How to get nothing done

Ben Madley, 30 Dec 2020

Plenty of articles will give you help on how to get things done, but precious few help you do the opposite: minimise your productivity and spend the most time doing it possible. This is the definitive guide to reducing your productivity as a developer.

Always be working

The first trick is a little counter-intuitive. You’re looking to reduce your productivity, so why should you work more than you do now? Well, let’s examine what happens when you decide you’re always going to be working.

First you need to pick something to do, maybe even find something to do. Let’s not forget, you need to always be working, so you need that task as soon as possible. This lends itself to picking the first thing that comes up, rather than the most important or useful thing. Maybe the thing you pick up isn’t even useful at all. Maybe it will be detrimental!

Now that we have that task, we get working. Eventually we meet a problem. There’s a natural break like a meeting or we need some help. In the time until we can start working again, we’re going to have a break in working. This is exactly what we’re trying to avoid. So we pick up a new task! Once again we find the first thing we can do so we get back to working as quickly as possible, but now we have two tasks! How do we work on them? There are two options and you can pick either!

1. Pick one of the tasks to try and complete. We leave the other task until we get stuck again. By the time we get back to it, we’ve forgotten what we were doing, the context and our plan. If we’re lucky, we might need to have another meeting. Now we’re stuck on two tasks and we can find a third! All without finishing anything.
2. Complete both tasks at the same time. This is another great strategy, allowing us to multi-task, swapping between our tasks. This lets us waste time context switching, while we’re still working.

As many tasks as possible

While we could wait for the tasks to come up organically, if we’re lucky, we can skip the middle step. Start with more than one task. Even better we can actively volunteer for more tasks as they come up. They don’t have to be big, even a small task can contribute to our context switching.

Work in large chunks

While small tasks are fine, it does make them easier to finish. Consider working in large chunks. Your tasks should be measurable in weeks and months rather than hours and days.

Large tasks are great because we can lengthen our feedback loops. We can take a task that was going to take a month (longer if we’re multi-tasking) and then wait until we think it’s done. Now we take our big load of work and show it to someone to get feedback. They are definitely going to have suggestions. Probably a lot of suggestions. The situation will have changed and you may have gotten the wrong picture. So you’ve now got a lot more work to do, and you’ve still not finished anything. As a bonus, while you’re waiting for that feedback, you can start a new task!

Work alone

We can shortcut these feedback loops by working more closely with other people. If we pair program we don’t need code reviews, you can even pair with non-developers and skip other reviews. You could even work closely with your customer, to reduce their changes. Obviously we want to avoid this at all costs, so work alone for as long as possible.

Together these principles lead to a situation where you’re forever working, but nothing is getting finished. When you do finish something, it’s taken longer than it should have and had less impact.

Inspired by CGP Grey’s 7 Ways to Maximize Misery: