Choose What You Spend Your Time On

I’ve been a software engineer for 16 years, and I see myself as just ‘ok’ at programming. No-one ever looks at my code and says Wow!

But one thing that makes up for my deficiencies is that I’m good at choosing what to spend my time on.

What I Do

Engineers will never have enough time to work on all the great ideas or improvements that they think of, so a really important factor in being effective, is deciding what — today — we should spend our time on.

So try to:

  • Choose which tasks/ideas have the best combination of value, cost & risk that you can work on today, this week, this month?
  • After starting on an idea, do the minimum possible to get a feel for if it’s going to be viable.
  • Re-assess often, avoid getting caught up in the sunk cost fallacy, and drop ideas without remorse when needed.

This can all seem inefficient, but:

  1. The best way to find out if an idea is really viable, is to try it out.
  2. It’s far better to spend a few hours or days on a handful of ideas, that end up being throwaway, than to spend weeks or months on an idea that ends up not giving the expected benefits.

Choosing what I Should Work on Today?

The answer to the question should not automatically be — “whatever I was working on/thinking of working on yesterday”.

If you made a decision yesterday based on the information you had then, but today you’ve gained further information, then you should re-assess.

Gain Feedback Early, so you can Re-Assess Early

“When the facts change, I change my mind. What do you do, sir?” — John Maynard Keynes

Try out ideas, but assess early, and give up on them if they don’t look like they’re going to be the most valuable thing you can work on this week.

I’ll often try and get more insight quickly by hacking something very ugly together that’s just enough to give me some real feedback — whether that’s some profiling data for a performance improvement, or just to confirm that a new feature would actually work in practice.

And I’ll frequently just shelve little mini-projects after spending a few hours on them. If I’ve gained enough feedback and don’t see them being as valuable as other tasks I could work on, then I stop working on them. It’s a sunk cost, so move on.

The goal is to get some real feedback. Data, not assumptions.

Judge the Value of Each of the Competitors for Your Time

Consider the value, cost and risk of each of your options. You can’t properly compare options, based only on considering the value or cost or risk of them. You need to consider all of these to get a full picture, and therefore make a good choice.

From the pov of my work, I see these as:

  • Value: Always tied back to business value. Either reducing business costs, or increasing revenues.
  • Cost: Engineering time to build and maintain in future, plus any additional hw or sw costs.
  • Risk: Level of confidence in the predicted Value and Cost.

I don’t always go to the extent of formally assessing these, but I find that just the act of thinking them through and attempting to make some estimates, can significantly improve the quality of decisions.

Applicability

I find this approach particularly important if you’re part of a you build it, you run it style of team. I’m a huge fan of this way of organizing, but it does require engineers to bounce around quite a bit. So being thoughtful about priorities on a frequent basis, really helps with getting a good balance between reactive and proactive tasks.

And an important enabler for this approach, is that the organization you work for gives you the space and freedom to make your own decisions. I’m lucky working at Netflix to be in this situation, and my managers here — @moldfarm, @schmaus, @daniel_jacobson — work hard to foster this kind of environment. “Freedom & Responsibility” really is applied all the way through the company.

This article was originally posted on my own site kerumai.com.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.