Like a game

Have you ever played a computer game where your character could die at any point? First person shooters (Doom, Quake…) make for an excellent analogy to distractibility. What do you do when you have to complete difficult, complex, sometimes tedious tasks and your progress can be lost at any point?

A long, long time ago, there was nothing you could do. You just played the game until you died. A few palliatives were invented to try and deal with that, and eventually, they culminated into the ideal solution: saved games. Nowadays, if you’re playing a game like Quake, you can save whenever you’ve done something that was hard or lengthy. Then, if you happen to die in the next minute, you can reload from the saved game. If you save every minute, you can minimise the effects of dying to, at most, translating into one minute of lost time.

If you accept the fact that you are easily distracted (and, after years of fighting it, it’s something I’ve come to accept rather than fight), you could consider distraction to be similar to dying in a computer game. Accepting your own distractibility means that whenever you’re doing any work, you have to accept that you might be distracted and start doing something else for two hours, two days, or even two weeks.

So what can you do to mitigate this sword of Damocles? You need some sort of real-world equivalent of saved games.

#2 Keep tasks closed

A task is closed when you can ignore it for an indeterminate amount of time and there will be no direct negative consequences from doing so (other than the fact that this specific task won’t get done), and when it isn’t left in such a state that you will struggle to pick it up again.

A programming task (e.g. a refactoring) is closed when you can commit and push all your changes into the main codebase and not (knowingly) break the application.

A writing task (e.g. writing a book) is closed when you’ve finished a self-contained section or sub-section and can leave it without having to spend 20 minutes to re-immerse yourself in the subject to continue writing.

A managerial task (e.g. setting up a weekly meeting) is closed when no one is expecting anything else from you on that task.

A closed task is in a state of rest. It can be safely ignored while you do something more important. It’s like saving the game after killing all the monsters in the room, but before walking into the next room. An open task is either when you haven’t saved the game recently, or you’ve saved it in the middle of a fight.

Open tasks are risky

There are many risks with abandoning open tasks:

1. They can prevent other people from getting on with their own tasks (which breeds resentment against you even though you’re working hard and enthusiastically);
2. You might have been able to work on the task today on an inspired high, but you might be on the low for the next week. If you leave open a big, complex task, and go do something else, you may be incapable of picking it up productively again for some time;
3. As long as the task is open, it will clutter your mind and your ability to do other things will be diminished. Keeping tasks open uses up your mental capacity and impacts every other task that you’re involved in;
4. By the time you are finally able to complete the task, someone else might have rendered it irrelevant (if you’re working in a fast-moving environment);
5. Say you finally complete the task and have taken five or ten times longer than expected; in hindsight, others may think it wasn’t worth spending that long on it - this will rob you of the praise that you need and expect when you complete something difficult.

And so on.

The key approach to surviving distractibility is to keep almost all tasks closed all the time. Only one task should ever be open at any one time, and it should only ever be open for a short amount of time. How long depends on your work. For programming, I like to make that time fifteen minutes. At least every fifteen minutes, I should be able to save all my changes and commit them to the central repository without any ill effects.

Some people present this advice as “you should not multi-task”, but that phrasing is not so useful to the hyperbrain. The reason is that the definition of a “task” is stretchy. A major restructuring of a codebase could be considered a single task, even though it is really composed of dozens or even hundreds of small tasks.

For the hyperbrain, the definition of single-tasking has to be time-based. You need to set yourself a limit for how long you will work on something before closing it.

If you don’t think you can close the task within that time, don’t do it.

Rethink the task until you can figure out a way to close it within a short time. If you can’t think of a way to do that, don’t start the task. You wouldn’t jump out of a plane before finding the parachute - don’t jump on a task without figuring out how to chip off a small chunk.

“Don’t multi-task” is correct advice, but not useful to the hyperbrain. Instead, think of it as: “Don’t do anything that you can’t close within fifteen minutes”.

This doesn’t mean that you need to break down the whole task into fifteen-minute chunks before starting. Don’t even try doing that, you’ll never finish. Instead, break off one chunk at a time. Ask yourself “what’s the next thing I can do that will help me get this task done, but that can finish in less than fifteen minutes?” Make sure that the next thing you work on can be finished in a short sprint. Each time you finish a sprint, break off another small chunk of the remaining work and do that bit.

Also, don’t feel that it’s a bad thing if it takes much less than fifteen minutes to complete a task. Some of my most productive stretches of work were long collections of 1-minute chunks.

What if you can’t seem to finish it?

What if you start a task that you thought could be finished within fifteen minutes, and you find yourself half an hour into it without any clear endpoint yet? This can easily happen with complex work, such as programming - after all, you don’t really know exactly what you’re going to do until you start doing it.

If that happens, you need to roll back to the previous closed state (discard your changes and reload the latest good version). Take the game metaphor: if you were playing your game and suddenly you find yourself dead? You simply reload. The unfortunate difference between a game like Doom and real work is that work doesn’t make it so clear when you’re dead. You can keep going like a zombie for a long time before you realise that you died three hours ago. And because, as a hyperbrain, you’re fairly optimistic about your own abilities, you keep soldiering on, thinking it will get better soon. Another way to phrase this advice would be: “When you’re in a hole, stop digging!” It won’t get better. You’ll just end up even deeper.

With work, it’s often hard to figure out whether you’ve lost your way and should back out, or whether it’s just a hard problem that you’re on the verge of cracking. Fortunately, there is an absolute, objective measure you can use to determine whether you should back out: time.

This is not a huge effort of discipline. It does take a little mental effort to “give up” on fifteen or thirty minutes of work that you’ve just done, and I’ll grant you that’s sometimes hard to accept. But if you can apply this simple discipline, you will see a several-fold improvement in your productivity (and that will make you happy and drown out any sorrow that you may have experienced when abandoning a small dead chunk of work).

Conclusion

You don’t need to be a super-hero to adapt to distraction, just to follow a handful of simple rules:

1. Reduce the distractions in your environment as much as possible, but accept the fact that you will probably get distracted anyway, and be prepared for it
2. Never leave a task open for more than X minutes (fifteen in my case, for programming tasks)
3. Never open more than one task at a time
4. If you are working on a task and it’s taking longer than your cut-off point, roll it back and try again from a different angle

I hope you’ve found this article helpful. Feedback is, as always most welcome.