Why developers hate being interrupted

http://thetomorrowlab.com/2015/01/why-developers-hate-being-interrupted/

by jhildings • 12 years ago

52 21 12 years ago

thetomorrowlab.com

sandstrom• 12 years ago

Excellent post! Two related articles, on office layouts:

- http://www.economist.com/news/international/21637359-how-wor...

- http://www.newyorker.com/currency-tag/the-open-office-trap

bengali3• 12 years ago

thanks for sharing. interestingly, the New Yorker article cites a 1980 research paper and the author states:

Physical barriers have been closely linked to psychological privacy, and a sense of privacy boosts job performance.

I wonder if this is still true in today's internet connected workplace?

bndw• 12 years ago

tl;dr

https://dl.dropboxusercontent.com/u/25009451/ProgrammerInter...

mrbig4545• 12 years ago

I've never found it to be a problem, I guess I must be good at context switching. But then again I'm usually working on 4 or 5 things at a time anyway, so a few interruptions don't seem that bad! I like the break, and then there's the bonus of solving something by not thinking about it.

jasonwocky• 12 years ago

Same here. I work from home and often enough have a 2-year old wander into my office. Talk about random interruptions. But I don't notice skipping more than a beat.

Maybe it's because I don't tend to work with really bad codebases that force me to keep huge mental models in my head while I'm making changes. Or perhaps I'm fast at getting ideas onto paper so that the stuff I need to keep in memory remains small. Either way, the dynamic the article describes is not an absolute, universal thing. There are environmental / behavioral factors at work besides "Developer, Interrupted."

rancur• 12 years ago

random interruptions aren't the problem, it's having to drop de-coupling work in a RTOS that I'm 3 days into when I get a support request that requires me to do the same in a second codebase, and then a phone call about a project I just deployed.

I thought I was just an idiot, now I realize I was at a bad company; but [my inspiration is gone] it's too late for that now

AdeptusAquinas• 12 years ago

Your last point is a truism for me: if anything, having random questions or discussions to break up the dev work seems to imbue me with greater energy. Almost like being briefly forced to think about something different allows me to 'see the forest for the trees'.

zo1• 12 years ago

You're very lucky in that regard. For me, a context switch, especially when I'm working from home, not only throws me off for a few minutes, but also takes away my motivation that has a more than few-minute impact.

Of course, I'm actively working on that, but interruptions don't help. And the more they happen, the more demoralizing they become and it's a vicious cycle.

michaelochurch2• 12 years ago

There's an elephant in the room, as well, which is social status. Impromptu status pings are a show of power ("this happens on my time") and often make a person feel subordinate and demotivated. It's only 15 minutes to recover context if motivation isn't lost, but if the impromptu meeting becomes intense and emotional, then you can lose hours. All meetings cost time at the edges (no one starts a project at 9:50 if there's a 10:00 meeting) but those that are infuriating, stupid, or otherwise unwanted probably do more damage than meetings do if they're useful and rare.

Impromptu status pings, except in a production crisis or in a time-critical situation, shouldn't happen. Any status reporting infrastructure should be regular, legible, and structured and, in typical times, ought to consume no more than 15 minutes per day.

As for meetings, those can be useful or worse than useless, and the problem there is that the usually higher social status of those who schedule them prevents proper feedback on the meetings that don't work or make sense. Just as there's complexity creep in code as features (whether well-thought-out) pile on and kludges and counter-kludges are thrown in, there's complexity creep in management as meetings get thrown on calendars and the people most aware of them not working don't feel comfortable pointing the fact out.

stove• 12 years ago

I wholeheartedly agree and find it relevant to mention PG's article on the subject: http://www.paulgraham.com/makersschedule.html

dllthomas• 12 years ago

"Impromptu status pings, except in a production crisis or in a time-critical situation, shouldn't happen."

I have the urge to weaken that, when the status has material impact on what the ping-er should be doing. If my coworker - superior or otherwise - is trying to figure out what he should be telling our most important customer that's a different thing then him just wanting to know - or worse, thinking it's keeping me on task.

Thoughts from your PoV?

michaelochurch2• 12 years ago

I agree. The first rule is that there are no rules. If you need to interrupt someone to get unblocked, that's different from asking for a general status report. I was talking about the latter.

AndrewKemendo2• 12 years ago

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

