
Programmer Interrupted - Off
http://blog.ninlabs.com/2013/01/programmer-interrupted/
======
grecy
At my last company us developers complained that we were getting interrupted
too much, so the boss asked us to keep a list of interruptions. By lunch on
the first day we all had 3+ pages, so he believed us and we implemented the
following:

Each week, one pair of programmers would be designated the "consulting
developers", and a big sign would be put above their desk. They were the
_only_ developers that could be interrupted for the week, allowing the rest of
us to get a lot of work done. If the consulting developers needed to ask
something of other developers, we tried to save it up for lunch, as we mostly
all ate together anyway.

This made an enormous difference to our productivity, which everyone in the
company took notice of when the number of "development days" we got done each
week increased dramatically.

At the start we thought of "sacrifice one for the good of all" and we didn't
look forward to our turn. As time went on it actually turned out differently.
We usually enjoyed the "consulting" time as it meant a break from the routine
of working on endless tickets, and it also kept us in touch with what the rest
of the company was doing with regards to deploys, environments, configs, etc.
etc.

AFAIK they still do it today

~~~
MatthewPhillips
Don't you find it distracting listening to people ask the consultants
questions all day? Often times about projects you work on? I don't think there
is any cure for interruptions other than no at-desk meeting rules or private
offices.

~~~
mtrimpe
> I don't think there is any cure for interruptions other than no at-desk
> meeting rules or private offices.

A simple feedback mechanism for this would get us quite far already. Just
something that will glow red for 'dont disturb,' orange for 'only if you have
to' and green for 'go right ahead.'

If someone wants to make (a Kickstarter for) a simple ball that does this I'll
gladly transfer my domain names interruptiball.com and interruptaball.com to
you by the way. ;)

~~~
X-Istence
I've thought about doing something like this, and tying it into a web based
services so you can see what state everyone is in.

Might work on this some in the near future, but I am not sure if I want to
commit to a Kickstarter ;-)

~~~
mtrimpe
If/when you do... just ping me and I'll hand over the domain names ;)

------
hkmurakami
I'm a PM, and I consider it my most important responsibility to prevent
interruptions from reaching developers. By redirecting inwards-bound
interruptions to myself, I've probably reduced developer interruptions by 80%
since I started.

What I've found is that the typical developer/engineer is really bad at saying
"no" or "not now" to others. The solution then is to work the other side
(sales, marketing, etc) to interrupt someone else (me) instead. Even if it's a
relatively simple technical question from sales, I can convert the in-person
active interruption to a passive email notice (at the very least).

The typical office environment (and system) is not productive, so at this
point it's up to the individuals to reduce the impact of the system on the
team's productivity. (which is a sad reality...)

~~~
DrJokepu
Curiously enough, in my experience, the vast majority of interruption I
receive is not from "external sources" but rather from other developers,
typically junior members of the team seeking advice or guidance. I wonder how
you would address that?

~~~
epochwolf
I sit right next to a tester and he is a constant source of distraction.

~~~
skrebbel
Did you ever bring it up?

~~~
epochwolf
Several times. I was told to allow him to interrupt me. :/

------
MattRogish
I wonder how much money is wasted via lost productivity due to open office
plans. On a per-year per-programmer basis private offices are not very
expensive.

