

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

======
mrbig4545
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
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
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

------
bitserf
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.

------
mattxxx
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?

------
xtrumanx
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.

~~~
thaumaturgy
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.

------
AndrewKemendo
_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.

~~~
jbergens
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.

~~~
AndrewKemendo
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.

------
sandstrom
Excellent post! Two related articles, on office layouts:

\- [http://www.economist.com/news/international/21637359-how-
wor...](http://www.economist.com/news/international/21637359-how-workers-
ended-up-cubesand-how-they-could-break-free-inside-box)

\- [http://www.newyorker.com/currency-tag/the-open-office-
trap](http://www.newyorker.com/currency-tag/the-open-office-trap)

~~~
bengali3
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?

------
michaelochurch
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.

~~~
dllthomas
_" 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?

~~~
michaelochurch
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.

------
bndw
tl;dr

[https://dl.dropboxusercontent.com/u/25009451/ProgrammerInter...](https://dl.dropboxusercontent.com/u/25009451/ProgrammerInterrupted.png)

