
Are interruptions worse for programmers than for other knowledge workers? - axiomdata316
https://dev.to/_bigblind/are-interruptions-really-worse-for-programmers-than-for-other-knowledge-workers-2ij9
======
chrispyper
I would say "creative" workers instead of "knowledge" workers. If your job is
to regurgitate a bunch of stuff from memory, interruptions might not be a big
deal. If your job is to create new things that don’t exist yet, then
interruptions derail you as you need intense clarity and focus to do so. And
it affects everyone who is in a creative class job equally when they are in a
creative mode: Designers, architects, musicians, writers, engineers, chefs,
mathematicians, scientists, etc.

I like to think of it like this: A musician can play for a busy stadium, or a
chef can cook for a busy restaurant, if they are playing a song they rehearsed
or preparing a dish they made many times. But to write that song or create
that dish in the first place, like hell you could do that with all that noise
and distraction.

~~~
egypturnash
So, here's my experience in another creative process.

I'm an artist. The vast majority of my thinking and planning time happens with
a sketchbook or drawing program open in front of me, and me rapidly generating
rough sketches and/or story notes. I have learnt over the years that, sure, I
can sit there staring off into space trying to work stuff out in my mind's eye
all I like, but things go a _lot_ faster if I work it out by creating a rapid
feedback loop between what I'm sketching out in front of me, and how I want it
to look when it's done.

Sometimes when I am very stoned I can enter a state where I'm holding a nearly
complete image of the whole drawing in my mind's eye and "tracing" it onto the
paper. It's a pretty cool place to be in. But it's super fragile; interrupt me
and I'll lose it, with an incoherent fragment of a drawing. So normally, _I
don 't work like that at all_ \- I'll quickly draw the roughest version
possible of the important parts of the drawing, and iterate on that until it's
done, or until I decide this approach is not working, and try another one. My
ideas are in tangible form _as soon as possible_.

When I'm writing (I mostly make comics, so I get to draw AND write), it's the
same thing. As soon as I have the germ of a baby idea that sounds okay, I pull
out paper or Evernote or whatever and _write it down_.

Interruptions still suck. Interruptions can still take time to recover from.
But I don't have to spend a half an hour building up an intricate mental model
of what I want to do afterwards from scratch, because I have a pile of roughs
and notes that _documents_ the process of getting to where I was.

So my suggestion, from how I practice my craft: As soon as you realize you're
getting into complex territory, _open up a notebook and start scribbling
questions and answers and inspirations to yourself_ , draw little diagrams (or
big ones). And mess up your copy of the code with a ton of comments - what's
this section doing, what do I need to investigate further, here's some
pseudocode for how I might fix this, etc, etc. _Document as much of your
thinking as possible_ , put as much of the headspace you're generating
_outside_ of your head as you can so that it's easier to pick up the pieces
after an interruption.

~~~
startupdiscuss
Oh, it is the same for programmers!

As soon as we have an idea we immediately open up an IDE, and then get a GIT
repository going, and get Yarn to prepare all the libraries we need, and get a
quick little back end database api set up, and then a quick little front end
framework and then we are...

finally ready to start experimenting.

~~~
eropple
You can, for the most part, do that _once_ and never again, though.

`cp -R` is a thing.

~~~
mindcrime
or

    
    
        git clone https://github.com/myaccount/proj_template.git newproj

------
scarygliders
> I don't believe we're as special as we think we are

I don't like the premise.

In my opinion and from personal experience, it's more to do with keeping an
abstract of the problem you're trying to solve in your head, which is what the
cartoon is portraying, than any thought of somehow being special in some way.

I mainly work from home, and I'm married, which means quite often I could be
working on a piece of code - abstract in my mind - when the goodly wife enters
my room and starts asking or talking about domestic subjects or issues. And
then just like the cartoon, the abstraction I had so carefully taken the time
to build up in my mind goes _POFF!_

That _POFF!_ is most frustrating. It's not that I think I'm special, or that
the _POFF!_ is different for other types of workers/professions, but it does
take time to settle down and begin to build the abstraction back up in one's
mind again.

