11 ms·

Are interruptions worse for programmers than for other knowledge workers?

204 points by axiomdata316 9y ago

clay_the_ripper 9y ago
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.
draw_down 9y ago
No, we’re huge babies about it and think everyone else’s job is less difficult and important than ours.
whataretensors 9y ago
> 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 9y ago
  >. 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?
  - deleted 9y ago
    [deleted]
  - jolmg 9y ago
    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 9y ago
      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).
  - deleted 9y ago
    [deleted]
- warent 9y ago
  I partially agree and partially don't. If the only thing protecting against self-hatred is to believe we're special, then it was a flimsy self image to begin with. Knowing our worth as developers is definitely important, but having humility is equally important. I would argue that other professions can be equal to software engineering on an intellectual/productive level, and simultaneously we still do deserve things like flexible hours, unlimited remote work time, planned vacations, and fair royalties.
switch007 9y ago
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 9y ago
  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.
EeJeg8oh 9y ago
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.
dghughes 9y ago
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 9y ago
  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.
  - dghughes 9y ago
    Thanks for the tip, that would make sense. Actually one of my classmates uses noise cancelling headphones in class. Actually in the entire program I've noticed many people use full entire ear covering headphones I bet 80% of the students. Now I know why.
  - mamon 9y ago
    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 9y ago
      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.
scarygliders 9y ago
> 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 9y ago
  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.
  - caymanjim 9y ago
    Trello is a great tool for this. There are plenty of similar tools as well, including open source alternatives. Your separate open file for mental stack dumping is a great option as well, and something I often use. My favorite, though, is a stack of black index cards on my desk. I like the immediacy, the ease of sorting, and the ability to quickly spread things out or stack them up. Best of all, there's satisfaction in tearing up that card and throwing it away when done. I use Trello quite a bit, but nothing beats the index cards for me. It's something I use both at work and at home.
yomly 9y ago
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 9y ago
  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.
- alexashka 9y ago
  We've automated away the trivial bits somewhat - the remaining bits require far more concentration than most jobs that are soon to be automated away (driving etc)
rb808 9y ago
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 9y ago
  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.
nopinsight 9y ago
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.
DaggerDagger 9y ago
Lets just say "problem solvers" and avoid the semantics. Problem solving is abstract reasoning. It requires flow state.
- thanatropism 9y ago
  I don't think anyone is being paid for creating problems outside of academia.
  - yaccz 9y ago
    Cashiers solve the problem of facilitating the transfer of appropriate amount of money from customer to the store but would you call cashier a problem solver?