[http://blog.fogcreek.com/the-price-of-dev-happiness-part-
two...](http://blog.fogcreek.com/the-price-of-dev-happiness-part-two/)
<http://www.joelonsoftware.com/items/2006/07/30.html>
[http://www.joelonsoftware.com/articles/fieldguidetodeveloper...](http://www.joelonsoftware.com/articles/fieldguidetodevelopers.html)

~~~
majormajor
I've been a developer with a private office and I've also been on a small (<
10 person) team in an open office plan. Give me the open office any day. If
there's a side conversation not of interest to me, I tune it out. But
frequently there are ones that _are_ of interest to me that I'm able to either
contribute to or learn something from. It's great for group troubleshooting of
sudden issues, too.

~~~
mutagen
I suspect the two parent comments (and several more here and every time this
topic comes up) point to a fundamental difference between various people, some
are more productive in silence and solitude and some thrive on the
productivity around them.

While it might sound like the difference between introverted and extroverted,
I suspect it isn't quite as simple. It very likely also depends on the job to
be done (memory load), the content and quality of surrounding conversation and
more ephemeral factors like company culture.

I suspect it also affects how well things like pair programming work out,
conversations about it often elicit quite polarized viewpoints on the subject.

~~~
MattRogish
I really want to learn more about this.

I think there's some level of cognitive bias here with respect to social
interaction preferences.

I certainly prefer to hang out with folks in a social setting compared to
sitting in an office all day. I understand folks who prefer to do this in a
work environment from a camaraderie and a "I'm not in a cave" perspective.
That's totally fine and understandable.

But from a real, practical standpoint - are folks that "prefer" to be in an
open setting _actually_ more productive than those not?

What type of programming lends itself better to a distraction-filled
environment?

How does "culture" fit into the distraction equation, other than "we tolerate
more distraction-killing productivity here than elsewhere"?

(We have a chat room where we try and put all side discussions, so folks can
virtually "overhear" conversations and chime in if applicable).

I concede that there could be some people who will get so antsy in an office
all day that the mosh pit-style work environment "feels" better. I'm not
discounting that some folks prefer to be in a noisy environment. I just
question whether or not they're actually more productive there or that the
organization is better off _in total_ with a noisy environment.

The difficulty I have is that I cannot find any studies that show that a
distraction-filled environment creates more knowledge-worker productivity than
a quiet one. Mountains of studies scream the opposite.

Personally, I'd rather find other ways to channel that ADHD energy in a more
productive manner. :D

~~~
majormajor
I would guess it has a lot to do with the team, especially the size but also
the level of commitment to the work of the other devs. I've never been around
a loud team or in a noisy environment (I'm not counting the sound of other
people typing). Blocking out 50 conversations in a day, many of the much more
inane or pointless, may be much harder for me than 5 business/tech-related
ones. But I've never had to try to deal with that.

Though I doubt that it would be much different for me, personally, because
when I'm really in the middle of an interesting problem and cranking stuff
out, I just don't notice background noise in the same way I don't notice that
it's suddenly four hours later... I mean, maybe I'm just lucky in that, but my
own coworkers have never expressed frustration with the environment either, so
I don't know just how rare it is. (So I guess the key thing is that if the
environment is getting to you, don't just keep it to yourself!)

I also have a (maybe overly cynical?) hunch that in addition to the "ease of
distraction by external noises" spectrum there's also a "desire to goof off
more if nobody's going to notice" spectrum that comes into play. (He says, as
he posts on HN in the middle of the day, heh...)

I've never bothered to look into research on it, but I also don't see any
trends of companies with private offices outcompeting ones without. I know the
output of the team I was on at the company I worked at where I had a private
office was not great, but there are other factors involved there too, of
course.

I also think the rotating "consulting developers" idea from grecy above sounds
like a pretty good idea, regardless of office layout.

------
fennecfoxen
I would like to point out in my experience that I've found pair-programming to
provide excellent interruption-recovery capabilities. Even if both people in
the pair are interrupted, they're very good at getting each other back on task
and filling in the gaps left in each others' trains of thought.

(Disclaimer. The broader applicability, appropriateness, and overall
desirability of pair programming, Extreme Programming, and other agile
methodologies, or any of the other implications thereof, are not addressed in
this post. Void where prohibited. No warranty, express or implied.)

~~~
lawnchair_larry
I see it as one giant interruption. I'm not sure what I dislike more, "pair
programming" or "open concept".

~~~
zaptheimpaler
As a college student, I do a lot of pair programming. IMO, the efficiency of
pair programming comes down to how well matched the two are in skill, and how
well they can communicate with each other. Depending on those two variables,
it can be much more productive than a single programmer, or a huge roadblock
to getting anything significant done.

~~~
fokov
The problem is the business isn't paying for a single programmer's value, it
is paying for two. The only time I have known pair programming actually worked
pretty good was when a senior would take a junior under their wing when the
junior was first hired. This would facilitate quick ramp-up for the junior to
know all practices and the vast amount of things that are not documented (or
updated). Keep in mind this only lasted a couple of months max, and not
necessarily every day.

------
houshuang
Most of the comments are discussing interruptions in general, and could have
been posted on any article about programmer working situation etc, but I think
some of the most interesting in this blog post is the attempt to measure
cognitive/memory load (both retrospectively, in a research situation, and
perhaps eventually live).

Imagine something like the ubiquitous sleep trackers for mobile devices which
can track your sleep pattern, and both give you feedback on how you sleep, and
also select the best time to wake you up within a certain boundary.

Could we imagine something similar for engineers? We already have very rough
tools to provide feedback on productivity, like RescueTime, but a context-
aware tool that can model cognitive activity based on edits, switching from
one function to another, viewing two files simultaneously, git commits, etc,
is far more advanced.

Perhaps if you wanted to ask a programmer a question, you could ask for him to
be interrupted sometime during the next half hour, and the system would choose
the time where it would be least disruptive?

And I'm also interested in the discussion of ways in which it would be easier
to remember/reestablish context. I wonder if some of this is transferable to
other domains, for example deep academic "knowledge work" - working with
annotated articles, several windows of notes, trying to synthesize ideas etc.

------
danso
I find it hard ever to program for hours straight, no matter what the external
stimuli is. However, I've found that test-driven development has worked to get
me back on task after I've strayed. The physical act of just entering in "rake
test" and seeing "Tests passed" can be enough of a trigger for me to get back
into coding...and if I've left some broken tests for me to fix, I have a much
easier time remembering what I needed to do next...without the extra overhead
distraction of finding my to-do list.

Of course, one could argue that the monotony of writing tests is what keeps me
from being fully engaged to begin with :)

