On interruption-driven development

As the sole developer at work, I have to balance our “ask me anything, anytime” culture with a need for unbroken concentration on whatever code I’m writing.

I’m generally fine with a door-always-open policy like this, because it makes communication fast and easy—especially in a small team, where everyone wears several hats—but as projects get closer to a deadline, it does tend to put a bit of strain on my ability to get things done. When that project involves a relatively complex application, however, it can be very hard to keep things on schedule, because task switching has such a high cost:

That’s because programming is the kind of task where you have to keep a lot of things in your head at once. The more things you remember at once, the more productive you are at programming.

I’ve been struggling with this a little bit lately. It’s no one’s fault, of course—colleagues are just interacting with each other the way they always have.

So far, I’ve been trying some of the more common workarounds to this kind of workflow:

• coming in to work two hours earlier than anyone else to focus on trickier problems
• working from home¹
• declining meeting requests that I don’t absolutely need to join
• delegating other tasks to other colleagues
• using noise-attenuating headphones when I need peak focus

It’s helping somewhat, but what I’ve noticed as the project approaches release-candidate is a little more interesting.

The more loosely-coupled the code is, the easier it is to come back to it after an interruption. Instead of having to keep all kinds of interaction in my head, I love small, simple classes that have no knowledge of their context. They do one or two related things, and that’s it. Jumping in and out of these is relatively easy.

A good debugger and a test suite are indispensible. Interrupted tasks are twice as likely to contain errors, so a thorough test suite—and really writing tests before code, as TDD requires—helps catch these. Some parts of my project include firmware that’s written without the benefits of test frameworks or breakpoints, so I have to resort to caveman debugging. This is something I’m going to avoid in future projects.

Refactor your comments with your code. You should never trust your comments to accurately reflect what your code does unless you consider them to be inseparable from the code, and change them while you make changes to your code. When you’re interrupted, ask for a minute to take a note on what you’re doing and add TODO:, FIXME:, or HAX: comments that you can come back to.

These things do way more for my ability to mitigate how badly an interruption affects my productivity than headphones, working from home, or refusing meetings, and they make my code better to boot.

What works best for you?