
Why You Shouldn't Interrupt a Programmer - libovness
http://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer
======
calineczka
Once upon a time I was working with a very challenging legacy code and I was
building similar constructions in my mind. The office was sometimes noisy and
chance of interruption was not that small. So I established a habit of writing
kind of stack trace of my own thoughts so that I could easily come back to my
state of mind after such thing. It looked like:

    
    
      There is a bug in module X
        Module is X is calling module Y when user is not yet activated
        We are creating user subscription
          We are using current subscription in subscription creation
            Current subscription is A when user is not activated
            Current subscription is B when user is activated
              Probably bug in method c()
                Think what is going to happen in situation M when changed the implementation to d().
    

The list sometimes had 12 elements that I was trying to fit in my head to find
the solution to the problem. I now work remotely from home (quiet and all
that) and most of the code that I work on is of much better quality (another
company, better practices) but I still sometimes resort to this method when
working on a complicated piece of code that is unfamiliar to me.

~~~
Maxious
This is a common technique in engineering troubleshooting
[http://en.wikipedia.org/wiki/Ishikawa_diagram](http://en.wikipedia.org/wiki/Ishikawa_diagram)
[http://en.wikipedia.org/wiki/5_Whys](http://en.wikipedia.org/wiki/5_Whys)

~~~
calineczka
I never thought about it as something that can have such fancy name and such
broad engineering application. I think my technique is like 1% of what
Wikipedia describes.

------
jimbokun
I liken programmers to extremely expensive equipment for manufacturing
software.

When a company invests in expensive equipment like that, it is very important
to keep it producing output. So by sending programmers to meetings, your
expensive equipment is sitting idle, offline, producing nothing.

Interruptions are like shutting down an entire assembly line. When you turn it
in again, it will take time to be running smoothly again.

So to the managers and executives, it is your choice how to utilize this
highly specialized, very expensive equipment. You can try to keep it running
at full capacity, or frequently start it up and shut it down, take it offline,
and leave it sitting idle.

~~~
zanny
Many programmers (at least me) have varying levels of peak output in a day.

Some times I literally can't make my brain work after 2 - 3 hours of in-the-
zone work. I just can't read lines off a screen anymore.

Other times I can go 24+ hours without breaking a sweat.

I think in practice your average programmer can't operate on the 40 hour a
week traditional work schedule and actually output solid performance for all
40. On average, at least. So maybe the first businesses to start introducing
meetings and such were attempting to pace their SE staff and actually saw
positive results, since they still got whatever the maximum output one
engineer could put out before their brain went to mush in a week but also had
them talking to clients or discussing other things.

It is just the industry latched on to bureaucracy without postulating why it
might be useful. You want your SE coding whenever possible.

~~~
aidenn0
This is the reason why my productivity has gone down since going from single
to having a family. When I was single, I would just cut out early on the days
I wasn't in the zone, and get some errands or housework done.

When I was in the zone, I would stay at work until right before I would go to
bed.

This way I would spend nearly all of my "in the zone" time doing work.

Now that I have kids and such, I leave at 6 every day regardless of my
productivity level, so even though I spend only slightly less time at work, my
net productivity is way lower.

~~~
javajosh
Anyone can take a great photograph. The professional photographer learns
techniques to take great photos more frequently.

In a sense, "professionalism" in any field implies a certain "frequency of
success". For a programmer, that means learning techniques to accomplish tasks
even when you aren't "in the zone". This means learning to get in the zone,
how to stay in the zone, and learning to produce when you're nowhere near the
zone. This requirement is universal to all professionals, including all
_professional programmers_ [1]

I would add that learning to approach your work even when you don't feel like
it can sometimes yield surprising insights. Your brain is recoiling from work,
but only as it approaches it from _certain directions_. It is possible to
approach a problem from other angles, and getting "in the zone" from another
angle can sometimes yield unexpected improvements to the product for the
simple reason that you're looking at it in a new way.

[1] There are two categories of professional programmers, the hired guns and
the artists. They both want to build great things. The hired-gun wants to
build things faster and to spec. To him, "great things" is unambiguously
defined as 'the things that will satisfy the customer'. All businesses love a
speedy, accurate programmer - especially if they can be speedy and accurate in
a non-disruptive way. Such programmers are very good at understanding existing
codebases, processes, and doing the minimum work to get the job done. Often
they simply do not care about technical debt - (indeed, they are incentivized
the other way, to maintain (and even increase) technical debt, every bit of
which only improves their negotiating position with the client.)

Meanwhile the artist-programmer success is not defined by conformance to a
spec. Success is harder to define - but the artist can define success as
getting the time to _perfect_ his creations, traveling ever higher up that
diminishing returns curve, going higher than most people are willing to go.
This kind of programmer is the dreamer, the architect, the creative. This can
be a backend architect, or a front-end perfectionist. They share the common
goal of _mastery_ and _beauty_. Most, if not all, programmer heroes come from
this category. And rightly so, I think.

~~~
sateesh
Nicely put. Yes, programming is part art and we are not like machines that can
work no matter in what state we are. But often we mask our
procrastination/laziness blaming it on lot many things and waiting for a right
moment to magically arrive get the work done.

I am reading 'Dune' now and I found this advice from Halleck to Paul so
relevant :

'I guess I'm not in the mood for it today' Paul said.

'Mood ? Halleck's voice betrayed his outrage even through the shield's
filtering.

 _' What has mood to do with it? You fight when the need arises - no matter
the mood! Mood's a thing for cattle or making love or playing the baliset.
It's not for fighting' _

\-- Dune, Frank Herbert

~~~
Mithaldu
While this applies to many things people do, i don't think it applies to
programming. Programming is a continuous activity of concentration done over
the course of 8 hours, 5 days a week, roughly 45 weeks a year. Meanwhile
fighting of many kinds is something that happens in short bursts of extreme
focus and excertion.

In fact, programmers have to "fight" too, and it is highly different from
their daily work: It is when the software is burning cash and they have to
find the problem and implement a fix right now. Most programmers find that
they deal with that extremely well, though it usually happens at the cost of
the rest of the day.

------
jtheory
This isn't applicable to only programmers, of course; my wife is a novelist --
there are a lot of high-level concerns that she needs to balance in her head
PLUS there's the fiddly nature of creative flow, and it all comes crashing
down all too easily.

I had creative aspirations when I was younger (writing and music in
particular), and came to programming because it's far more predictable; the
costs of interruption are bad, but interruptions can be avoided, and the
difficulties can be mitigated (e.g., I take notes for anything complicated,
and re-read them when restarting a task; I break compilation as a to-do list,
and/or use version control for non-compiling code). Flow is really important,
but I generally _know how to do it_ \-- get enough sleep, clear away
overhanging stress clouds (like "taxes are due soon"), eat well, break tasks
down, get the smallest possible thing working, iterate, and so on).

But creative work killed me -- it was so painful to do iteratively; I'd spend
8 hours "writing" a poem that actually didn't coalesce until the 7.5 hour
point, at 4am. Composing a bad first draft of anything left me feeling
horrible; I never managed to force my way through that as long as I was trying
to make it "what I did".

Now that I do something else primarily, I can noodle around creatively and get
much more joy out of it -- but those years left me with much more respect for
people doing more creatively-oriented mental work than I do.

~~~
eru
Look up writer's discipline. `Creativity' is not too different from coding.

> \- get enough sleep, clear away overhanging stress clouds (like "taxes are
> due soon"), eat well, break tasks down, get the smallest possible thing
> working, iterate, and so on).

That's great for writing a novel, too.

~~~
jtheory
It's not that these things don't _help_ creatives, but that they are not
reliably sufficient to produce something of value.

If I'm coding on an uninspired day, I can easily just shift to tasks that I
know are simpler, and create a perfectly workable (if boring) solution. I can
work my way through to finding even fairly subtle bugs just by stepping
through the logic; it's slower than a flash of insight, but it works.

A writer or other creative person with high standards must discard all of that
uninspired work. In theory it may help keep the ideas churning, but for most
writers I know it can be a frustrating grind when things just aren't quite
clicking. It certainly helps to "train the muse" by writing every day at the
same time, always filling the page (even with nonsense if that's all you can
produce), and so on, but at the end of the day, they can't say "well, this is
a shitty story, but it'll pay the bills". It won't.

There's also the psychological difficulty that comes with putting sometimes
_years_ of work into something that may actually have no monetary value, or
minimal. There are obvious parallels to building a startup, except that novels
that succeed can't naturally be built into sustaining income -- you have to
start another novel, and it can easily earn you nothing after 5 years of work.

~~~
eru
In eg writing, there's lots of rewriting and editing. (And in coding, there's
lots of truly inspired work, too.)