------
rachelbythebay
I saw an interesting situation at Google many years ago. There was a "bullpen"
in which 8-10 people sat. That was for my team, a bunch of pager monkeys with
a rotating on call rotation. We were operation-oriented as you would expect.
Not too far away, the developers for one of our services had their desks.

At least one of the ops people on my team and at least one of the devs on the
other team were, well, loud. I don't know if they had hearing issues or what,
but they were significantly louder than most people. You know the type. That's
just how they are.

Immediately over the cube-wall from us on the other side was a bunch of
technical writers. They couldn't get any work done because of the racket from
us. We got complaints. My boss used to keep a tally on one of his whiteboards.
This is the thing where you go |||| and then put a slash across for the fifth
for those who aren't familiar (is this a local culture thing?). I think they
ultimately tried to get moved to another building, _away_ from the people they
supported.

On a _third_ side, there was a bunch of project managers. This was back in
2007, so OpenSocial was the "big thing" then. So we had to deal with the
blathering coming out of them most afternoons: "what if this person is friends
with this person on this service, but isn't friends with this person on this
other service, and then this third person shares this thing to the second
person, does the first person get to see it?"

I'm surprised ANYTHING got done there. Come to think of it, that might explain
a few things. Another team up in that same space was the Lively group, and
everyone knows what happened with that project.

~~~
swah
Did you try telling the guys they were loud?

~~~
rachelbythebay
Those guys didn't listen when I told them our servers were being hit too hard
due to <thing> and <other thing>, so I don't imagine that raising a purely
social/meatspace concern would have done any good.

------
dickeytk
Even though I rarely use headphones, the idea that there are actually
companies that don't allow engineers to work with headphones blows my mind. I
thought I worked in some pretty strict places, but never anything that
extreme.

------
_Benjamin_
I don't understand why companies don't try an approach more like what
Universities provide their students. If you need a quiet place to study, you
can go to the library, where you may often find private rooms for even more
seclusion and quiet. If you prefer someplace busier, try the student union or
the food court. Right after getting my CS degree, my boss pointed me towards a
desk in an open office environment and I was supposed to start cranking out
value for the company in that one environment. Sometimes I like it, I like the
impromptu conversations with fellow developers. But other times I need to shut
out all distractions and outside noise and movement but I don't have that
option.

~~~
K2h
1) As part of a budget I am charged for the floor space that my team uses in
the facility. I would welcome open space and closed space, but don't have the
space in this facility to make closed spare look like more than a closet -
something most won't respond well to working in.

2) Many tasks (especially engineering that deals with work in the physical
domain) require tools, items, equipment of more than just a computer. While we
can do shared lab space for development - it does get tricky when you need
certain hardware or test setups to do design/work.

It did take me time to adjust outside of academia too.

------
KeyBoardG
Unnecessary or poorly planned meetings are probably the biggest interruption
here. God-forbid the pre-meeting meeting. I tend to stick to small, mundane
work until a part of the day where I can focus for while. You can get more
done instead of frustratingly failing to get deep into larger projects.

~~~
geophile
Our scrums are typically 1-2 hours long, due to an accumulation of topics for
"after-meetings". What a soul-sucking waste of time.

~~~
vpeters25
You guys seem to be using the daily scrum as a planning meeting, I would
suggest to add all the after-meeting stuff to the backlog and discuss them in
the next sprint planning.

Daily scrums should not take longer than 15 mins. A good scrummaster will keep
them under 5 mins in average for a 12 member team.

One thing I usually do when daily scrums start getting out of hand is to
politely mention long meetings as a blocker to get my job done. After
repeating the same for a few days it will start to sink in...

------
jgj
Whenever possible, I delay interruption by taking 15-30 seconds to cache my
current train of thought while holding up a "one moment" finger at the
perpetrator. Just distilling my train of thought into a sentence or two, or a
mnemonic device of sorts, helps me get back into what I was doing quicker.

~~~
muhuk
This would also communicate you are being interrupted and it's not nothing. I
would expect it to at least filter the stuff that can wait.

------
noknockers
The interruption issue has plagued me for the last 10 years. Firstly working
at home with flatmates or wife, then with children and now at an office next
to the marketing team.

Instead of trying to fight the interruptions themselves, I decided to try and
become better/faster at context switching by training myself to
compartmentalize the jobs on hand (programming/helping kids/answering
questions).

It took a while to figure it out and i'm still getting better at it, but so
far it works pretty well and I can jump between contexts much better than i
could before. When I get interrupted, I'll take a snapshot of where i am,
store it away and 'switch' to the new issue.

