turnings :: daniel berlinger

passions :: perfections :: peoples :: stuffs

Archive for the ‘agile’ Category

Maker’s Schedule, Manager’s Schedule

leave a comment »

Maker’s Schedule, Manager’s Schedule:

When you’re operating on the manager’s schedule you can do something you’d never want to do on the maker’s: you can have speculative meetings. You can meet someone just to get to know one another. If you have an empty slot in your schedule, why not? Maybe it will turn out you can help one another in some way.

Business people in Silicon Valley (and the whole world, for that matter) have speculative meetings all the time. They’re effectively free if you’re on the manager’s schedule. They’re so common that there’s distinctive language for proposing them: saying that you want to “grab coffee,” for example.

Speculative meetings are terribly costly if you’re on the maker’s schedule, though. Which puts us in something of a bind. Everyone assumes that, like other investors, we run on the manager’s schedule. So they introduce us to someone they think we ought to meet, or send us an email proposing we grab coffee. At this point we have two options, neither of them good: we can meet with them, and lose half a day’s work; or we can try to avoid meeting them, and probably offend them.

Till recently we weren’t clear in our own minds about the source of the problem. We just took it for granted that we had to either blow our schedules or offend people. But now that I’ve realized what’s going on, perhaps there’s a third option: to write something explaining the two types of schedule. Maybe eventually, if the conflict between the manager’s schedule and the maker’s schedule starts to be more widely understood, it will become less of a problem.

Those of us on the maker’s schedule are willing to compromise. We know we have to have some number of meetings. All we ask from those on the manager’s schedule is that they understand the cost.

