There’s already a good amount of discussion out there about the need to take breaks to give your body – eyes, wrists, back, etc. – a rest, but not much about how to properly take a break without it messing with your flow.

A lot of programmers seem to be in touch with the idea of flow – you know, that period of time where you’re just on. I’m touching on the idea of getting in and out of flow successfully and repeatedly over a period of time.

Obviously, there are physical limits to how long you can do work for. But if you don’t record your thought process while you’re still in the flow, then none of that work matters, because you’ll never be able to return to it. The trick is to strike the right balance between work and meta-work, writing down just enough so that you can pick it up again later, but not so much that you’re not accomplishing anything of value.

With such a brain-intensive task as programming, it’s hard to tell whether or not taking a break helps you solve problems. I think of each of my breaks as a kind of context switch. The key is to know how long it takes for the context to dissipate. If you take a bathroom break or chat with your buddy for a bit, you can probably get re-familiarized with where you left off in a relatively short time period – maybe 10 minutes or so. After a two-week break, it could take a whole day. After a year, you’d probably feel like starting from scratch.

The moment you step away from a problem, the clock starts ticking. Eventually, you’ll forget what you were thinking at the time. That is, unless you plan ahead.

In order to truly benefit from a break, you need to finish things quickly, or at least leave them in a proper state of done, similar to the agile concept of having something releasable at the end of every cycle. But even if you don’t do the whole agile thing, the idea is still applicable to anything you code.

All you really have to do is record the context in which you leave off, so that it’s easy to pick the work up again. When a computer is happily plugging away on some process and gets interrupted, it takes everything it was working on – the “context” – and stores it somewhere in RAM, so it can use all those resources to work on whatever interrupted it. When it’s done, it grabs everything from RAM and puts it right back where it came from and then continues working on the original process.

This is easy for a computer because it doesn’t need to remember what it was going to work on next; it just gets told what to do by some predefined instruction code. For you, it’s a little different. When you’re in the zone, the direction in which you’re going is a bit fuzzy. You get a few ideas all at once but can only work on one at a time. That’s why you need to write out not only what you’re working on, but also your line of thought. Ultimately, this is why commenting and documentation matters – because you won’t always remember what you were thinking at the time.

Once you start thinking about storing the context when you put a task on hold, you’ll realize how costly it actually is to take a break. I’m not saying that you shouldn’t take breaks. Breaks are obviously important. The point is not to do so much in one sitting that you don’t have the energy to store the context before you take a break.

A brief example: the other day, I was working on Off The Clock before heading off to a brunch. I was only at my desk for about an hour before I had to leave, but I was definitely in the zone. I was able to get up to speed in about 20 minutes by referring to the notes I’d left myself a couple weeks earlier (I had written down what I needed to work on next along with a few possible implementation strategies, of which I followed exactly none).

Anyway, when I was done, I just kept all the windows open but took no additional notes. When I got back about 4 hours later, I just looked at what was on each window, and that was enough for me to get back into it within about 10 minutes. If I left it for two weeks, just having the windows open wouldn’t have been enough for me. I likely would have had to start from scratch again.

How much you need to write down is something I think you only learn through experience and practice, but, in general, the longer you leave a task, the more detail you’ll need to write down.