
Programmer, interrupted (2013) - joshka
http://www.gamasutra.com/view/feature/190891/programmer_interrupted.php
======
infodroid
FYI the original article has much better readability, formatting, and
references: [http://blog.ninlabs.com/2013/01/programmer-
interrupted/](http://blog.ninlabs.com/2013/01/programmer-interrupted/)

~~~
j_koreth
Can mods change links to this?

~~~
moonshinefe
Seconded, this is way, way easier to read and actually has references in it.

------
partycoder
I write down my thoughts so if I get interrupted I can resume from where I
was. Then, I try to encourage people I deal with to use the issue tracker as
much as possible.

"Hey, how is this task going?" -> go to JIRA

"Hey, are you blocked?" -> go to JIRA

"Who is working on this?" -> go to JIRA

Then I check JIRA when I have the time.

~~~
CaptSpify
I hate jira, but I agree with your point. I always have notes that i can
reference.

More to reference = less time to get back up to speed

~~~
Bahamut
Could be worse - you could be using Rally.

~~~
XorNot
Or a giant board of post-it notes.

------
failrate
Some days I can barely even get started working, because I am already
anticipating interruption. Wearing headphones doesn't help. I think it should
be a clear social signal, but other people do not. In fact, they talk to me as
if I can hear them (I cannot) and have to repeat whatever their introduction
sentence was when I finally take them off. Why is this normal?

~~~
jdiez17
One way to do this would be to buy (e.g) a bunch of white caps and tell your
coworkers to wear them when they need to concentrate, and to not disturb
others when they are wearing them. I know of at least one company that does
this and it works well for them. You can also do this with headphones, just
tell your coworkers politely.

------
AdieuToLogic
This phenomenon is not constrained to programming. It's sometimes referred to
as flow[0] and has been documented as taking somewhere between 15 and 20
minutes[1] to regain after an interruption.

Programmers may be more sensitized to its disruption than most due to the
nature of the work, but the net effect is the same. If a person is required to
concentrate in order to perform their job, interruptions will cause
performance to degrade.

0 -
[https://en.wikipedia.org/wiki/Flow_%28psychology%29](https://en.wikipedia.org/wiki/Flow_%28psychology%29)

1 - [http://grahamchastney.com/2011/10/axiom-interruptions-
cost-2...](http://grahamchastney.com/2011/10/axiom-interruptions-
cost-20-minutes/)

------
ww520
I found this help explain to others how programming work.
[http://heeris.id.au/2013/this-is-why-you-shouldnt-
interrupt-...](http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-
programmer/)

------
moonshinefe
The article makes some good points, and nobody likes constant interruptions
and context switching. Especially in particularly complex parts of the coding
process. I also agree that it often takes ~10 minutes after a significant
distraction to get back into things.

I think non-programmers could definitely benefit from this article. But I also
think it's a two way street and there are certain steps you can take to
minimize the damage done. Some things I at least try to do:

\- This may not go over well at everyone's companies, but just being honest
with your coworkers sometimes. Send a message or email indicating you need to
put your head down for a while to address priority tasks, and that you'll be
logging out of Slack/IRC/whatever and can be contacted by email if anything
urgent comes up. A healthy work environment should allow for it.

\- If headphones on is a 'signal' to others not to bother you, just politely
mention it to them if they keep interrupting you during. Invite them to email
you with any non-critical issues and you'll get back to them when your higher
priority work is done.

\- Getting knocked out of the "zone" and it taking 15 minutes to get back...
this definitely happens. But most meetings are scheduled. If your coworkers
know your signal not to be bothered unless it's important, you can then work
around the scheduled meetings. Do the less complicated coding tasks if
possible leading up to the meeting so you don't need so long to get back in
the zone after. If that isn't happening, at least keep a text editor open and
jot down some notes to remind you of where your thought process was. A
checklist is even better.

\- Use bookmarks. A lot of editors / IDEs have them, and if you bookmark all
the areas of interest, if you do actually have come back and 'get back in the
zone' without notes, you can at least hop around the pertinent areas quickly
to regain context.

Anyway, just some thoughts on what's helped me at least reduce that issue. I'm
not sure it can completely go away.

~~~
jakobegger
While interruptions are bad for your own productivity, they may really boost
the productivity of the person doing the interrupting. I'd rather have a
junior dev interrupt me when he needs a quick answer to a question instead of
spending an hour googling and copy-pasting a dangerous hack from Stack
Overflow. What's the point of sitting in an office when you don't collaborate?

The trick I use to reduce the effect of interruptions is to not respond right
away if I'm in the middle of something. I just say "I'm in the middle of
something, let me just finish this!" and then I get back once I'm at a point
where my "mental load" is reduced.

~~~
cema
I think I have to reluctantly agree. Collaboration is a huge part of a
developer's professional life.

~~~
sotojuan
More than many want to admit.

------
bbarn
I see so much of this arguing against being interrupted, or context switching.
I suffer from it, most of us do, but I think everyone's trying to solve the
wrong problem.

The problem isn't that we get interrupted and our concentration suffers, it's
that we keep trying not to be interrupted. Good developers are people who knit
things together. The myth of the savant coder who just cranks out beautiful
amazing stuff has to die. What makes a great developer are soft skills, and
gluing together other code, not cranking on something for hours alone. Just
like every other industry, you have to deal with other human beings, email,
and the rest of life. We don't NEED to be cranking out code for hours on end,
we need to integrate and interact with other people.

~~~
mattnewton
I think there is a time and a place for both modes (and it also depends on
personality). What's wrong with private exploration / development after a
period of research on the problem?

~~~
Roboprog
This makes a good case for having both some "core hours" for sharing, and some
"crank stuff out" time.

~~~
bluejellybean
I think a 1 on 1 off day could be interesting. Normal week but every other day
is worked from home in quiet, maybe include some IRC.

------
Osiris30
Charlie Stross has also Chimed in on this:
[http://www.antipope.org/charlie/blog-
static/2016/08/writer-i...](http://www.antipope.org/charlie/blog-
static/2016/08/writer-interrupted.html)

~~~
dasmoth
This makes a really interesting comparison.

It's noteworthy that (fiction) writing hasn't gone down the "collaboration is
part of the job"/"don't trust the coder hacking away by herself" wormhole that
seems to be swallowing the software world at the moment.

------
vendakka
This is something I definitely agree with. I've sometimes found that taking a
few seconds to cache state in a notepad before responding to the interruption
helps a lot. Having times of day dedicated to meetings also helps reduce
fragmentation. At the risk of being overly self-promoting, solving problems
with fragmented work days is something my cofounder and I are working on now
with TimeFerret ([https://www.timeferret.com](https://www.timeferret.com)).

------
CarolineW
Also discussed at length here:

[https://news.ycombinator.com/item?id=9515613](https://news.ycombinator.com/item?id=9515613)

------
mjevans
The first part of this seems to well describe the problem.

Then it looks like it goes in to a sales pitch for 'solutions' to that
problem?

------
Kenji
This might be somewhat off-topic but do we really always have to conduct a
study first before we can acknowledge and solve a problem that is obvious if
you have any common sense?

~~~
cholantesh
Seemingly common sensical notions can be wrong. The hope is that empirical
study is less so.

~~~
Kenji
I agree with that notion completely, but I think one can overdo it and get
lost in pedantry and bureaucracy. Imagine you would program your software and
do a benchmark test on every single line. That is what it feels like.

~~~
sanderjd
I've always liked the warning to not let perfect be the enemy of good. But I
also think it's easy to rationalize too much guessing and too little evidence
gathering. I find it a really hard balance to strike.

------
maerF0x0
@joshka, add a 2013 tag

------
ghostintheshell
good mate

------
libliflin
I'll offer the dissenting opinion.

Let's say the ratio is worse: 10x less productive; 10x more error prone.

I will _still_ interrupt my coworkers who are working on the wrong thing.
1/10th of a thing that makes 100x more money is better than 1x of a thing. I
_want_ that nonsense flushed from their working memory.

I understand that makes me a micro-manager; but I'd rather have more
productive coworkers that help keep our business alive. My coworkers
appreciate it (most of the time) because it helps them grow.

~~~
MaulingMonkey
> I will still interrupt my coworkers who are working on the wrong thing.

How common is this, how can you tell, and why were they working on it in the
first place? How often do you interrupt them when they were working on the
right thing, as an unfortunate side effect?

I've wasted time and energy on dead ends and it is one of the most frustrating
things, even when it was understandable, sanctioned, and a _desired_
exploration of the problem space. I'm all for trying to avoid unnecessary
waste.

> I understand that makes me a micro-manager;

That this is your understanding would concern me greatly, though. I'd rather
be macromanaged - have the big picture explained to me, in a way that I can
understand and buy into, that I can then approach in the ways that best suits
my own talents and abilities. Where I can contribute my own insights and ideas
to the collaboration, where I don't start working on the wrong shit in the
first place.

Not just... along for the ride, like floatsam, being told I've been doing it
wrong a hundred times and do it this other way because I've been told to,
without any deeper insight to correct the underlying problem. Or even worse,
without any real underlying problem in need of actual correction.

~~~
clifanatic
> how can you tell

He can tell because he's a manager, and if he wasn't always right, he wouldn't
have been made a manager, so he's always right.