------
tmikaeld
[http://i.imgur.com/xvNRKIT.png](http://i.imgur.com/xvNRKIT.png)

~~~
aw3c2
I downvoted you before I realise you just provided a copy of the actual post.
Please include some context next time and not just dump an imgur link.

~~~
lignuist
So you downvoted something that you did not even look at?

~~~
bdg
A post that expresses little thought should be down-voted. The post in
question is of value since the original link 503'd, but that value is
obfuscated to some by the lack of a quick "Here's a mirror" explanation.

Is this really a big deal?

~~~
ygra
Back when I first tried opening the page it 503ed and there was just one page
of comments, one of them was this image link. Its purpose was fairly clear,
actually. And helpful.

~~~
strickjb9
No it's not clear but it was helpful. There is an implication that a simple
imgur link could be a mirror of the comic image. But then you would have to
know that the content of the article was a comic image.

------
nmeofthestate
This scenario is a bit optimistic. I made a cartoon depicting my open plan
office experience: [http://imgur.com/fsv1cCq](http://imgur.com/fsv1cCq)

~~~
switch007
That's so accurate! The penultimate one should be putting on ear phones, then
the last one showing someone coming over to your desk and interrupting :P

~~~
rix0r
I actually made one about that :)

[http://rix0rrr.tumblr.com/image/42866777562](http://rix0rrr.tumblr.com/image/42866777562)

------
teddyh
Reminds me of this:

Don't Wake Up the Programmer!

[http://alexthunder.livejournal.com/309815.html](http://alexthunder.livejournal.com/309815.html)

~~~
brador
That article contains the best analogy of programming I've ever found.
Beautiful piece, thanks.

------
ohwp
This is also why you shouldn't interrupt yourself ;)

Turn off your e-mail client, phone, messages, internet connection, HN.

~~~
option_greek
IMHO, while working on challenging tasks (bugs mostly) where we are not able
to figure out something, tiny breaks spent on unrelated subjects seem to help
a lot. While interruptions are bad, a badly timed interruptions seem to be the
worst.

~~~
sateesh
In my experience tiny breaks away from the workstation are far more helpful
than the ones that need you to use the computer. I have found taking a break
from a programming session in form of checking HN, twitter makes the mind all
more muddled.

~~~
gbog
Yes, let's grab a cigarette... or a coke, or a coffee. But all these circuit
breakers are bad for health. The best I found out for now is to add hot water
to my tea mug.

~~~
ljf
Or starjumps in the corridor

------
jenrzzz
Mirror: [http://heeris.id.au.nyud.net/2013/this-is-why-you-
shouldnt-i...](http://heeris.id.au.nyud.net/2013/this-is-why-you-shouldnt-
interrupt-a-programmer)

------
jmadsen
The problem is, the only people who ever read these are other programmer who
already know this.

Need to find places where we can post it to NON-programmers

~~~
hkmurakami
I'm currently back in school in a non-programmer environment, and I honestly
have a hard time bringing this sort of this up to most people I know here
because I just know that they won't understand why this is so important and I
just don't want to deal with the interpersonal mess :( :(

~~~
mhurron
Apparently programmers are the only people who think about problems. You poor
little unique flower.

Write it down. It will be clearer to you. You can more easily refer back to
it. You will be interrupted. You will need to do other things before you
finish your current grand opus. You will lose your place in your own thoughts
just by trying to hold it all in your head the whole time.

~~~
icebraining
You're right, though your post would be better without mocking people.

I don't have an habit of writing stuff down, but I know I really should. That
said, a couple hours of interruption-free work doesn't seem an extravagant
request.

------
lotsofcows
Needs a clock in the background to hammer home the point to non-programmers
that it can take an hour to get from the 1st to the 6th panel. Bosses take
note: an hours work has disappeared.

~~~
goshx
I agree

------
Pxtl
This is also why, as a programmer, it's essential that you manage and handle
your email. If you're not available by mail in a _vaguely_ timely fashion,
you're going to get people learn to workaround your deficiency by chasing you
down in-person or over voice.

~~~
andy_adams
Wow, this bit of wisdom is unbelievably valuable in my experience. The number
of programmers who have _thousands_ of unread messages in their inbox has
always startled me. So many of them don't respond in a timely manner via
email, which earns them the title of 'flake', and opens them up to phone calls
and other interruptions.

------
rix0r
To my mind, the cartoon is more of a depiction why you should avoid mutable
state and non-local effects.

~~~
colanderman
Or moreover, why you shouldn't write parsers/lexers by hand.

------
ozh
Will show this to the wife. She has a hard time understanding why working on
week-end projects by 45 minute chucks isn't effective as I need 20 minutes to
get in the zone and restart my thoughts where I left them

~~~
gbog
There is one nice way to push oneself in the zone faster: just open a broken
test in your test suite, it will point you to the next step. [edited to
clarify]

~~~
keyle
I quite often leave my code broken so that next time I open the solution I
know exactly where I left off. I will often leave a comment there or
throw("get X to do Y now")

~~~
jtheory
I do this as well -- once I have the complete solution to something in my
head, I quickly go through the various parts of the codebase that will be
affected and drop pseudo-code or even just rapid notes in each place -- which
will intentionally break the compilation, so that I can use the compiler
errors as a fast & direct way to pick up the threads again if I'm interrupted.

For non-compiled code I'll add a dozen line breaks and a note in all-caps to
make it jump out in a diff.

~~~
gbog
Great but using tests is better, because written correctly you will keep them
and they will check forever that the thing is working

------
stef25
Whenever I try to explain this to interrupting colleagues / bosses I always
get rolling eyes and "here he goes again", frustrating as hell.

~~~
hkmurakami
This is why I haven't been able to bring this up in my new environment
(school). I know that people won't get it, and I just have a strong desire to
avoid the admonishment :(

------
SubuSS
Late comment but: I look at it as a necessary evil. I usually solve it by
having a note of the intermediate understandings / thought process on OneNote
when I am debugging something deep. It probably takes 2 minutes to get back on
the train when disturbed. Yes - I do debug production systems / file system
level issues / Storage level issues etc. And yes I am a senior engineer who
keeps getting walkin / IM requests.

The flip side of saying no to meetings/walk ups is that the senior won't be
doing a good job of unblocking the team. It is a huge waste to leave a bunch
of junior engineers solving the same issues that you had solved years ago.
Mentoring takes a hit and morale takes a dive in that case.

------
steven777400
Every month, I produce a "time usage" pie chart for one of my managers for the
month. At one point, he said: "You need to spend less time in meetings."

So I told him I'd be happy to oblige if he wouldn't schedule me in as many. He
was shocked and said most of the meetings must be from my other manager (who's
a real hands-off kind of guy). So I broke out the details and showed him that
the vast, vast majority of my "meetings" time was scheduled by him.

He didn't bring it up again, but also continued to schedule me in as many
meetings as before... So I guess that's a decision. :)

~~~
brudgers
Obviously, he wouldn't schedule a meeting if he didn't think it was important.

I suspect there is a correlation between managers who believe their meetings
are important and managers who believe that an hourly breakdown of a direct
report's work tasks is a more meaningful metric than the direct report's work
output.

------
bmelton
Worth noting, but this article is _also_ a plaintiff cry for why programmers
need to write better comments, too.

Edit: I meant _plaintive_ , but my eyes were still crusty with sleep, and I am
a giant dummy.

~~~
ChristianMarks
Who is the defendant?

~~~
bmelton
Gah. S'what I get for posting before coffee. It should read "plaintive".

------
jseban
This is also why you should use pen and paper and not try to keep everything
in your head?

~~~
jpatte
The main problem of pen+paper is it's only 2D. Modeling an entire process may
require a lot more than 2 dimensions, so trying to put it in 2D is actually
harder than modeling it freely in your head.

~~~
tempestn
Exactly. And much slower as well. Obviously if you _expect_ to be interrupted
you can take the time to download your brain onto paper, but trying to do all
your work on paper would be like running your CPU through a printer->scanner
loop-back.

------
kineticfocus
lol... the current page works as a punchline just as well:

 _Service Temporarily Unavailable

The server is temporarily unable to service your request due to maintenance
downtime or capacity problems. Please try again later._

------
waylandsmithers
I don't mean to be a downer, and I certainly enjoyed this comic, but I fear
that these are the kinds of posts that lead to communities becoming nothing
more than memes and other quick laughs on reddit.

~~~
moccajoghurt
Well this was very specific programming related joke. If they stay like that
and only pop up once in a while, it's fine. Just enjoy the joke and stop
worrying.

------
tieTYT
As a test I sent it to a non-technical friend. She said, "I don't understand".
In other words, this only makes sense _if_ you're a programmer. I feel the
cartoon's pain, but I can't send this to a manager to help them understand.

------
niravshah
This is why programmers (and everyone doing deep analysis/critical thinking)
get a huge benefit from taking notes.

------
jipumarino
I got a 503 error and for a moment I thought it was very insightful.

------
strickjb9
I showed this to my wife and she didn't get it right away. I explained it to
her then she said 'Does this mean I need to go?' because we were gchat'ing and
I was working at the time (aka waiting for Eclipse to respond). I regrettably
told her that we need to wrap it up.

------
wiremine
This is great! It articulates what most of us programmers feel internally when
we're interrupted. What's I'd also love to see is a cartoon explaining the
external effect of an interruption. Like, when you interrupt a programmer
you're pulling the "stop" cord on an assembly line: it doesn't just effect
that individual, but there is a net effect on the overall effort.

(FWIW, I don't think the assembly line is a good example, because programmers
work in parallel, not in sequence, but it's the best sort-of-example I could
think of on a Monday morning...)

------
tluyben2
For me this image shows why there is something deeply wrong with programming
at this moment in time; the fact you need to do all those assertions/logical
operations in your head instead of the super computer standing in front of you
(which is much faster in most those operations anyway) is painful to see. By
clicking that line, the IDE should generate all that context (and
graphs/charts/whatever) for you in a jiffy instead of you doing that in your
head.

~~~
jdbernard
Sure, if you are content with the way the compiler lays out the information.
Personally, I am far more efficient with vim and a CLI than Visual
Studio/Eclipse/$FancyIDE precisely because I can live in my head and not in
the IDE.

The day we can replace the mental process required to fully understand a
problem is the day we can put down our keyboards and let the computers do all
the programming for us. Until then I assert that you will not produce the same
quality of code without doing the hard work in your own head.

~~~
tluyben2
I'm looking forward to that day anyway. And I agree to some extend with you as
you say 'doing the hard work in your head', I just don't think _all_ the hard
work should be done there. Just the hardest work computers cannot do for you.

I work with vim only because I don't think IDE's contribute much at the
moment. I believe they should be able to contribute a lot more. I'm just not
sure how that is supposed to look, but luckily smarter people than me are
working on that :)

------
tmikaeld
Someone put it on 9gag
[http://9gag.com/gag/av0z0Bn](http://9gag.com/gag/av0z0Bn)

------
cburgmer
I disagree with what I think this picture implies. That is shielding the
developer from interaction makes him/her more productive. In contrary,
interruption and conversation belong to development. The more my fellow
developer colleagues talk, the better the code base is.

~~~
pwelch
Yes and no. Yes, talking can help bring a lot of people to a solution easier.
Taking a coffee break and chatting with a co-worker about your current problem
or pairing with another set of eyes is often vary helpful.

However, when you are really focused on a complicated problem it is hard to
find a solution when your thought process is constantly interrupted.

------
Delmania
Unit tests can go a long way to helping both gain and retain understanding of
what a codebase does. Context switching topics is an important life skill. A
work place that's free from distractions would be good, but that's not always
possible.

------
elwell
The number of upvotes is indicative of a common thread of frustration felt by
programmers.

------
djKianoosh
A lot of the commentary places importance on getting stuff done in a single
day...

I think sometimes we overlook that really strong problems require many days of
active/passive thought. Soooo, sometimes interruptions are good!

------
NAFV_P
Let's face it, coders can't multi-task.

Fortunately, computers can do all that for you.

~~~
bradwestness
_Humans_ can't multi-task.

~~~
NAFV_P
It's a myth invented by (sociopathic) business gurus. It holds as much H2O as
"soggy biscuit".

------
LeSeb
Being a programer on trading floor, this happens all the time ...

------
SworDsy
It's still funny that now it's a down

------
gouggoug
How ironic is it that when I clicked on "Why You Shouldn't Interrupt a
Programmer" I got a 503

------
rsobers
My only qualm with this comic is that it doesn't end in a fit of rage. :-)

------
known
Writing software != Selling software

You need mutually EXCLUSIVE skills.

------
umrashrf
I can't access the page.

------
Spoygg
Excellent :)

------
tmikaeld
hacker news effected the site

~~~
jrgnsd
affected?

~~~
Ygg2
Eh, no need to call in the Grammar Squad. Not to mention effect is correct
here (effect means ‘to bring something about as a result’). Hacker News did
bring something about as a result.

~~~
jmmcd
Grammar Squad here with the facts. And just the facts.

When _effect_ is a verb, the object must be the change itself, similar to
_cause_ : "Hacker News effected a significant deterioration in site
availability". With _affect_ , the thing being changed is the object: "Hacker
News affected the site."

~~~
shangxiao
What nobody's quoted xkcd yet? [http://xkcd.com/326](http://xkcd.com/326)

~~~
jmmcd
Very good, but the Grammar Squad are not amateurs, and we have not been
tripped up!