[Well explained. I try and line up meetings in a given day. When they can't be aligned that way I use the middle of the day, reserving the morning and end of the day for "maker" time. Allez! ]

Written by Daniel

November 5, 2013 at 3:10 pm

Better than an “email vacation”

leave a comment »

Better than an “email vacation”:

Much like inbox bankruptcy, simply running away from email overload doesn’t solve the problem. What does work is to engage email as described in Bit Literacy (free Kindle ebook, free iBookstore ebook). To summarize: move your action items to a todo list, and archive or delete everything else. The inbox should be empty at least once a day.

[Mark's been talking about this for as long as I've known him. Just do it already. You can thank me later. BTW, the email client I've been using for work has an setting that shows only unread mail. Very useful.]

Source: Creative Good

Written by Daniel

May 15, 2012 at 7:27 am

Posted in advocacy, agile, craft

Rookies in the bike shed

leave a comment »

Rookies in the bike shed:

The ability to spot this is one of the most valuable skills a software developer can possess. There are endless features we could build and debates in which we could engage, but only a small subset are worth the effort.

The best developers aren’t the ones who can write the most code in the shortest amount of time or out-reason anyone on the internets. They are the ones that only write the code that’s most valuable to execute and only enter the debates of high substance.

[And that is what makes anyone good at what they do. It is about editing things down to the most important things and concentrating on those.]

Written by Daniel

March 27, 2012 at 1:59 pm

Posted in advocacy, agile, tech

What clarity is all about – (37signals)

leave a comment »

What clarity is all about – (37signals):

If your whole business was laid out flat – every product, every promise, every price, every rule, every condition all on one surface – and you superimposed a heat map layer over it, where would the confusion hot spots be?

[Not a bad exercise to perform...]

Written by Daniel

March 22, 2012 at 1:32 pm

Posted in advocacy, agile

Compare and contrast: The 4 day work week.

leave a comment »

So there’s a pointer to this Inc. article in my inbox this morning. I don’t need any convincing about the potential for a company to form its own work schedule. But it seems to me that this article is lying, or the author is fooling himself, or worse, he’s taking advantage of his employees. To wit: The Case for a Four-Day Work Week

The extra time for research makes for a well-informed team and the realization they have something unique.

So they work 40 hours in 4 days. But then, they get to do research on their “day off”. Huh? How is that helping? I realize that they can run errands and do other things at home since their not expected in the office, and mot likely do not have to answer email, the phone etc. But this smacks of creating a 48 hour work week to me. Either include the research in the work week (“Hey, I need my people to keep up!”) or crow to Inc. magazine how you you fooled your employees into a 48 hour work week and here’s how. Or, one more possibility, no one’s doing anything significant for the company on that day and he knows it. Which makes the article a lie about the benefits of time for research.

Now compare that to how Jason Fried talks about the topic of his company’s schedule:

I don’t believe in the 40-hour workweek, so we cut all that BS about being somewhere for a certain number of hours. I have no idea how many hours my employees work — I just know they get the work done.

Only half the people in the company lives in the area where they could possibly come into the office. But there’s no requirement to at all. They don’t track hours because that’s not the goal. The goal is getting stuff done. I’ll bet there are weeks where people work many more than 40 hours, and times when they work less. Does it matter? Being home to “meet the plumber” shouldn’t be a benefit, but common sense. Not being able to schedule appointments and handle the trivia of life adds enormous stress to people. Do you want a bunch of stressed out, unfocused, people working with you? (do you think the leak held? No shower this morning, gah. etc. throughout the day) Do you want to create an environment where people consider lying as a time management strategy? (Hmm, I should call in sick so I can take care of this.)

Anyway, regardless of whether any of this works for you or your company try not to use it as a means of extending the work week rather than embracing the real benefits.

Written by Daniel

January 18, 2012 at 7:54 am

Wunda’s World: Clarifying purpose

leave a comment »

Wunda’s World: Clarifying purpose:
How can we do this? By understanding and buying into what we are creating and how we see it experienced. We can create a mission, vision and values to clarify and create distinction.

The mission statement is all about purpose. Its about the problem you are trying to solve, the information you are trying to share and/or the service you are trying to provide. Its about the long term goals.

On the other side, the vision statement is an abstraction of the experience. It can include words like fun, simple, quality, quickly, stable, reliable, responsive, etc. It does not include ideas like color schemes, mechanics, technology specifics or other implementation details.

Time can also be spent on value statements (users own their information, we strive to directly connect with and respond to user feedback, all user feedback is valid, etc)

Continue drilling down into these ideas until everyone knows what they are doing, are excited to work towards the goals and know in their hearts they are working on an effort they accept fully.

For new teams, taking time to manifest an understanding of team dynamics, quality and creativity with as much openness and honesty as possible can help ensure the best “good-enough” software gets created in a way that is enjoyable, sustainable and collaborative.

Finally, read these statements every morning. When discussions become long, unclear or hostile, refer back to them. Use them as a method to stay detached to what is no longer serving and focused on the underlying issues.

[Well said!]

Written by Daniel

December 6, 2011 at 3:36 pm

Busy Developers Guide: CoffeeScript

leave a comment »

Please note that these instructions are for busy developers, and assume that you are one. If so, this should help, if you’re not, these may not. Sorry about that. Below are the steps I used…

  1. First get npm (the node package manager).
  2. You’ll find a one line install such as this or similar: curl http://npmjs.org/install.sh | sh
  3. Next CoffeeScript: npm install -g coffee-script (Leave off the -g if you don’t wish to install globally.)
  4. Assuming that went well you should be able to type “coffee” on the command line and see a "coffee>" prompt.
  5. Pat yourself on the back and start developing! But wait, a little more structure might help… You can skip the steps below and check out the repository.
  6. Create a new folder and get it set up as a repository. For me that looks something like this: mkdir ~/code/learning_coffeescript; cd ~/code/learning_coffeescript; git init;
  7. Create some files a bit of structure. A top level public directory and src directory. Inside public I created a lib dir and an index.html file.
  8. The index.html file contains a base html 5 template, and in my learning case it included a line pointing to the hosted jquery.js lib, and our newly compiled javascript file (yeah, I know, patience… I’ll get to it in a minute.)
  9. Back in the terminal, at your project root, type coffee -o public/lib -cw src which will compile all the CoffeScript files written in src into javascript in lib. It is “watching” the src files timestamps so if you update and save a file it will recompile.
  10. Assuming you’ve got everything wired up correctly, you can fire up a browser, open the index.html file and go to town.
  11. If you want to get snazzy you can rackup file_server.ru -p 1111 and the project will run under a basic Rack file server.
  12. If you wish to be all hip and edgy you can download and install Pow, symlink your local clone of the repository and develop to your hearts content.

Feel free to make pull requests, or send me issues, updates, or notes. I’m sure I have a lot to learn about CoffeeScript how best to integrate it with jQuery, etc. In the end though, I’m enjoying the syntax. It was just not clear how to get a project going. Next I’ll be looking at testing…

Written by Daniel

May 3, 2011 at 6:12 pm

Posted in agile, code, docs

Follow

Get every new post delivered to your Inbox.

Join 514 other followers