------
strictfp
When talking about productivity, it's important to acknowledge the difference
between speed and progress. While working uninterrupted is great for
development speed, it might also lead you down the rabbit hole, working with
irrelevant features of your liking. I find that regular interruptions helps
setting a new course before going too far in the wrong direction.

This is one of the reasons why agile methods work so well. Small tasks limits
the scope of concentrated work, reducing the risk of going astray. Pair
programming offers a watching party, who can guide and direct while you are
busy tunnel-visioning some small method.

------
ericHosick
The best work I've done is when I start in the morning and go for a break only
to see it is now dark out.

------
agentultra
Working from home can be the worst (especially so if you have kids). There is
nothing more frustrating than not being able to concentrate on a task for more
than 45 minutes when your, "warm-up," time is about half that time...
effectively giving you 20-some-odd minutes of actual work at a time. In fact
it can be down-right torture.

The best, "snake-oil," solutions I have are:

1\. _Well-delineated boundaries for interlocutors._ This means scheduling my,
"off-limits," time and communicating those boundaries to the people around me.
Concessions are made by appointment and I try to plan out my time a few days
to a week in advance depending on how busy I am.

2\. _Write everything down._ I try to be methodical about this but I am
characteristically spontaneous and disorganized. Therefore I keep notebooks
nearby when I'm not at the computer, I have a whiteboard near my computer, and
I have a very organized filing system on my computer where all of my thoughts
eventually end up. I find that having different mediums that I can switch
between very helpful -- many an algorithm has been conceived of in the shower,
doodled on a piece of graph paper (I'm a very visual thinker) over breakfast,
and eventually compiled before lunch after I've finished with my emails for
the day. Having record of it in multiple places seems to reinforce my memory
and after reading this article I suspect I now have an inkling as to why.

3\. _Never leave a thought unfinished._ This can be frustrating both for
myself and my spouse sometimes when it's near the end of the day and I'm only
half-way through something important. However I cannot enjoy myself and let my
mind wander if I have some half-finished thought still rummaging around in my
head. It's easier to let the mind relax and be creative if you can finish each
thought... even if it's simply writing the rest of it out or hammering out all
of the test cases you can think of. As long as there is some record of it in
its entirety my mind seems to be able to be satisfied with it and leave it
alone. It also helps so that when I get back to work on the problem that I'm
able to get up to speed and not having to, "finish my own sentences."

After reading this article I began to wonder if there were any cognition-
enhancing tools that are integrated with popular development environments for
assisting programmers in remembering where they were in a large refactoring or
what they still have yet to do in various locations of a code-base, etc.

~~~
ww520
I think working at home doesn't mean you work while babysitting your kids. It
should be like working at office, minus the commute and seeing your
colleagues. If you need to babysit the kids for a while, do that as it is then
make up for the development time later on.

I found org-mode to be great in tracking todo items, general note taking, and
organizing thought.

~~~
agentultra
org-mode is my go-to, I use it for quite a lot of stuff!

------
pbiggar
This might not be the appropriate thread for a job post, but if you are the
kind of programmer who likes library voices, quiet concentration, and no
interruptions, this is something we're trying to cultivate for ourselves at
CircleCi. Job post here: <http://news.ycombinator.com/item?id=4993738>

------
rkb
Interesting blog post presenting different types of memory and the use of
these types by programmers. However, the introduction of the piece feels a bit
off, and the overall coherence is somewhat lacking. It is as if the writer was
being interrupted continuously while writing it...

------
stevewilhelm
Are there any studies that quantify the impact of Google Talk on programmer
productivity?

------
guard-of-terra
I seem to be much interruption-tolerant than all those articles imply. On
other hand, I'm lucky if I get any code to write at all, because it's mostly
communication, planning, system support and debugging that consume time.

------
follower
I found this section of the article of particular interest:

"A code narrative is an episodic memory aid that helps a developer recall
contextual details and the history of programming activity."

I created Labradoc (<http://labradoc.com/>) to encourage a form of manual
"code narrative" (e.g. a form of development journal).

Here's an example from one of my personal projects:
<http://www.labradoc.com/i/follower/p/android-arduino-handbag>

I find it really valuable for context-switching between projects.

------
potomak
I think Pomodoro Technique works well against interruptions or at least
against unintended interruptions. That's why I made and use regularly
Tomatoes[1] pomodoro time tracker (now I'm on my long break).

[1] <http://tomato.es>

------
n3rdy
Do these numbers get inflated for a programmer with ADHD?

I find it takes me much longer to get back on track after interruptions. I
work from home and deal with a ridiculous amount of interruptions. After 9am,
I usually have to just give up for the day.

------
rjzzleep
there you go, scientific proof that the whole microsoft enterprise stack is
counterproductive. every debugging step involves 20 distractions.

