Why developers hate being interrupted

Interruptions are to developers what kryptonite is to Superman—they kill productivity and there’s a significant recovery period.

There are two types of interruption: the planned meeting and the one where someone walks over to your desk to talk to you (or if you’re unlucky enough to have a desk phone it’s when the phone rings). The random interruption is akin to walking up to a someone building a lego tower, kicking it over and expecting them to continue from where they were the moment before you arrived. The planned meeting is a lot longer and kills productivity before, not just during and after. So, there are two types of problem that need addressed here.

What happens when a developer is interrupted?

A huge amount of what a developer is doing is in their head. As we write code we need to keep a mental model of how parts of the application that have already been written and are yet to be written interact with the part that we are writing at that moment. We need to have a solid picture of exactly how the code is working as a whole and maintain that picture. It’s not easy, it requires a lot of concentration and has to remain in place while we think of creative and efficient ways to solve the problem at hand.

Developers can appear very unproductive at times, sitting staring at the screen with our headphones on and very little in the way of keyboard clackety-tap. This however is when we are doing our thinking, when we are building up, adding to and rearranging the mental model of how our code will work. This is the biggest and hardest part of development.

Imagine how it feels to have that interrupted at random by a telephone call or somebody walking over to talk to you. It’s horrible.

This picture explains it very well.

The thing about this mental model is that it takes about an hour to build up from a cold start (first thing in the morning, after lunch or after a meeting). Thankfully that’s not the case after a five minute interruption from a boss or account manager. In that case it takes 10-15 minutes before a developer is back “in the zone” with a repaired mental model and ready to write some more code.

That’s still not great—we only need 4 or 5 small interruptions for an hour to be lost.

Scheduled meetings don’t bring the mental modal crashing down the way smaller interruptions do, but they have a significant impact. We know the meeting is taking place so we can stop where there’s a natural break point in our work and prepare for the meeting. Not such a huge problem there.

Where it becomes a problem is if the meeting is scheduled for an hour or so after lunch or arriving in the office. Remember that it takes about an hour to be in a position to write code after a longer break. Combine that with the fact that nobody can write much code in less than an hour, so anything that leaves a developer with less than two hours is probably going to mean it’s not worth the effort to get started only to stop and have to get started again afterwards.

There’s one more thing, a theory by developer come venture capitalist Paul Graham called Maker’s Schedule, Manager’s Schedule. In it Graham posits that managers are on a different schedule to makers and that is the root of the problem. Interruptions are the symptom.

It’s a good article and well worth reading. I feel it’s well summarised by two early paragraphs:

Most powerful people are on the manager’s schedule. It’s the schedule of command. But there’s another way of using time that’s common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started.

When you’re operating on the maker’s schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in. Plus you have to remember to go to the meeting. That’s no problem for someone on the manager’s schedule. There’s always something coming on the next hour; the only question is what. But when someone on the maker’s schedule has a meeting, they have to think about it.

The upshot of all of this is that developers often end up working late at night when there is no chance of an interruption and we know we can really get stuck into a project. Obviously this is not ideal. Developers are no more able to cope with a lack of sleep than anyone else, especially as we get past our twenties.

Reducing interruptions

So what practical measures can we take to alleviate this?

Toby Osbourn has written a fantastic article on the subject of small interruptions and one of the things he highlights is the need for developers to turn off the interruptions we create ourselves like having our phone on a stand under our monitor, distracting us with every text, call, tweet and whatever other notifications it has turned on.

Desktop notifications need to go too. Close that email client and get rid of any browser tabs that aren’t related to the task in hand.

Here at The Tomorrow Lab we have a headphones rule. If a developer has headphones on or in both ears they cannot be disturbed. If only one ear has music then they can be disturbed about work. It’s been in place for a good while but for 2015 we decided to formalise it in the form of a poster on the wall, and you can download it to print if you like!

Another thing Osbourn suggests is moving somewhere else such as a coffee shop or working from home. Thankfully here at The Tomorrow Lab we can work from home frequently but moving out of the office is not something that would work for us over extended periods of time. There’s a lot of collaborative work with other members of the team on design, digital marketing, sales and with each other that we need to be in the office for.

The key thing for me though is communication with interrupters. They will never know how they affect our productivity unless we tell them. They spend all day doing their job and aren’t going to find out via telepathy that what they are doing is having a negative influence on how we do ours. Another system we are prototyping here is a timetable or quota of time when everybody has to stay away from developers unless there is a serious problem with a live site. We can’t impose this on account managers and directors so we need to work with them, effectively communicating why such a system needs to be in place and how it benefits the whole company.

That’s all fine for small interruptions, what about planned meetings? We can’t just take a laptop to a coffee shop to avoid meetings we’re supposed to be at. Meetings are a necessary evil. (Granted they are usually last twice as long as they need to which is a separate issue.)

To be honest we’re not sure the best way to tackle this one. We conducted an internal survey asking 4 questions:

  1. What time(s) of day do you feel most productive?
  2. What time(s) of day would you rather have meetings at?
  3. What/who are the worst interruptions you have to deal with?
  4. Anything else you want to say on the subject of being interrupted?

The initial feedback would suggest we’re not going to keep everyone happy when scheduling meetings but there are some “hotspot” times i.e. times you don’t dare touch when organsing a meeting. These hotspot times are in addition to the first couple of hours in the morning and after lunch. On top of that we aren’t robots working in The Tomorrow Lab so we each have different start times and lunch times.

I think the best we can hope for is that nobody ends up feeling like they’re always in meetings right when they are most likely to solve a hard problem.

How to deal with interruptions when they happen

We’re talking about short interruptions here, the unplanned type. They will happen—hopefully less than before—but they will happen, and the aim when dealing with them is to preserve the structural integrity of the mental model as much as possible.

First of all split up the main problem into a list of smaller tasks, so instead of thinking something like, “Now where was I with the progressively enhanced accessible modal dialogue”, it’s more like, “Now where was I with updating the aria-hidden attribute”.

Secondly learn how to answer the interrupter with something polite along the lines of, “I can’t look at it right now, send me an email to remind me and I’ll get back to you as soon as I can.” People will soon learn there’s not much point in interrupting you when they’ll just be going back to their desk to type out the same thing they were trying to tell you.


Interruptions are a serious problem, they cause a huge amount in lost productivity, ergo money, and can make it very hard to get anything done. Working in a company where interruptions are guaranteed and nothing can be done about it is very demoralising. On the other hand, working in a company (*cough* like Tomorrow Lab *cough*) where you’re left to get on with your work is fantastic. It makes a developer feel like they can achieve something, it makes us look forward to going into work, it makes us feel fulfilled at the end of each day.

Developers don’t wear headphones because we enjoy music more than anyone else, it’s because headphones shut everything out and give us the mental space we need to build a very complicated model. (A lot of us view open plan offices as the worst invention of the 20th century!)

If you’re an interrupter and you get a terser response than you might have expected please don’t take it personally. We’re just aware of the model starting to loosen at the more precarious points and are getting frantic about the need to get back at work.

If you’re a developer and you’ve discovered some novel or interesting ways to reduce and/or deal with interruptions, please let us know in the comments.