Getting rid of the busy work

_{(Image by Charlotte Karlsen on Unsplash)}

I recently watched this video on Idea Flow, or how to improve software engineering in a team, which contains a lot of interesting points and ideas:

One idea in particular hit me and I'd like to write it down to make it more clear and concrete, so here we go:

3 Stages

In programming as in science, you can identify 3 stages:

1. Devise an experiment
2. Run the experiment
3. Analyze the results

While an experiment is running, this feels like 'time wasted', we sit around and wait for the results (e.g. a unit test to turn green). Therefore, our mind says we should optimize this time and make sure compilations are as fast as can be, and test runs are as fast as can be.

Which makes sense, to some extent.

When we're in stage 1 or 3, we're actually doing the work and in this stage it feels like time is flowing, we look up and suddenly 2 hours have passed.

Here, it doesn't feel that time is wasted, since we're actually doing something the whole time.

However, if you put these 3 steps on a timeline, it's very possible that step 2 takes the least amount of time. Yes, you have to wait and sit around for the code to compile and tests to run, but this often takes minutes if not seconds.

Compare this with the 'progress work' done in stages 1 and 3. In case you're going down the route of writing some faulty implementation, it can take easily half an hour and only then you decide to scratch the whole thing and take a different direction. There, 30 minutes 'wasted'. (Arguably it's not fully wasted, since you did actually learn something in that time.)

Mountain climbing

Who would you say is the more effective mountain climber?

The person that goes round and round the mountain, going up a bit with each circumference?

Or the person that takes the stairs on the side of the mountain, going up with each step.

I guess Person B reaches the top a lot faster than Person A. Maybe they have seen less and learned less, but if the goal is to reach the top of the mountain and plant a flag, then B is definitely the more effective climber.

Now if this is more of a holiday-type situation, then I would go with Person A: I would see a lot of nature, maybe some animals, learn more about Person A and about the country where we're at (I'm assuming we're abroad since we don't really have mountains in The Netherlands :-) ).

So in this case Person A would be the more effective choice.

In other words: what the best choice is depends very much on what the actual goal is.

The actual goal

Ok, so what is the goal in a software engineer's job?

Is it going back-and-forth on the code multiple times, shaving and tweaking until it is "just right" and learning along the way?

Or is it shipping a certain feature implemented by high quality and maintainable code as soon as possible?

The answer may be answered differently depending on the organization or even team. Also it might be answered differently for hobby projects and OSS.

A step back

Ok, now let's take it back to the beginning: in the 3 stages, we have the feeling that we should reduce the time spent waiting as much as possible.

However, I would say we should reduce the time spent 'making progress' as much as possible. Try to get to the top of the mountain as soon as possible, while still making sure code is high quality and maintainable.

How do we do this?

The aforementioned video has some tips & tricks mentioned at the end, including:

• Before starting a task, do a walk with a colleague and ask yourselves questions like: where do we think we'll spend the most time during implementation? What part will be the hardest to troubleshoot? What part will be the hardest to implement (i.e. where will we have the highest chance to make mistakes)?
• After the task (so after stages 1 till 3), do the same walk and ask questions like: how would I approach the task differently if I was to do it all over again? Did the part that we thought hardest to troubleshoot give indeed the hardest problems, or was it a different part of the task? Was the part that we thought hardest to implement actually the most difficult, or was there something else?

And then iterate, rinse & repeat. Good luck!

Conclusion

Our bias leads us to try to reduce the time spent waiting (e.g. on compilation or test execution).

Instead, we should try to reduce the time spent making progress.

You know those people that always say: "I'm so busy"? Some of them are just doing "busy work", which is not really making progress at all, but it feels nice because it feels like you're actually doing something. While the goal that you're trying to reach doesn't really get any closer.

So be very mindful of the time you're spending and optimizing that. This probably means less trial-and-error and more up-front planning/strategizing and after-the-fact reviewing.