Everyone that works in an office (especially in an open office space) will have to deal with daily distractions, and software developers are no exception. It is well known that distractions are harmful to your productivity but it has a more worst effect on developers.
Lack of Daily Productivity
The average lost time is 23 minutes per major interruption according to studies conducted by Gloria Mark, Professor in the Department of Informatics at the University of California, Irvine. For developers, it is far worse because you can’t easily go back to where you were right before an interruption. You need to get into the mindset for development and then slowly trace back to where you left off. This can easily take more than 30 minutes.
You’ll be lucky if there was only one interruption a day. Realistically, there will be several interruptions and next thing you know more than half the day is gone and you didn’t get much done.
Increase Number of Bugs
Getting back to the exact state of mind you were at right before an interruption is nearly impossible. Because of this, some information might get lost before you put it into code. And when something like such happens, it can lead to bugs. For example, you might forget about that edge case with 0.1% chance of occurring when you come back from an interruption because it is so insignificant.
Increase Stress and Frustration
Imagine how frustrating and stressful it is to spend an hour running through logic in your head and you finally reached the point where you understand why something is happening. You have reached the point where you understand why this array has twenty elements and what those elements mean after tracing through ten levels of stack calls. Then suddenly, someone walks up to you and ask if you received their email about X that they just sent to you five minutes ago. Now, when you get back to doing your thing, the first thing that comes to your mind is, “What do these elements in the array mean again?”. You are almost back to square one and lost a lot of the progress made in that one hour.
Planned Interruption vs Unplanned Interruption
Unplanned interruptions are times when a coworker or your boss comes up to you and ask you about something or to do something (usually a small task). Planned interruptions are like meetings that have a set time and place. While unplanned interruption can throw a developer off for half an hour or so, a planned interruption is worst.
Paul Graham wrote an excellent article that talks about a maker’s and manager’s schedule that I found to demonstrate the cost of planned interruption perfectly. To avoid any possible confusion, developers fall under the maker’s schedule.
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.
For someone on the maker’s schedule, having a meeting is like throwing an exception. It doesn’t merely cause you to switch from one task to another; it changes the mode in which you work.
I find one meeting can sometimes affect a whole day. A meeting commonly blows at least half a day, by breaking up a morning or afternoon. But in addition there’s sometimes a cascading effect. If I know the afternoon is going to be broken up, I’m slightly less likely to start something ambitious in the morning. I know this may sound oversensitive, but if you’re a maker, think of your own case. Don’t your spirits rise at the thought of having an entire day free to work, with no appointments at all? Well, that means your spirits are correspondingly depressed when you don’t. And ambitious projects are by definition close to the limits of your capacity. A small decrease in morale is enough to kill them off.
What You Can Do to Make Interruption Less Costly
Interruption is inevitable so instead of fighting it, it’s better to embrace it. Start documenting your thought process even though it might seem like a hassle. You’ll be glad you did when an interruption occurs, and you were able to get back on task quicker than before.
Wear Headphones
Ever wonder why you always see developers having a pair of headphones on hand? There is a reason for that. To develop software you need to be in a deeply concentrated state or “flow“, which is impossible to achieve in a noisy environment. Ironically, open office spaces are commonly where developers will work in, which means noise and distraction.
There are many types of headphones out there, so make sure you get the kind that blocks out sounds. Ideally, you would want to get a pair of noise canceling headphone (one of the best investment I’ve made), but if that’s not an option any closed back or in-ear headphones would work too. Listening to music does more than blocking out distraction, it can give you a productivity boost as well.
Help Others Understand Why Interruption Is So Detrimental to a Developer
Non-technical people don’t understand how technical people work. They think dropping by your desk and asking you a simple question would not do any harm. So, it is up to you to show them that is not the case. Now here is the hard part, how exactly can you get them to understand.
Use Analogies
Analogies are common when you are trying to explain something to another person who doesn’t understand it. You try to put it in a way in which they would understand it. Here is a great example using a sleep analogy.
“How long does it take for you to fall asleep?” “X minutes” “Now imagine that when you are close to falling asleep, someone walks in and interrupts you, how long will it take you to fall asleep now? Those few seconds you had left, or will you have to start again to ‘sink back’ to where you were?” “I’ll have to start again” “Great. Same thing. Just like falling asleep, it takes me a while to ‘sink’ into focus mode, and it takes me a while to get back to it once I’m interrupted, except that I also forget half of what I was doing.”
Show Them This Comic Strip
Jason Heeris – Image Source
Often comic is meant to be funny. But in this case, it strikes a little too close to home. If you are having trouble explaining to someone how your minds work when you are developing software showing them this comic strip might help.
I hope this post was helpful to you. If you found this post helpful, share it with others so they can benefit too.
What is your take on interruption towards developer? Are you a software developer? If so, what are your experiences with interruption?
Are you a manager of software developers? If so, how do you deal with interruptions toward your developers?
To get in touch, you can follow me on Twitter, leave a comment, or send me an email at steven@brightdevelopers.com.