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.
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.
My problem, as a programmer, is that I can’t easily express what I’m thinking on screen/paper. I already do draw out a lot of it, when I can, but its not enough. I already try to document what’s in my mind before I commit it to code, but the “house of cards” mental aspects don’t go away, so there’s really not much difference between distracting me from documenting my thoughts and distracting me from writing code, both are equally as detrimental.
It depends on what I’m working on, of course, so I think its essentially when problems become too abstract, then I can’t easily translate my in-my-mind understanding to paper/screen.
I did, however, enjoy my time playing with Max/MSP (a visual programming language) for the exact reasons you mentioned: I could think “out loud” so to speak, at least to a larger degree than I can in text. Pseudocode helps, a bit, but I’ve always found boxes-and-lines better to focus my thoughts. Incidentally, whiteboards are one of my favourite programming tools :)
When I get in the zone, especially at the very beginning of coding for a new project, I can't type or write fast enough to keep up with everything in my head. It's on all levels - high level of hope the whole system works, down to the minute details of how some of the smallest components work. I typically bounce around, flushing out enough details of a small component to be sure it works conceptually, and then going back to the broader picture to fit it in. I'm rushing to get as much documented as quickly as I can.
This includes a mix of writing code, drawing on a whiteboard, sketching on paper, and taking point form notes.
Even as I get writing placeholders for unit tests, it often leads to thinking of another case of situations that goes back to inform the high level design.
I think also the motivation can be a factor. When I start getting into this mode, it's highly motivating to keep going. If I get so interrupted as to lose some of what I had figured out, I find it can be hard to build up that motivation to even get going again. It's actually demotivating to start into it, run into a new problem, then realize I had actually already thought of it and the work I just did has to be changed - whereas if I had kept going the first time that wouldn't have happened.
I'm an artist as well as a programmer. It looks like one of the things you're not appreciating is the sheer size of most commercial codebases. It's not possible to keep it all in your head, or even scribble meaningfully about it in a notebook. It's barely possible to keep the bare minimum you need in your head, and that can take a while to build up -- and then poof, it's (somewhat) gone because your coworker can't Google a simple question.
If it was just the size, it would actually still be manageable with a notebook -- but it's not just size. Every single character on every single line matters, to some non-negligible extent. If you could condense that into a notebook, you'd condense the code in the first place.
Imagine you (and your ancestors) had written five hundred novels. Now you're making a significant change in the storyline. You need to be DAMN SURE you didn't miss anything anywhere, or created any plot holes. You can either take a million notes as you go, defending against all possible interruptions, taking obscene amounts of time; or just try and focus and get it done.
Apologies HN for the brief comment, but I wanted to make excited noises about how similar your process echoed with how I'd describe my own (especially the "magic time where I try to take the whole problem space into my head" aspect) but within programming. Although, to be fair, even when I'm doing an isolated component on paper programming seems to necessitate that I keep the "local state" up to some reasonable logic isolation boundary in my head as well. It's oddly reassuring to find that I'm not as inefficient/off in left field (with my thought processes) as I thought I was, for whatever reason this isn't a conversation I've had much with other peers.
I'll try to make this post more useful than self congratulatory by echoing: Notes notes notes. Whiteboards, sticky notes, and a giant perpetually updated todo list in an email draft (discount-evernote :) ), have been my saving graces, even while my memory gets worse as I age.
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...
I find setting up the environment a nice warm up routine that I wouldn't want to skip. Also, it takes just a few minutes, which is probably less than searching for that "template project" that I prepared those weeks / months ago. I guess everyone has their own creative process... :)
> My ideas are in tangible form as soon as possible.
In programming terms the tangible are the concrete things... the code on the screen in tangible, but when you start inferring meaning, concepts, origin, relationships etc in your head (or the reverse - doing that before you write some code) - that stuff is the quantum probability field that you need piece and quiet for, when that guy comes and asks you a question it collapses and you start over - if your very lucky you might get some state back and it wont take quite as long.
But here's the thing... the more complex the problem the longer you need to stay in that state - building it up larger and then refining it and so on, and the more important quiet becomes. Sometimes I don't mind noise if i'm just hoping from one "tangible" bit of code to the next doing some fairly mindless debugging that doesn't take a whole lot of insight, but most of the time i'm not.
But it's hard we all need to communicate eventually, constant meetings are no good, I find the best thing is this new instant messenger trend... not because I like being pestered but because I can turn off the notifications and then go and check it when i'm done on my current chunk of thinking.
> I find the best thing is this new instant messenger trend... not because I like being pestered but because I can turn off the notifications and then go and check it when i'm done on my current chunk of thinking.
No actually, there is value in instant messaging, and I admit I wasn't exactly enthusiastic about it at first... if you are available it's very productive having instant communication, very short back and forth without assumptions (strangely having it less immediate than a phone call and more more than an email _is_ advantageous, it brings clarity, forcing you to think more before putting responses into words, but immedite enough to not encouraging monologue and digressions at the same time).
If you aren't available, you can just collect little messages - better still the person who sent them can edit and refine their messages after they realise you aren't immediately available - you can't really do any of that with email.
What I still don't quite get though, is why anyone should be paying for this.
As someone who does both (artistic, design type stuff, and also coding), I can confirm that it doesn't work like that for coding. I do draw stuff, arrows, blocks, layers, whatever can help me, but everything pales in comparison to sitting get still, with your eyes closed, and holding all that abstract construction in your head. Especially since I can be imagining days/weeks/months of work in one go. Artists have a huge advantage here.
That's why personally I'm a big believer in functional visual/feedback based tools for programming, like touch designer, grasshopper. Strictly for code there's Light table, but it's pretty far off of real visual programming tools.
These help a lot in offloading some of that brittle house of cards construction you have to store in your head.
Trying to write down your thoughts can be considered a form of interruption too. It's a bit of a trade off or risk control. How much time to conceptualize it versus interrupting the conceptualization and writing down an inferior version of the idea?
Iteration does help improve on the inferior version, but the risk is that you might be iterating on a local maximum instead of the more global maximum you could've conceptualized.
This goes for programming too. Plus writing things down forces you to explicitly examine your thoughts, abd helps you catch contradictions before spending valuable time implementing it and realizing what you write was bogus.
That's enlightening. I always thought artists had the whole paint in mind before starting, never considered that it wasn't like that. Arguably it was one of the main deterrents to do any kind of drawing: it took too much effort to have the whole picture in mind!
I'm happy to see that I wasn't entirely out of my mind...
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.
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.
I think it boils down to something like long term memory vs working memory.
In my experience, even if I get interrupted playing a piano score that I practiced hard, I still remember the whole notes and I can easily come back to the state, because the main thing to remember is where I have stopped playing and this easily fits in my working memory.
Opposed to that, when I'm in creative mode, I heavily rely on working memory and when I get distracted, new info comes in and my working memory easily blows up. I forget what I was thinking about and cannot come back to the state before I got distracted.
Network engineer turned coding n00b here. I like your definition.
Interruptions are the same for me coding as they were when I was troubleshooting a difficult network issue. There's so much to consider and as you're iterating through your mind interruptions at the wrong time can be brutal... there's just so many ramifications to consider as you cycle through possibilities that if you're loose your train of thought you really do have to start at point A again if you're going to be careful about what you're doing.
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.
I'm not sure. The thing with the musician is that they're not really being interrupted. Sure, there's lights and movement and such, but that's more similar to the background noise we get in an open space environment, which many of us manage to filter out. When they are really interrupted, they are often pissed off too.
Not at all my experience. Interruptions when designing is, to me, almost free. It's a completely different mental process at work compared to programming. One which does not need much wind-up time at all.
I wouldn't say creative work and "create new things that don't exist yet" is what's defining for expensive interruptions. Rather, whether you need to keep a lot of stuff in mental cache or not. That is not true for a large subset of design work.
Edit: My personal experience is that interruptions during design work is, in contrast, almost welcome. Once you come back to your designs after an interruption you often see things in a new light and catch stuff you previously didn't see.
Yeah designing generally has the benefit that when you look back at what you've been working on the whole thing can be taken in at once, in other creative fields you have lost the context and what you were thinking about - you need to go back and look things over.
> 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.
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.
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.
> 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 works well.
Yeah, keeping a text editor with a task-specific file open while I work has been something of a revalation for me. I get distracted or thrown off easily, so it really helps reduce the amount of time it takes to get back to the mental spot that I was at. That, and if I need to leave right after I figure something important out, I’ll put a train of thought note wherever I am in the code without comment delimeters so that I can’t compile until I read it when I return.
> So basically I'm just documenting my train of thought as I setup a new application environment - nothing formal.
You can take it one step further and automate that with something like Terraform. Or more primitively bash scripts but that leads to snowflake environments over time as you said.
I think the author's premise is that interruption aversion is symptomatic of how many programmers work and that there are habits one can develop to minimize the impact of external distractions. The presentation from Tom Stuart goes into much more detail.
My personal experiences have led to a waning sympathy for coworkers complaining about too many meetings or interruptions. It's a reactive complaint. The most productive engineers on my teams also tend to be the most disciplined in managing their tasks, guarding their calendars, and employing every Do Not Disturb option available.
To be honest, I think for a lot of developers the premise is already pretty flattering. I'd love to see a presentation titled: "You Were Not That Productive To Begin With, or Why That Fortnite Stream on Your Second Monitor Might Not Be Helping Things."
Haha. Good point. I hate interruptions for an opposite reason from others - they give me no time to prepare a proper response to the interrupter.
My CEO used to bust into my office and want to talk high level tech strategy, meanwhile I’ve been staring at the same for loop for an hour. I finally had to tell him that I cannot switch gears that quickly, and if he wanted a coherent conversation he needed to schedule a meeting :)
Workers aren't well empowered in many of those situations, at least in my experience.
Those productive engineers? They figured enough of office politics skills to do the equivalent of taking a manager to a dark alley, then leaving the mutilated remains hanging from the "gate" to their time.
Unfortunately, those skills are not skills we teach anyone, at least not in computing. Meanwhile, project management seems to be a common subject in engineering classes in other areas...
I completely agree it is a dysfunctional work environment where the engineer's only recourse to having a sane schedule is taking their "manager to a dark alley."
That said, framing the problem as: "those skills are not skills we teach anyone" is the problem.
Once you can recognize a skill gap, you can fix it. You can be the teacher.
Well, I recognize my own lack of skills there. What's worse is that I also have a generally uphill battle with interpersonal skills, so I'm really not the person to teach them to anyone.
However, so long as we don't have professional courses taking this into account I don't think we can talk about teaching "software engineers".
> > I don't believe we're as special as we think we are
> I don't like the premise.
I don't like the implied conclusion. Why shouldn't you be allowed to feel special or enjoy it or request that unpleasant things don't happen unless absolutely necessary?
What merit is there in saying "well you can actually cope with interruptions even though you hate them, and because you can you now have to, pleb".
(And in the post and the replies to it, where's any concept that different people are different and think about things differently?)
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.
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)
In a similar vein, trying to reconstruct a reported error from application logs or crash dumps is, in my experience, murderous when combined with interruptions. You're trying to piece together why this unexpected error occurred, cross-checking source code, multiple log files, screenshots, and fragmentary narratives provided with the report, to build a mental model of what the state of the system was when things went south.
Then somebody pings you with some completely unrelated urgent thing, and poof! goes your mental model out of working memory.
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.
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 ;)
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.
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.
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.
+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".
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.
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.
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)
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.
> 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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
"""
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.
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.
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").
> 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...)
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.
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?
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
Be careful with damaging your hearing. A common side effect is tinnitus, which is basically hearing a constant distracting noise that you basically can't do nothing about. If you're prone to be distracted by noises, and want to do work that requires focus, tinnitus will likely be a life-altering catastrophe for you.
Thanks for your concern but as a kid I had constant ear infections so I have had tinnitus all my life even now a high pitched ring is constant. I don't even notice it unless I think about it I'm so used to it. But the loud static certainly won't do it any good!
Try electronic music, or on Spotify there is a "deep focus" playlist. On YouTube and Spotify there is "No Copyright Sounds" which is also this kind of music. I play this stuff all day at work. It sets a tone and keeps that part of my brain entertained but does not invoke distracting emotions (which is what good music is supposed to do.)
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.
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.
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.
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.
> 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.
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.
>. 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?
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.
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).
Having witnessed this, reminding me of luxury work camps supressing exploration, creativity and then dealing with distractions. Burn out happens faster.
The company doesn't have to provide Google style free lunches. Just flexibility. The same as any office worker. Should the worker need to exercise it without feeling pressure.
I've been in places where developers sit next to customer service agents who have remote work rights while devs do not. The excuse? Devs work too closely with operations.
I'm not sure devops should always mean devs are physically next to ops. The amount of interruptions the two deal with are insane. Smallest incidents needing devs attention.
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.
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.