~~~
Bizarro
I'm in the same boat as you. I work from home and so does my wife. I'll just
be passing by to go to the bathroom or something and she'll want to have a 20
minute conversation about something. I don't want to be rude, but I'm thinking
"I gotta get back at it.."

My memory has never been great, which isn't ideal for being a programmer.
Lately, I've had a text editor opened up separate from my code editor where I
kind of document my train of thought - especially on fuzzy, complex stuff.

For example, we run everything out of Azure, but I've noticed that for our
various environments, but same applications, things are setup in an ad-hoc
manner and a little bit different, but still work.

So basically I'm just documenting my train of thought as I setup a new
application environment - nothing formal.

That might seem obvious to other development shops, but we're just a couple
guys flying by the seat of our pants and things get messy quickly, and
memories fade.

~~~
cosmiccartel
> Lately, I've had a text editor opened up separate from my code editor where
> I kind of document my train of thought - especially on fuzzy, complex stuff.

I do something similar. I have a dedicated to-do app, but I like having a more
freeform text log as well. On a Mac,
[https://github.com/glushchenko/fsnotes](https://github.com/glushchenko/fsnotes)
works well.

~~~
jason_slack
Thanks for the link. This app will solve some needs I have.

------
switch007
I don't accept the premise. Who are all these people saying they're "worse for
programmers than for other knowledge workers"?

I've seen many times on Twitter non-programmers basically calling us cry-
babies. However, they are often arguing against an opinion they invented.

"I hate interruptions" does not mean "I hate interruptions and I believe I'm
the only person in the world affected by them"

~~~
sametmax
One of my grandfather was building huge oil extractions platforms. You can bet
50 years later he was still complaining about his work being interrupted.

It's not a new thing, but it does affect engineers a lot because their job is
to solve new problems on complex systems regularly, and it involves
creativity, abstract thinking and holding a lot of variables in your head.

Today, IT is one of the field where you have the most engineers, and by nature
they master the most important communication device made by man: the Internet.
So you hear them the most. They are not cry babies, they are more numerous and
can be more vocal than other professions with the same problem.

------
seba_dos1
Aside of the critique that already appeared there about the fact that if you
believe that you suffer from being interrupted it does not mean at all that
you think you're any kind of special, there's one thing this note completely
fails to mention.

One of the most mentally demanding parts of programming (and the part that I
personally enjoy the most) is debugging. In small, managable chunks it
probably takes most of one's time, while the bigger sessions of finding a
particularly nasty bugs are more rare, yet awfully demanding. You can't "come
up with a solution to a problem before you start writing code" nor "divide the
solution you came up with into small chunks", as your whole job there is to
slowly unravel the interconnectedness of all things and produce a mental model
of how the code works, how it should work and where the expectations differ
from reality. It just requires a lot of concentration, just as any other job
that suffers greatly from interruptions.

(also, I fail to see how "come up with a solution to a problem before you
start writing code" changes anything. You will still lose your train of
thought when being interrupted while coming up with a solution before starting
coding - and it will be even harder to justify being annoyed at interrupting
party when you can't even show them your IDE on your screen :P)

~~~
mannykannot
Divide-and-conquer approaches are very effective in debugging. When you are
debugging, you don't break down the problem before starting the process;
breaking it down _is_ the process.

With debugging, you have a concrete implementation and a specific problem to
work with. In development, you have to try to anticipate every problem, and
coming up with a concrete implementation is the goal, not a given. These
complications, IMHO, make design ultimately harder than debugging.

If your progress on something is dependent on a mental image that collapses
with the slightest interruption, then you are working at the limits of your
ability. To go beyond that, you need to be able to record what you know so
that you are not limited by your mental working storage. I am interrupted by
sleep every day, and the first thing I do the following morning is to review
any notes I made on the previous day.

Interruptions are certainly disruptive, but your claim that these techniques
will not mitigate the problem does not mesh with my experience.

~~~
seba_dos1
Your post matches what I meant - you don't do these mentioned things before
doing "proper" work; your work _is_ doing there things, so there's nothing to
actually learn from the article. The interruptions will be just as painful (or
not) for you as they were before reading it.

Sure, notes are useful, but your mental representation of the issue is your
cache. With lots of cache misses, you are much slower ;)

------
BrandoElFollito
I did science (PhD in physics), work in information security and develop (pro
and personal).

Interruptions in science were not a problem, I would say that they were
welcome. My brain was processing a lot in the background when the thoughts
were bent formed. I had my best ideas in unusual conditions.

The same interruption when coding is disastrous. My thoughts are "stacked" and
run in the foreground. When I am interrupted, I have to build the stack again
almost from scratch.

Information security is a middle ground. A lot of the work is not creative and
I do not care about Interruptions. The creative part sometimes look like
science and summertime like coding, so it really depends on the subject.

------
clay_the_ripper
I’m not a developer, but I work in tech. Interruptions are still quite costly
for me. It’s less about “holding a lot in my head at once” and more about
getting into a “flow”-ish state. Once I get going, I get momentum and am able
to continue to get things done. Once I stop, I lose momentum and my pace of
work slows.

It’s harder to quantify but when I get uninterrupted work done, I “feel”
better while I’m working. I’m happier and more productive while working. I
have a pretty one track mind, so focusing on one thing at a time and doing
that one thing really well is important for me.

------
jim-davis
The advice about "chunking" when writing new code does not apply when, like
the cartoon character, you are _debugging_ , perhaps post-facto, an event in a
complex system where you must recreate the state while considering multiple
hypotheses. You are constructing and exploring a fault-graph, formulating
various 'experiments' you can try next to prune (or expand) the graph,
weighing the relative costs/benefits of each next action, and assessing your
confidence in multiple beliefs. All this with imperfect information (e.g. as
the cartoon shows, missing course code; but also empty commit messages,
obscure or obsolete comments.

The most useful 'chunking' I do is to actually _write down_ the multiple
hypotheses and evidence pro-and-con. Often the mere act of putting the idea
into words helps, and at least it gives me something to come back to when I
get interrupted.

~~~
bonniemuffin
+1 on _write it down_. Leaving myself an unusually effective trail of notes is
the secret weapon that makes me substantially more resilient to interruptions
and task switching than many of my peers. Paper, osx notes app, google docs,
emails-- the right tool depends on the exact task, but step 1 to solving any
problem is always "start a doc".

~~~
Noumenon72
Do it in something searchable so you can look for "have I ever puzzled through
this class before?"

------
yomly
Something I noticed (having worked as both a non-programmer and programmer)
that hangovers affect me much worse as a programmer than not.

As a non-programmer there were always mundane things I could do to keep things
ticking over: sending emails, updating reports etc.

As a programmer who solely codes, there's not many places I can hide in my
work if I'm off form. If my concentration is impeded, my output will very
visibly suffer.

~~~
hinkley
I work on something else. Docs. Code reviews. Backlog. Automation. Or I read
up on what the broke in version 1.5.4 of the library we use for this part of
the code. Read up on the new language features coming out later this year. Or
review the keyboard shortcuts for my editor.

It doesn’t help me so much with this week’s story (I fuckin hate Scrum now)
but it helps in the long run.

------
fnordprefect
I'm a lawyer (day job) and programmer (now hobby, former side job). I find
interruptions just as bad for both kinds of work when you are in or trying to
get into the zone.

By that, for coding, one good example is trying to work out how something new
would be implemented, then how it would fit with existing things, then getting
down to implementing. For that, you need a clear mental model of all the
moving parts -- what's there, what's not there, what has to be added, and what
has to change. When you're in the zone, you know where you are, where you're
going, what to add and how to add it. Things just flow. Code appears, and you
keep track in your head of files you need to visit and what you need to do in
each. If left uninterrupted, you will eventually get there, and hours can
disappear without you noticing. Same with debugging, when you're trying to map
in your head what is going on, what should be going on, and what might be
causing a deviation between the two.

You have to rebuild that model when you get interrupted, and the extent of the
rebuilding is usually proportional (and monotonically increasing) to the
length of the interruption and the extent you have to commit thought to it.

For legal work, I find that kind of work usually occurs in writing submissions
or preparing cross-examination. You're thinking about your overall journey to
win the case (usually all or part of your case theory) and how you help get
there with what you're working on. You're keeping points made in dozens of
cases that you have to interleave when you get to the right place, or that you
have to take account of in the evidence (eg what kind of evidence does case X
require me to adduce to prove point Y). You're thinking about what is
_persuasive_ (the key to all good legal writing) but also about what is
accurate (duty to the court), what is admissible into evidence, and what is
understandable to your audience (usually a judge). Again, when you're in the
zone, it just flows and time has little meaning.

The overall interrelationship is the same as coding -- lots of moving parts in
your head, lots of reliance on short-term memory -- and it suffers the same
way from interruptions.

My pet theory is that the more that mental work requires saturating short term
memory, and making use of it when saturated, the more vulnerable it is to
interruptions.

------
y0y
> Are interruptions really worse for programmers than for other knowledge
> workers?

Who cares? It's not a competition. The fact is that it sucks for programmers
and we want to avoid them.

------
dkersten
> But I do think that you can improve your resilience to interruptions if you:

> 1\. Come up with a solution to a problem before you start writing code, and
> think about which parts of the system that solution will impact.

The problem is, for me, that _“come up with a solution”_ is the part that is
at most risk of getting derailed by distraction. Writing the code, after I’ve
come up wth a solution, is quite a minor aspect of programming for me (almost
trivial, often). The hard part is understanding the problem, its contraints
and requirements, the context within which it lives and all of the different
things that I need to take into account to create a solution. That often takes
a lot of working through things in my mind: visualising input data,
transformations and output, visualising dependencies, simulating the
algorithms and processes in my head. Determining what affects what and if that
has any impact on something else. That’s the hard part. Actually coding it is
usually not so hard nor is it usually particularly sensitive to interruptions.

~~~
jinfiesto
This. I personally don't feel that I spend all that much time in the
"trenches" when programming. Most of my work is thinking and then hopping over
to the computer to tap out a few lines. Or sometimes interacting with
something through the debugger/reading the code to get an idea of how
something works. I very rarely have my nose in the keys trying to grind out a
solution.

------
Bizarro
I don't agree with the premise of "we think we're special either", but

 _Come up with a solution to a problem before you start writing code, and
think about which parts of the system that solution will impact._

 _Divide the solution you came up with into small chunks, so you can take them
one at a time._

This makes a lot of sense. I see junior programmers flying by the seat of
their pants without a plan too often - I do it too.

I find that stepping away from the IDE/code editor (not looking at code) and
thinking about the problem helps a lot. That could also involve a piece of
paper and pencil, or a text editor and just writing train of thought stuff.
But the key is not to be looking at the code.

His second piece of advice about dividing the solution up into smaller chunks,
I also apply to debugging.

When someone comes to me with a debugging issue, the first thing I ask "ok,
how do we simplify the problem? How do we get rid some of the extraneous
details?" And then keep on iterating over that - keep on simplifying.

~~~
taneq
> Come up with a solution to a problem before you start writing code

Oh, so " _figure out how to_ draw the rest of the freakin' owl".

~~~
hinkley
?

The rest Of the post is about how you don’t need to draw the entire owl.

------
nopinsight
I have written and published two non-fiction books (about e-commerce and
education) and I code. Interruptions during coding cause more disruption to my
flow of work than during writing.

------
wenc
In another HN article today [1]: "Logic will get you from point A to point B,
but imagination will take you everywhere." — Albert Einstein

Programming (more generally, problem solving), especially of the creative
sort, is not logical. It meanders and takes a non-linear path to the solution,
and is not always amenable to chunking.

[1] [https://undark.org/article/book-review-mlodinow-
elastic/](https://undark.org/article/book-review-mlodinow-elastic/)

------
anotheryou
I think it depends a lot on two things: Flow and Complexity of the necessary
scope.

A broken flow is much worse e.g. for a musician, but still very important for
programmers as well.

A big, special part of the flow can however be the complexity of what you have
to keep in mind to make a good next step. Programming can have a lot of
concepts and connections to be juggled at the same time and non broken commit
needs tons of things to be kept in mind, too small to write a todo for it.
Those need to be read in to ram again after an interruption. I think
programming is indeed special here.

Good code minimizes complexity, but you want to map out as much of the
complexity in your head before even starting to archive exactly that.
Especially at that point you really don't want to be interrupted. A good
indicator for work that suffers a lot from interruptions might be when you
already turn to some whiteboard just for yourself, because you need to get
some little bits of your mind to mentally work on other parts of the project
and still have them within reach.

Most other work is much more linear and e.g. reading your last few sentences
rather quickly gets going again to write the next.

~~~
slx26
Agree with your point on complexity, I was thinking along these lines too. I
realized that the real problem comes when you have a lot of information in
your head, and you are trying to keep everything in mind at the same time,
designing the solution of a complex problem, tackling many of the small
details in parallel. That requires a lot of focus and a very specific state of
mind, and getting distracted when you are at that point is really bad. If you
are just going through a buglist or a list of simple tasks, it might not be
such a big deal, but most of the time, even when not actively designing, you
need to put a lot of effort to get in the right mental state, load into your
mental cache the complexity of the codebase you are working in.

And realizing this also helped me concentrate better. Sometimes I have trouble
starting to code, and I found that focusing on a very simple problem helps you
get back on track and you automatically start remembering everything you need
for your work. In the past I used to make the mistake of trying to solve
everything at the same time, have a perfect plan before starting to write, and
I was completely blocked. I think it depends a lot on the person and their
mental processes while programming.

------
wenc
I don't agree with the premise.

Chunking helps to break down problems, but some problems require one to
wrestle with many chunks of the problem at the same time, while building
intuition. The boundaries between chunks are also not that well-defined,
especially when one is working with a new problem that has no solution.

Author assumes that all problems are decomposable to interrupt-proof
tasks/units.

This is untrue in many complex problem domains.

------
perpetualcrayon
I've been involved in 2 very different situations as a programmer.

When I'm working on some random problem that I don't care about it's going to
be difficult to recover my original line of thought if I was "in the zone" at
the time.

If it's a problem I care about and am involved in intimately it's not
difficult to recover from interruptions.

------
rossdavidh
One underappreciated aspect of pair programming, which I grant you has its
downsides, is that in some organizations there is a special room where those
two developers go to pair program, at a booked part of the day, and that tends
to raise the threshold for interruptions. Not saying pair programming is
without downsides, but I have had the experience work, and afterwards wondered
if it wasn't only that two pairs of eyes was better, but also that two people
in a room doing a scheduled meeting seems (to most people, not all) less
interruptable than a single person at their desk.

------
maym86
Just saying "sorry can't talk now" to people doesn't really break me away from
being able to solve a problem or loose my train of thought. Other people I
work with don't understand this and move on. Being interrupted is never a big
deal as long as the person knows to leave me alone if I'm not ready to talk
and the interaction is short.

Distraction is more of a problem for me when the environment is loud and there
are people having other conversations nearby or other things going on that I
can't control.

------
rb808
I remember at university the professors had doors on their offices. When they
were working on something they'd lock the door. Its more difficult to do when
working in an open plan office.

~~~
throwaway080383
Yep. As a grad student, it was _much_ easier for me to avoid distractions than
it is now as a software engineer. If I needed X hours of uninterrupted focus,
I would go to the library for X hours.

------
throwaway080383
""" But I do think that you can improve your resilience to interruptions if
you:

Come up with a solution to a problem before you start writing code, and think
about which parts of the system that solution will impact. Divide the solution
you came up with into small chunks, so you can take them one at a time. """

That may be true, but I think it comes at the cost of taking more cumulative
time. I can either knock out this feature in three hours, or I can spend an
hour breaking it into six half-hour chunks.

~~~
Jaruzel
This approach is known as 'Top Down'[1] and was VERY popular in the early days
of system and program design.

When I started my career I encountered a beardy-sandal-wearing systems
programmer[2] , who 100% believed that there should be more comments than code
in a program. His approach was to use the comments to write out long-form
exactly what the program would do. He would write the whole solution as 1000's
of comment lines, from start to finish in one big comment block. Once he'd
done that, he'd then start again at the top, and split the comments at a
natural point and insert real code to reflect the 100 or so comments above it.

At the time, I thought it was a crazy way to do it, and even now I wouldn't do
it. But it had it's upsides. His code was really easy for others to maintain,
and it was also fundamentally self documenting.

\---

[1] [http://dept-
info.labri.fr/~strandh/Teaching/MTP/Common/Stran...](http://dept-
info.labri.fr/~strandh/Teaching/MTP/Common/Strandh-Tutorial/top-down-
programming.html)

[2] Ironically, my beard is now WAY longer than his ever was.

------
NPMaxwell
Article: "Divide the solution you came up with into small chunks". The idea is
to use less of your short term memory for the work; by applying this approach
to your working memory, you'll have a few slots left over for office
conversations. An analogous strategy is for programs to hold less data in RAM
so you can dedicate a portion of the CPU's RAM to keeping track of shopping
lists and baseball statistics for your neighbor.

~~~
walshemj
That is assuming the everyone has the same ability with working memory - its
quite obvious that one of the diagnostic's for neurodiversity is poor short
term memory - and guess what industry's have more neurodiverse people?

~~~
NPMaxwell
Yes! All the more reason to keep all your short term memory for your work.

------
yiyus
What's the point of comparing with other "knowledge workers"? And how can you
pretend to make an argument when those other knowledge workers are not
considered at all?

Surely interruptions are bad when you are programming, but interruptions are
as bad when you are doing any other intellectually intensive task.

------
exit
_> 1\. Come up with a solution to a problem before you start writing code, and
think about which parts of the system that solution will impact._

how could the programmer in the comic strip apply this advice?

a lot of programming, possibly most of it, is about reading code and making
sense of it, not writing it.

------
forinti
I work in a role that is part development and part DBA/sysadmin. Interruptions
are bad in both cases, but a lot worse when I'm coding. I also work in a noisy
office, so it's hard to get into a coding mood in the first place, so
interruptions are that much more annoying.

------
bane
We (the industry) have done a poor job at delineating different kinds of
people who type code into a computer. Our jobs run the entire gamut from "read
specification, type code" player-piano type work to intensely creative
endeavors.

On this spectrum, what do we call these people? I have a sense that "software
engineer" to "computer scientist" seems to bookend the range.

This is important because converting specifications is generally less focus
demanding than new algorithm development, and workplaces can adjust their
shape to fit the different kinds of work they do.

~~~
taneq
> I have a sense that "software engineer" to "computer scientist" seems to
> bookend the range.

I think the extremes you want are more "code monkey" and "architect".

~~~
asthrw
Except that "architect" is synonymous with "bullshitter" for insiders.

------
awinter-py
> a lot of interruption aversion we feel is caused by not breaking our work
> into small enough chunks

Some kinds of work (not just programming) is difficult to plan well in advance
because you're reading & writing at the same time.

Doing a good job at creative work is an optimization process and you need to
be able to change direction as you explore the space. Staying open to that is
a hard mental workload.

In a lot of cases where I outline ahead of time, I end up going in a different
direction once I start work.

Also _planning_ takes as much concentration as anything.

------
mattkevan
I’m not a professional developer but my train of thought is very easily
derailed. Closing down the windows on my computer is like an archeological
dig, unearthing the strata of tasks I started and forgot about.

The solution is to write everything down. I have a Dynalist window permanently
open and put thoughts, things people ask me to do and anything else in there.

And when I do write code, it takes such concentration that even 10 minutes
later I can’t remember how it works. I have to comment almost every line with
a narrative as to what’s going on.

------
markbnj
I buy this, in a general sense. If you're able to fully understand the problem
and plan out the solution before starting to make changes you should be able
to pause and pick up again more easily than if you are designing on the fly.
But of course all that planning requires thought, and thought requires time
and the freedom to concentrate, and "ding" there's an email in the inbox.

------
DaggerDagger
Lets just say "problem solvers" and avoid the semantics. Problem solving is
abstract reasoning. It requires flow state.

~~~
thanatropism
I don't think anyone is being paid for creating problems outside of academia.

------
danieltillett
I am surprised to not see anything about debugging in the comments here. I can
write new code fine with regular distraction without facing too much mental
model rebuild downtime, but debugging is something else. The mental model of a
complex code base when debugging takes me a long time to rebuild after any
interruption.

------
thedailymail
Samuel Coleridge famously claimed he was interrupted by a "man from Porlock"
while writing down the poem Kubla Khan. There's some debate about whether he
was using interruption as an excuse for not finishing the poem. In any case,
it's not just coders who hate having a train of thought broken.

------
ChuckMcM
This line stood out for me ... _This in turn is caused by not understanding
the scope of what we 're doing. Very often we just dig in, thinking it'll be a
small change._

Many times I start where I _think_ it will be a simple change but it turns out
to involve much more than I realized.

------
bedros
it's worth reading maker's schedule vs manager's schedule [0]

[0]
[http://www.paulgraham.com/makersschedule.html](http://www.paulgraham.com/makersschedule.html)

------
spc476
Nope. Just ask Samuel Taylor Coleridge [1].

[1]
[https://en.wikipedia.org/wiki/Kubla_Khan](https://en.wikipedia.org/wiki/Kubla_Khan)

------
dghughes
I'm learning Python in College, I am not a programmer at all probably never
will be but it is fun.

When working on a project any noise, any interruption at all I find extremely
distracting to the point I have to stop and collect my thoughts for later.

During exams for Python I use earbuds and play a Brownian noise sound file
turned up very loud to block out all sounds. It's probably damaging my hearing
but it helps. Music has patterns and songs have words both are distracting,
classical music is not too bad though it seems to help.

~~~
monsieurbanana
I've had Bose sound dampening earphones (qc20) and I urge you to buy them or
similar. You'll be able to listen to your noise sound file at much lower
volume while massively improving efficiency.

They are expensive, but if you truly are listening to too loud sounds you need
them.

~~~
mamon
Do such earphones cancel just background noise (like street traffic) or are
they also effective against human speech? I ask, because the kind of noise I'm
most interested in cancelling is my coworker's chit-chat.

~~~
loco5niner
I have qc20's and they are mostly effective against droning, repetitious
noises (think airplane noise). If the chitchat is far enough away, quieter,
and random enough (think coffeeshop/library) it helps a lot. If it's a couple
of co-workers sitting 6 feet away, it's not going to help enough unless you
listen loud enough to damage your hearing. That's my experience, but I already
got tinnitus from trying to drown out coworkers and have to keep music very
low these days.

------
neom
I can't code, but if someone interrupts me when I'm imagining, it's _gone_.

------
wcarss
I was hoping for more comparison to other types of knowledge work here, and I
think there's something deeper than what the author is describing, but this
post still makes a good point that likely applies in many cases.

I'd restate the author's thesis as: the problem of having to hold a ton of
state in your head which can be poofed out of existence by a small
interruption is mostly due to a lack of planning and of breaking the problem
down before diving in.

I have to agree with that. Many times I have wandered into a change and
expected it to be small, and after many small steps ended up in a mess of a
big commit that I need to break back down. Stopping at that point to "re-do"
the work in a smarter order feels wasteful, so I just try to split things up
logically and move on, but that place is dangerously susceptible to
interruption. Pre-planning my actions, perhaps with some notes or a drawing,
all taken while just reading the code, could likely reduce the end-work
significantly and also reduce the state that's poof-able.

However, I think that there are often complex things to keep track of in large
systems that small changes can impact, where trying to take notes of all of
these would be prohibitively time-consuming, and may even reduce what you can
fit in your head overall. You might not know what pieces to focus on until you
begin really working into things.

Good programmers have the ability to build this construct of actions and state
entirely in their head, and to see a manipulation of it that will result in
the change they want -- a kind of "large system comprehension" that the
classic comic embedded in the post demonstrates beautifully. It's a very
useful and complex skill!

So I don't think that it's something to always avoid. There's a middle ground
where you plan out things that are complex and you stop yourself from wading
into a swamp that's deeper than you realized to take some notes and break up
the work, but where you also work quickly and efficiently by exploiting this
very useful skill. I believe that becoming aware of this and finding that
middle ground comes to good developers with experience.

As to whether it's 'different than for other knowledge workers', I armchair-
hypothesize that you could break knowledge work up into classes of
interruptible activity: mathematics, engineering, programming, architecture,
probably work in medicine and chemistry etc. all likely have similar "large
system comprehension" as a fundamental skill that enables competence in the
field, and that requires real concentration -- they can have work that can be
poofed.

Other work like art, writing, argumentation, filing, etc I think are also
disrupted by interruptions, and they're annoying in the same way and can cause
a loss of flow, but the magnitude of the time lost, I think, is far smaller.
You can resume these tasks immediately but may be slower at it, versus needing
to spend 10+ minutes just to remember what you were even thinking about.

So, I'm tempted to apply the classic 'no' response to the headline, but I
still think there's real value in what the author said: planning is a part of
the skill of our work, and when we don't do it, we over-rely on our large-
system-comprehension skill, which exacerbates the interruption problem. The
relative boom of less experienced professionals in dev work may have led to a
lot of wading-into-swamps, and thus to an over-inflated sense among us of the
importance of not being interrupted -- even if interruptions are a major
issue.

------
whataretensors
> I don't believe we're as special as we think we are

Maybe if you believe this it becomes true. You allow people to tell you what
to work on, when to work on it, interrupt you, and generally walk all over
you. And you don't deserve any royalties right, because you aren't special?
Your fellow developers don't deserve higher pay or royalties, they aren't
special either.

Lets just see what happens when this mentality spreads. Developers will get no
choices and must all program uniformly. Creative solutions must be approved by
the board first. All decisions are made by shareholders and executed by
project managers. You will be judged solely on your story point outputs in a
perpetual 'sprint'. We can boil down every abstraction and implementation to
the lowest common denominator.

Self hatred and crab-in-a-bucket mentality are a straight path from this self
devaluation. I suggest we treat ourselves and each other as unique and
special, regardless of our hijacked 'scrum' processes that tries to turn us
into cogs. Not only do you avoid the risk of devaluation, you start to tap
into the potential in people that has been beaten out of them by 22 years of
indoctrination. This will only fully be untapped when developers realize we
are special, and we deserve things like flexible hours, unlimited remote work
time, planned vacations, and fair royalties.

~~~
krapp
>. This will only fully be untapped when developers realize we are special,
and we deserve things like flexible hours, unlimited remote work time, planned
vacations, and fair royalties.

Ok, but why do programmers exclusively (being "special") deserve these things,
but not employees in other fields, or employees in general?

~~~
jolmg
I think whataretensors's point is that we should be assertive to our own needs
regardless of how employees in other fields are typically treated. IOW, it's
not that they must be below us or us above them, but that we should not settle
for less than what we can and allow our de-facto standard conditions to worsen
on the rationalization that those are the conditions other employees in other
fields work in. If other fields demand better conditions and get them, good
for them.

~~~
thanatropism
But then that isn't "programmers should be assertive", it's "workers should be
assertive".

I don't even think knowledge/creative work is that special, really, or that
there is even non-creative work. (You should read about carpentry in either
Heidegger or Graham Harman's book about Heidegger).

------
indubitably
Programmers are just self-important.

~~~
jodrellblank
and that's a helpful description in what way?

~~~
indubitably
Helpful? It's just true.

------
EeJeg8oh
It is a tradeoff in my experience. Being interrupted by small requests does
jank me out of my flow but on the other hand immediately responding to a
problem can save them hours of being stalled by some issue. It's simply
necessary as a senior developer.

For the same reason I immediately often stop whatever I am doing when I get a
code review request as it allows others to get a specific issue done faster
and iterate on it instead of having to look for a different task in the
meantime and come back later to the issue under review.

On the other hand the tradeoff is not worth it if the issue is not an
immediate blocker.