throwaway080383 9y ago
""" 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 9y ago
  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/Strandh-Tutorial/top-down-programming.html http://dept-info.labri.fr/~strandh/Teaching/MTP/Common/Stran... [2] Ironically, my beard is now WAY longer than his ever was.
- bonniemuffin 9y ago
  Proper Prior Planning Prevents Piss Poor Performance I'd estimate that planning out a 3-hour task would take no more than 10 minutes-- why would you need a whole hour to plan something that's only going to take 3 hours? And in my experience, most of the time, those 10 minutes spent mapping out the plan will end up saving you more time in the long run, as you realize some critical assumption about the work was wrong ("oh I don't actually have to do X", or "oh I'm missing this key dependency and need to loop in team Y").
- egypturnash 9y ago
  > I can either knock out this feature in three hours, or I can spend an hour breaking it into six half-hour chunks. The first option carries more risk. Let's say you spend an hour building up the mental model of what's going on and what you need to do in your head from scratch. But you get interrupted ten minutes after that, and lose it all. You've now spent 1:10 with nothing to show, and will have to spend another three hours starting from scratch. Total time, assuming you don't get interrupted next time you try: 4:10. Whereas if you'd spent an hour planning, and then gotten interrupted ten minutes into your first half hour of working, you will have lost at most maybe ten minutes. Total time, assuming no more interruptions: 4:10. And then you start again the next day, and another interruption comes in an hour and a half. The you who requires three uninterrupted hours to do this just blew 5:40 total and still has 3:00 of doing it from scratch staring them in the face. The you who spent an hour chunking the problem into smaller tasks? Whatevs, you spent 2:30 getting solid progress, wasted 0:10 of work, and still have 1:30 left to do. If you can control your environment and minimize interruptions to, oh, one every two or three days? then not spending that hour up front to break the problem down into smaller chunks is workable. But if you're going to have some kind of interruption at least once a workday, then you may never get those three solid hours you need to actually figure out what needs doing, and do it. (This is of course a very rough model that assumes a programmer who loses all mental state upon an interruption, leaving absolutely nothing behind, be it half-written code that they could later use to reconstruct where they were going in somewhat less time, or a source tree in a completely broken state that will require even more time to fix...)
y0y 9y ago
> 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.
Bizarro 9y ago
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 9y ago
  > 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 9y ago
    ? The rest Of the post is about how you don’t need to draw the entire owl.
- mentos 9y ago
  I find just writing out the steps in comments then implementing the comments helps //First we need to get the users voice state //check if they are in a group or team channel //if they’ve opted out of auto-connect for voice then don’t connect them to the voice channel //etc
chrispyper 9y ago
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.
- ebbv 9y ago
  100%. This is what people fail to realize about programming. Sometimes our job is just writing stuff where we already know what we need to do. That stuff tends to go pretty fast. The hard part of our job, and what takes the majority of my time, is creating solutions to problems. And a lot of that time doesn’t even involve typing. I have to look through documentation, other people’s code, logs. And just think. The typing starts when I have an idea to try out. Interrupting that process is like detailing any other creative process. The problem is not the time I have to take to answer a question, it’s the time it will take to get back into the headspace the interruption took me out of.
  - deleted 9y ago
    [deleted]
  - JustSomeNobody 9y ago
    That is why I love pencil and paper. As I'm going through code I take notes. As I read doc I take notes. As I'm thinking I take notes. If I do get interrupted it's relatively easy to pick back up because I have all these notes. By the time I'm coding I'm almost always following a mostly fleshed out algorithm so it goes pretty quick.
- astrodust 9y ago
  Maybe you've boiled it down to "creating" versus "performing", where performances are done by reflex, by habit, by routine, while the creation process takes considerably more attention.
bane 9y ago
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 9y ago
  > 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 9y ago
    Except that "architect" is synonymous with "bullshitter" for insiders.
wcarss 9y ago
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.
jim-davis 9y ago
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 9y ago
  +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 9y ago
    Do it in something searchable so you can look for "have I ever puzzled through this class before?"
- deleted 9y ago
  [deleted]
seba_dos1 9y ago
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 9y ago
  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 9y ago
NPMaxwell 9y ago
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 9y ago
  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 9y ago
    Yes! All the more reason to keep all your short term memory for your work.
wenc 9y ago
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.
wenc 9y ago
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 9y ago
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 9y ago
  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.
markbnj 9y ago
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.
neom 9y ago
I can't code, but if someone interrupts me when I'm imagining, it's gone.
forinti 9y ago
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.
bedros 9y ago
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
mattkevan 9y ago
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.
BrandoElFollito 9y ago
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.
dkersten 9y ago
> 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 9y ago
  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.
indubitably 9y ago
Programmers are just self-important.
- jodrellblank 9y ago
  and that's a helpful description in what way?
  - indubitably 9y ago
    Helpful? It's just true.
yiyus 9y ago
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.
wcr3 9y ago
"knowledge workers" ... c'mon man.
fnordprefect 9y ago
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.
awinter-py 9y ago
> 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.
spc476 9y ago
Nope. Just ask Samuel Taylor Coleridge [1]. [1] https://en.wikipedia.org/wiki/Kubla_Khan https://en.wikipedia.org/wiki/Kubla_Khan
deleted 9y ago
[deleted]
thedailymail 9y ago
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.
rossdavidh 9y ago
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.
deleted 9y ago
[deleted]
ChuckMcM 9y ago
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.
perpetualcrayon 9y ago
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.
danieltillett 9y ago
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.
maym86 9y ago
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.
exit 9y ago
> 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.

204 points by axiomdata316 9y ago

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.

draw_down 9y ago

No, we’re huge babies about it and think everyone else’s job is less difficult and important than ours.

whataretensors 9y ago

> 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 9y ago
>. 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?
- deleted 9y ago
  [deleted]
- jolmg 9y ago
  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 9y ago
    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).
- deleted 9y ago
  [deleted]
warent 9y ago
I partially agree and partially don't. If the only thing protecting against self-hatred is to believe we're special, then it was a flimsy self image to begin with. Knowing our worth as developers is definitely important, but having humility is equally important. I would argue that other professions can be equal to software engineering on an intellectual/productive level, and simultaneously we still do deserve things like flexible hours, unlimited remote work time, planned vacations, and fair royalties.

switch007 9y ago

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 9y ago
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.

EeJeg8oh 9y ago

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.

dghughes 9y ago

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 9y ago
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.
- dghughes 9y ago
  Thanks for the tip, that would make sense. Actually one of my classmates uses noise cancelling headphones in class. Actually in the entire program I've noticed many people use full entire ear covering headphones I bet 80% of the students. Now I know why.
- mamon 9y ago
  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 9y ago
    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.

scarygliders 9y ago

> 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 9y ago
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.
- caymanjim 9y ago
  Trello is a great tool for this. There are plenty of similar tools as well, including open source alternatives. Your separate open file for mental stack dumping is a great option as well, and something I often use. My favorite, though, is a stack of black index cards on my desk. I like the immediacy, the ease of sorting, and the ability to quickly spread things out or stack them up. Best of all, there's satisfaction in tearing up that card and throwing it away when done. I use Trello quite a bit, but nothing beats the index cards for me. It's something I use both at work and at home.

yomly 9y ago

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 9y ago
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.
alexashka 9y ago
We've automated away the trivial bits somewhat - the remaining bits require far more concentration than most jobs that are soon to be automated away (driving etc)

rb808 9y ago

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 9y ago
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.

nopinsight 9y ago

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.

DaggerDagger 9y ago

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

thanatropism 9y ago
I don't think anyone is being paid for creating problems outside of academia.
- yaccz 9y ago
  Cashiers solve the problem of facilitating the transfer of appropriate amount of money from customer to the store but would you call cashier a problem solver?

throwaway080383 9y ago

""" 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 9y ago
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/Strandh-Tutorial/top-down-programming.html http://dept-info.labri.fr/~strandh/Teaching/MTP/Common/Stran... [2] Ironically, my beard is now WAY longer than his ever was.
bonniemuffin 9y ago
Proper Prior Planning Prevents Piss Poor Performance I'd estimate that planning out a 3-hour task would take no more than 10 minutes-- why would you need a whole hour to plan something that's only going to take 3 hours? And in my experience, most of the time, those 10 minutes spent mapping out the plan will end up saving you more time in the long run, as you realize some critical assumption about the work was wrong ("oh I don't actually have to do X", or "oh I'm missing this key dependency and need to loop in team Y").
egypturnash 9y ago
> I can either knock out this feature in three hours, or I can spend an hour breaking it into six half-hour chunks. The first option carries more risk. Let's say you spend an hour building up the mental model of what's going on and what you need to do in your head from scratch. But you get interrupted ten minutes after that, and lose it all. You've now spent 1:10 with nothing to show, and will have to spend another three hours starting from scratch. Total time, assuming you don't get interrupted next time you try: 4:10. Whereas if you'd spent an hour planning, and then gotten interrupted ten minutes into your first half hour of working, you will have lost at most maybe ten minutes. Total time, assuming no more interruptions: 4:10. And then you start again the next day, and another interruption comes in an hour and a half. The you who requires three uninterrupted hours to do this just blew 5:40 total and still has 3:00 of doing it from scratch staring them in the face. The you who spent an hour chunking the problem into smaller tasks? Whatevs, you spent 2:30 getting solid progress, wasted 0:10 of work, and still have 1:30 left to do. If you can control your environment and minimize interruptions to, oh, one every two or three days? then not spending that hour up front to break the problem down into smaller chunks is workable. But if you're going to have some kind of interruption at least once a workday, then you may never get those three solid hours you need to actually figure out what needs doing, and do it. (This is of course a very rough model that assumes a programmer who loses all mental state upon an interruption, leaving absolutely nothing behind, be it half-written code that they could later use to reconstruct where they were going in somewhat less time, or a source tree in a completely broken state that will require even more time to fix...)

