The interruptible programmer

A read a good blog post about learning to work¬†interrupted. ¬†Work 2.0 ‚Äď the interruptible programmer. ¬†The blogger had to learn to switch from a conventional, anti-interruption, get in ‘the mode’ then stay there for as many hours as possible, to a take frequent breaks mode due to health problems. ¬† It was interesting since the majority of my career I’ve been exposed to the frequent interruptions style of working and have been aspiring for the non-interruptions style in order to improve throughput.

At my old job, I used to handle a plethora of queries.  Support phone calls would come through distracting me from programming.  I also used to keep my ears open for conversations about areas of the software or business I knew about so as to be able to help my colleagues avoid taking a wrong, time-consuming path as they were scoping out ideas for solutions to business / technical problems.  These too were distractions that I had to learn to shut out.

At my new job, there are still distractions but an order of magnitude less than what my old job was.  No phone on my desk, or MSN chat allowed means that the only real distractions are from my boss, some seldom queries from a fellow dev or product manager, and then emergency support queries from the business when all the other developers are away that are even more seldom.

Adjusting to this new way has been a little harder than I initially thought. ¬†I was used to being interrupted. ¬†The benefit of being interrupted often was that I wouldn’t get ‘locked on’ to a problem. If I was stuck, something would happen by chance to distract me so that when I came back I had pondered a way forward in the background. ¬†It was so run of the mill that I didn’t realise how much it became part of my daily routine.

At my new job, I found I’d get stuck on a problem and then keep pondering and pondering on it without a way forward thanks to the seemingly productive ‘one thing at a time’ mentality. When faced with a hard problem, I had to learn to deliberately leave a problem be for a little while and re-employ the task switching skills I’d learnt at my previous job. Here is a crazy analogy: Work is not a sausage that you can split in half and then continue eating the other half later. ¬†Some parts of eating the sausage wear you out, and you need to cut up into smaller chunks so you can chew through it.

The blogger however reminds me of my current boss, who I must say is exceptional at task switching in the face of constant business and colleague distractions (or at least able to do frequent task switching without complaining about loosing context). ¬†It was good to have a working example to think about whilst reading the blog. ¬†It seems that the best tricks to employ are, to one, not get upset that you are being distracted, and two, keep some context of what you are doing, so that when you switch you have something you’ve written down to come back to. ¬†The blog post makes mention of GTD as well which is good to see.

Leave a Reply