The piecewise approach to stress-free projects

It’s commonplace advice: break a big task into smaller tasks, to take one at a time. It’s almost a platitude, but it’s not a platitude, because it’s almost helpful. The problem is it doesn’t tell you how to break a problem down. Well, I’m going to break this idea down, and see if it gets us anywhere.

Along the way, I’ll spell out some things that may seem obvious. I do this as preparation to explaining why they matter and how to think about them. I’ll also introduce some computer terminology, because it happens to apply by almost exact analogy.

First, what is a subtask? A subtask is a piece of the big task that could almost be a task in its own right. So, what’s a task? It can be conceived of as a well-specified aspiration, with a starting condition and a desired end state. What you’re after is a process to get from one to the other, and a list of the resources you’ll need.

When you begin a task, you want to gather all the needed resources and then do the work. When you’re doing a task, things are in pieces around your workspace, and you’re mentally immersed in details. When you’re done with a task, things are more together and tidier than when you started. Likewise, to a lesser degree, with a subtask.

What’s my point? You’ve got a workspace, and a mind, and both are in a very different state depending on whether or not you’re in the middle of a task, and this matters. When you’re working, you’re swimming in details. The sum total of all these details – the bits and pieces on your bench and in your mind – is called process state. That’s jargon from computer science. It means, of course, all the stuff a computer has to keep track of to complete a task.

When you’re immersed in all this process state, you do not want to be interrupted. Also, if you stay in this state (of mind) too long you’ll get first stressed, and then fatigued. You want to get rid of all this damn process state at some point by finishing the job.

Again: a subtask is like a smaller task in its own right. So there are at least two bits of state now: the state of the main task, plus the state of the particular subtask you’re dealing with. It’s not as bad as it sounds, when you realize that the subtask IS the process state of the main task.

Why does all this matter? Because it tells you where to break the task into subtasks. A subtask break is when there is a sudden dip in the amount of state (details) to keep track of, or of the things in an untidy state. There’s still some state, or else the task would be finished. But there’s not nearly as much. Your mind and workspace are both almost tidy. This feels like a sense of completion of something and the start of something else, because that’s what it is. If it doesn’t feel like that, it isn’t a proper subtask break.

Which brings us to why we want to break a task into subtasks. After you’ve done a subtask, you can rest. Or you can work on some other task. This is called a context switch in software jargon. If you try to rest or switch tasks at any other time, you will feel frazzled from all the clutter sitting in your brain, and physically blocked by all the pieces and tools lying all over your workbench. The objective is to context switch at the easiest, least stressful time at which you can possibly do so. That time is the subtask break.

(A secondary benefit is you keep clutter from accumulating, by planning to reduce the size of the process state at every opportunity.)

A subtask break is the best, most natural time to context switch. A breaking point. Life forces us to context switch, and this is how we manage the stress of multitasking. This is why an untidy state is stressful – it makes us feel a slave to the task at hand. We are anxious that we’ll lose track of what we’re doing and not be able to pick up where we left off.

Subtasks can be nested. There are states within states, and subtasks within subtasks. Nest if you must, to get the process state carried between subtasks as simple and manageable as possible.

If the product you’re trying to create has a structure, your subtasks can mirror that structure. For example, in writing, write one paragraph at a time. (Nesting: one chapter at a time, one paragraph of the chapter at a time.)

At the very start of each new subtask, ascertain whether you have everything you need on hand to accomplish that subtask. If not, hold off on the subtask until you have what you need. The task is blocked. It is in a wait state. Context switch to something else.

I’m using software terms because I’ve been thinking of this in terms of computer programming. Most operating systems are what’s called preemptive multitasking, which means the time at which a context switch occurs has little to do with the nature of the task, but is arbitrary, like a rigid schedule. This forces the system to have a stack and registers for each task. That’s extra process state to be kept track of. On very tiny computers, this eats up scarce memory. On any computer, the load of dealing with can slow the system down a bit. For humans, it’s a lot worse.

A handful of operating systems have used something called cooperative multitasking instead of preemptive multitasking. In these systems, all tasks are either event driven or otherwise broken into tidy subtasks, and no context switch occurs against the will of the currently running task, but only when that task has just completed a subtask or is blocked. This is more efficient because there’s less process state to manage across task slices. No task even needs its own stack or registers. While a subtask is being performed, exactly one stack and one register set is needed. (Interrupt processing complicates this picture, but only a little.)

Computers don’t complain much, and are so powerful nowadays that we don’t often care about such inefficiencies. But for humans, preemptive multitasking is very stressful and draining. In your own mental processing, piecewise processing is the way to go. When you’re forced to multitask, make it cooperative multitasking.

And you will be forced to multitask. You will run into a point in a job where you don’t have something you need, and you can’t get it just yet. In computer science, we would say the task is in a wait state, or blocked. The computer schedules its next time slice for some other task that isn’t blocked. You can do the same. If you’ve identified your subtask breaks properly, this will always happen just as you’ve cleared most of the clutter and you’re ready to move on to the next subtask – the least stressful time possible to switch tasks.

One caveat: cooperative multitasking is unpopular because it can’t cope well with something called the halting problem. The halting problem means that there are some subtasks where we can’t even guess how long they’ll take, and they might take forever. Even preemptive multitasking can’t entirely solve this, it can only confine the damage to a single task in the system. This why you sometimes have to kill a hung task. In cooperative multitasking, the entire system would be hung. Do try to avoid the halting problem if you can. If you run into it, the only thing to do is set a time limit for the subtask, after which you will simply give up.

In summary: the key to biting off pieces of a big problem is knowing where to bite.