y0y 9y ago

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

Bizarro 9y ago

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 9y ago
> 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 9y ago
  ? The rest Of the post is about how you don’t need to draw the entire owl.
mentos 9y ago
I find just writing out the steps in comments then implementing the comments helps //First we need to get the users voice state //check if they are in a group or team channel //if they’ve opted out of auto-connect for voice then don’t connect them to the voice channel //etc

chrispyper 9y ago

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.

ebbv 9y ago
100%. This is what people fail to realize about programming. Sometimes our job is just writing stuff where we already know what we need to do. That stuff tends to go pretty fast. The hard part of our job, and what takes the majority of my time, is creating solutions to problems. And a lot of that time doesn’t even involve typing. I have to look through documentation, other people’s code, logs. And just think. The typing starts when I have an idea to try out. Interrupting that process is like detailing any other creative process. The problem is not the time I have to take to answer a question, it’s the time it will take to get back into the headspace the interruption took me out of.
- deleted 9y ago
  [deleted]
- JustSomeNobody 9y ago
  That is why I love pencil and paper. As I'm going through code I take notes. As I read doc I take notes. As I'm thinking I take notes. If I do get interrupted it's relatively easy to pick back up because I have all these notes. By the time I'm coding I'm almost always following a mostly fleshed out algorithm so it goes pretty quick.
