A quick guide for productive development

Tom Renner

- 3 minutes read - 518 words

It is upsettingly easy to work hard without being productive. The Lean Startup includes a quote I really liked:

“[People] feel that a good day is one in which they did their job well all day.”

The point being that this doesn’t account for whether you are doing the right work. This is a really common trap to fall in to. I know I have often worked really hard on something and produced code I’m very happy with, only to talk to my boss or the client and find that nobody else seems to be nearly as pleased with what I’ve produced as I am.

In these cases it’s tempting to throw up your hands and say that other people don’t appreciate your efforts (the “misunderstood genius” approach), but more accurately there has been a disconnect between their values and your prioritisation.

So what do I do to try to avoid these problems?

  1. Take every short-cut. Not as in “if we hack this together it might work”, but make sure you ONLY address the major requirements (you know the critical requirements, right?). “Nice to have"s can wait till v1.1, and probably don’t matter anyway.
  2. Prioritise my time by value rather then complexity. This helps avoid the problem of perfectionism, and stops me doing things just because they seem challenging or fun.

So realistically, my pattern of work goes something like:

  1. Estimate the things I want to do in the next cycle
  2. Order them by value
  3. Try to do them
  4. Work out half way through that I might miss some of them
  5. Observe what I am spending my time on, and make sure it’s the most important of the things listed in point 1.

This tends to get me closer to what I aimed to do than if I try to start by tackling the most complex tasks first. Complex tasks are sometimes the most valuable, but complexity also depends a lot on the skill-set you have as a developer. I, for example, suck at front end things. CSS and client-side JS don’t like me (and I don’t try too hard to like them). Recently I found myself spending time getting a web form to recalculate related fields on changes around the form. It was only after two hours that I thought about how little value this task ultimately provided. It was surprisingly complex (because of an uninteresting set of event change handlers) but not actually very valuable for the overall work I needed to do that week.

It is also important to remember that value should be measured as a team, not as individuals. An individual will think they’ve produced maximal value in a day when they sit at their desk and work on their own tasks all day. But maximising value produced for the team will require cross-functional tasks, and collaboration. That level of perspective needs active thought and coordination, not just personal prioritisation.

I find most people assign their time by complexity. I think you need to do the value assessment first. Keep that in mind (even after sharing out tasks) to keep everything on track.

A quick guide for productive development