How do you know when you’ve got a really good idea? Apart from all the usual indications of brilliance, I think truly great ideas announce themselves over time by popping up in different places. Look, for example, at the design of the Erlang language. Erlang borrows a concept of component isolation from the hardware design of highly-reliable telephone exchanges and uses it to allow the coding of robust, fault-tolerant software systems. That’s one example of an idea crossing domain boundaries, but the same idea turns out to make Erlang an effective language for achieving parallelism on multi-core CPUs and in networked applications. It turns out the basic concept of component isolation is useful all over the place.
I have recently come across another example of this kind of idea migration in a blog post by Steve Streeting on what he calls Work 2.0, or being an interruptible programmer. Steve’s basic observation is that the programmer’s fundamental tool is their concentration, which they tend to apply ferociously over long periods to immerse themselves totally in a task. The problem with this is two-fold. Firstly, these long periods of deep concentration aren’t good for the programmer’s physical health: the human body just isn’t designed to sit still for so long, especially not at a desk. Secondly, the modern office environment doesn’t allow for uninterrupted concentration. Even if a programmer is lucky enough to have a quiet, private office she can concentrate in, and co-workers who respect the fragility of that concentration, she is unlikely to escape the meetings, quick chats, conference calls and briefings which cluster the business landscape like dandelions on a recently mown roadside verge.
So what to do? Steve’s answer could almost have been borrowed from a 1970s operating system manual. Make the programmer interruptible by maintaining task state in some non-volatile storage which can be easily reloaded into working memory when required. Or, in non-geek terms, write down what you’re doing as you’re doing it, so an interruption doesn’t cost so much when it inevitably occurs. You just re-read your notes and you’re back “in the zone”.
I’ve been trying Steve’s approach out at work for the last couple of weeks, and I’ve found it beneficial in a number of ways.
- It really does help to make you interruptible. If everything is written down, even trivial things, it makes it very easy to context switch away to another problem with confidence that you can come back to what you were doing with little disruption. Beyond that, I find the act of writing things down helps to root ideas in my mind, as well as ordering my thoughts more rationally. It is easier to prioritise tasks when they’re written down in front of you.
- As a consequence of being more interruptible, interruptions cause less friction when they occur. I get less frustrated, and can concentrate on being more helpful. Everyone’s a winner.
- Keeping notes on what you’re doing has the unexpected benefit of helping to keep your gumption levels up. This week I didn’t manage to complete the task I was “supposed” to be doing, which could be depressing. But reviewing my list of what I actually spent my time on I could see that everything I did was valuable and necessary, and it allowed me to focus on the things I did rather than the things I failed to do. It helps to minimise that nagging feeling of “running to keep up”.
- It works really well for cross-referencing, or looking up a detail when someone asks about something a few weeks later. Our notebooks at work have an index in the front that makes this even easier. The index can be kept up to date in otherwise unproductive times e.g. during wandering meetings.
- It makes managing a context-switching workflow easier. Some programming tasks allow you to immerse yourself, whilst others necessitate long periods of waiting around for the computer to do something. Full test builds are good examples of the latter. If you’re only prepared to work on one thing at once, long periods of idleness really kill productivity. If you’re able to effectively switch to another task in the periods of waiting you can get a lot more done.
As with any new working technique, Steve’s approach for interruptible programming takes a bit of time to get to grips with. Reviewing his original article to write this post I see that I’ve missed some of the points that he made on ignoring tangential issues and negative prioritisation, which could be useful. Even at this early stage, however, these concepts have helped me to be more productive, and perhaps more importantly, to feel like I’m making progress even when the tasks are coming thick and fast.