astrodust 9y ago
Maybe you've boiled it down to "creating" versus "performing", where performances are done by reflex, by habit, by routine, while the creation process takes considerably more attention.

bane 9y ago

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 9y ago
> 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 9y ago
  Except that "architect" is synonymous with "bullshitter" for insiders.

wcarss 9y ago

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.

jim-davis 9y ago

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 9y ago
+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 9y ago
  Do it in something searchable so you can look for "have I ever puzzled through this class before?"
deleted 9y ago
[deleted]

seba_dos1 9y ago

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 9y ago
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 9y ago

NPMaxwell 9y ago

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 9y ago
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 9y ago
  Yes! All the more reason to keep all your short term memory for your work.

wenc 9y ago

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.

wenc 9y ago

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 9y ago

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 9y ago
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.

markbnj 9y ago

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.

neom 9y ago

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

forinti 9y ago

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.

bedros 9y ago

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

mattkevan 9y ago

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.

BrandoElFollito 9y ago

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.

dkersten 9y ago

> 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 9y ago
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.

indubitably 9y ago

Programmers are just self-important.

jodrellblank 9y ago
and that's a helpful description in what way?
- indubitably 9y ago
  Helpful? It's just true.

yiyus 9y ago

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.

wcr3 9y ago

"knowledge workers" ... c'mon man.

fnordprefect 9y ago

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.

awinter-py 9y ago

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

spc476 9y ago

Nope. Just ask Samuel Taylor Coleridge [1]. [1] https://en.wikipedia.org/wiki/Kubla_Khan https://en.wikipedia.org/wiki/Kubla_Khan

deleted 9y ago

[deleted]

thedailymail 9y ago

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.

rossdavidh 9y ago

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.

deleted 9y ago

[deleted]

ChuckMcM 9y ago

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.

perpetualcrayon 9y ago

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.

danieltillett 9y ago

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.

maym86 9y ago

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.

exit 9y ago

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