Programmer Productivity – Interruptions, Meetings and Working Remotely

In my previous post on what programmers want, I ranked working from home low on the list. Several commenters value working from home higher, and K (not his real name) added a link to a great TED talk given by Jason Fried (of 37signals) on why it is hard to get any work done at work. Jason starts with the observation that programmers need long stretches of uninterrupted time in order to get stuff done, and goes on to recommend avoiding meetings, and minimizing interruptions by using chat and e-mail instead of direct communication. While I agree with the meetings part, I think there is more to consider regarding interruptions. I also value face to face interactions more than he does.

office Interactions

The picture Jason paints of working at an office makes you wonder why we work at an office at all. Constant interruptions from bosses, colleagues and meetings make it hard to get anything substantial done. Why not have everybody work remotely all the time instead? For me, the main reason is that software development requires a lot of collaboration. Brain-storming, discussing, and refining ideas with other developers usually yield solutions much better than what you can come up with on your own. Furthermore, these kinds of interactions are much more effective in person, with a whiteboard handy (pretty much all discussions benefit from a few quick drawings). Remote collaboration tools try their best to recreate the face to face dynamics, but it is never the same as being in the same room with someone.

Jason recommends switching from active communication (face to face or phone call) to passive communication (e-mail or chat), to avoid interrupting people. This is good advice for avoiding interruptions. But after the initial request, the sooner you switch to talking, the better. Written communication works well for simple questions and answers. However, talking to someone is at least an order of magnitude more efficient when there is even a little bit of uncertainty or ambiguity . For example, if I get an e-mail with the question “Do we support feature XXX?”, most of the time the answer is not a simple yes or no. Perhaps it depends on which other features the customer has. Or we may have just developed the more capable feature YYY that they could use instead. Writing all this down takes time and effort – talking (in person or on the phone) lets you have the back and forth immediately, instead of spreading it out in writing.

Good Interruptions

While I totally agree with Jason that programmers need long stretches of uninterrupted time in order to be productive, there are cases when interruptions should be tolerated. If someone is working on a problem (a tester, a support engineer, or another developer), and has a question I know the answer to off the top of my head, I’m fine with being interrupted. Sure, my productivity takes a hit, but we should optimize for the company’s productivity, not only my productivity. If one (or several) other people in the company would be stalled, it’s better to ask me and get the answer in one minute, than to dig around for an answer in the code or in the documentation.

Another case where interruptions are acceptable is when there is a trouble report. In my team at work, we have virtually no trouble report back-log. We try to finish off trouble reports as soon as we get them. Getting back to the customer right away has several benefits: the problem is fresh in their minds, it’s easy to get additional information if needed, and the customer sees that we care about fixing the problem quickly.  The quick turn-around time means that no back-log of unanswered trouble reports builds up. It is also easy to stay on top of what the outstanding problems are at all times, since there are so few of them.

Meetings – Inefficient use of time

When it comes to meetings, I agree with Jason: the fewer the better. Having a meeting is often very poor use of time. When I worked at Ericsson, we had a weekly status meeting for the whole R&D department on Tuesdays at 10 o’clock. So at 9.30, you don’t feel like starting anything new, since you know you are going to be interrupted soon. Knowing that you will have to attend a meeting soon causes you to get less done. An unplanned interruption is much better – at least you don’t know about it beforehand. Another problem with those status meetings was that pretty much all information given could just as easily have been sent out in an e-mail.

Another reason meetings are inefficient is that often the people there aren’t needed for the whole meeting, so some of their time is wasted. At Symsoft, I have very few meetings. Instead of calling a meeting, I’ll walk over to the people involved (all developers are a maximum of 5 offices away) and discuss the issue. No meeting, and only the people directly involved are interrupted. Way better than the overhead of a meeting.

It’s not that hard

The work place Jason describes in his talk is pretty bleak. But it doesn’t have to be that way. I have never worked for a manager that came around frequently for “status updates”, probably because they have all been programmers too, and know not to interrupt. I hardly have any meetings at all at Symsoft, and it was the same when I worked at Tilgin. Creating a good environment for software developers isn’t that hard. I do get interrupted, but almost always for the right reasons. I become less productive, but we become more productive. And I still have plenty of quiet, uninterrupted time for developing new features and fixing bugs. How about you?