I hate to break it to you but this is not a problem unique to developers. "Flow" is not exclusively the domain of developers and basically every workplace I have been in has had this problem in some fashion.

Here is a list off the top of my head of groups of people who hate being interrupted:

Writers, musicians, artists, academic researchers, potters, watch makers, statisticians, athletes, gardeners etc...

Developers aren't the only ones who should be free from interruptions while working. My feeling is that the majority of problems that developers think are unique to them are just classic bad management.

dietrichepp• 12 years ago

I did not think anyone was claiming that this was unique to developers. The article's quote from Paul Graham explicitly mentioned writers, for example.

jbergens• 12 years ago

Every group for themselves ;-) But I don't think musicians and artists usually have bosses and coworkers around as much as developers do. Researchers seems to often have other researchers as bosses which hopefully don't interrupt them multiple time every day. Athletes would probably hate having someone come in every day in the middle of their training session telling them there is a meeting in 15 min but I haven't heard about that happening very often.

AndrewKemendo2• 12 years ago

Well exactly. These are management problems. Insofar as they are unique to the environment they apply broadly - rather than as a discipline.

And yes, most researchers at least in my experience work in the same kind of structure as developers, namely one in which their "bosses" may not be a researcher at all or whose job has moved away from being a researcher for so long they have forgotten how to work.

bitserf• 12 years ago

What's really great is when you're working on something else, someone sends you an email, and then walks over to discuss the email they just sent, because you didn't reply in 30 seconds.

xtrumanx• 12 years ago

I've been teaching myself how to resolve deadlocks occurring in our database and completely removed one deadlock scenario from occurring (it was occurring hundreds of times per day) and reduced another scenario down to about 1 deadlock per day from about 200 per day. It was really hard stuff for me at first (although I think I've got the hang of it by now).

My managers will simply not do anything about the phone ringing on my desk that several other people at the office can handle (including themselves).

On the one hand, I feel like acting like a child and just giving up on the problem I'm currently solving since nobody asked me to do this but on the other hand I know every year during our peak season these deadlocks bring our system to its knees and it doesn't look like anyone else is going to do anything about it (I just got access to the codebase a couple months ago and thought of adding error logging a few weeks ago which showed me the thousands of deadlocks that were happening everyday).

I'm not sure why I even try to help if they don't try to help me.

sukilot• 12 years ago

You have choices:

Do what makes your boss happy with you, for security.

Do what will help you get the next job you want.

Find a niche where they pay you and forget about you, and do what is fun.

thaumaturgy• 12 years ago

Don't work for free.

I don't just mean in terms of monetary compensation (although that too). If you haven't explained the value of your efforts to your bosses, then you should do that. If they can't understand the value of it, or don't want you to put effort into it (or aren't willing to support you while you put effort into it), then you shouldn't do it. Spend the time instead answering the phone -- that's what they want to pay you for -- and keep looking for a better job.

Somewhere up the chain of command is, hopefully, someone who thinks about everything in terms of money. Find that person and explain that the downtime and performance issues cost some amount of money every year. Do the math, come up with some real and plausible numbers. Then explain that you can fix it for probably some other amount of money. Before you go to them, make sure the first number is bigger than the second, otherwise they'll tell you you probably shouldn't be spending your time on it, and they'll be right.

Engineers have a bit of a tendency to focus on technical inefficiencies without giving enough consideration to the human or financial things in a business. The ringing phone might actually be costing the business more money than the deadlocks; some customers hate it when they call up and the phone consistently rings a dozen times or goes straight to voicemail. There might be other things that would be more important than fixing the deadlocks -- documentation tends to be a pretty common ailment.

It's great that you're taking initiative to fix some problems in the company, but be careful about feeling resentment over a lack of support for it if you haven't talked to anyone first to make sure you really should be working on this particular problem to the exclusion of other duties.

And don't do it for free.

mattxxx• 12 years ago

Yea, interruptions are annoying, but you have to learn to get good at them. Communication is the most important part of large software projects, and denying someone knowledge is just going to make the workplace unproductive.

Obviously there are trivial interruptions, but I do not believe that coding in 4 hour blocks is healthy of useful. If you can't start where you left off, you're probably not documenting well either. How is anyone else going to debug that?

Why developers hate being interrupted

Related Stories