Are interruptions worse for programmers than for other knowledge workers?
dev.to
dev.to
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.
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.
In particular "habitual" responses being improved by having an audience and non-habitual responses being hindered.
https://en.wikipedia.org/wiki/Social_facilitation#Attention_...
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.
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.
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 :)
As soon as we have an idea we immediately open up an IDE, and then get a GIT repository going, and get Yarn to prepare all the libraries we need, and get a quick little back end database api set up, and then a quick little front end framework and then we are...
finally ready to start experimenting.
`cp -R` is a thing.
I've been using permutations on the same dev stack for backend stuff for--well, before I wrote a new one[1], about five years.
This sort of middlebrow thing isn't good or helpful.
` alias initblock='function __initblock() { mkdir $1 && cd $1 && degit 1wheel/d3-init && gistup -m $1 --private --no-open && subl . && hot-server; unset -f __initblock; }; __initblock' `
git clone https://github.com/myaccount/proj_template.git newprojThis 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.
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.
you mean email? :-p
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.
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.
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.
What would you do?
I'm happy to see that I wasn't entirely out of my mind...
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.
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.
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.
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.
A lot of seminal jazz was created on the fly in fairly rowdy venues. But even in that genre, there are performers who can't stand interruptions: http://slippedisc.com/2014/07/keith-jarrett-is-disgraced-in-...
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.
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.
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.
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.
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."
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 :)
What presentation are you talking about? I'd be interested in reading it.
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...
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.
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 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?)
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"
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.
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)
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.
Sure, notes are useful, but your mental representation of the issue is your cache. With lots of cache misses, you are much slower ;)
Then somebody pings you with some completely unrelated urgent thing, and poof! goes your mental model out of working memory.
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.
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 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.
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.
It doesn’t help me so much with this week’s story (I fuckin hate Scrum now) but it helps in the long run.
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.
Who cares? It's not a competition. The fact is that it sucks for programmers and we want to avoid them.
> 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.
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.
Oh, so "figure out how to draw the rest of the freakin' owl".
The rest Of the post is about how you don’t need to draw the entire owl.
//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
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/
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.
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.
This is untrue in many complex problem domains.
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.
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.
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.
When I started my career I encountered a beardy-sandal-wearing systems programmer[2] , who 100% believed that there should be more comments than code in a program. His approach was to use the comments to write out long-form exactly what the program would do. He would write the whole solution as 1000's of comment lines, from start to finish in one big comment block. Once he'd done that, he'd then start again at the top, and split the comments at a natural point and insert real code to reflect the 100 or so comments above it.
At the time, I thought it was a crazy way to do it, and even now I wouldn't do it. But it had it's upsides. His code was really easy for others to maintain, and it was also fundamentally self documenting.
---
[1] http://dept-info.labri.fr/~strandh/Teaching/MTP/Common/Stran...
[2] Ironically, my beard is now WAY longer than his ever was.
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").
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...)
Surely interruptions are bad when you are programming, but interruptions are as bad when you are doing any other intellectually intensive task.
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.
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.
I think the extremes you want are more "code monkey" and "architect".
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.
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.
Many times I start where I think it will be a simple change but it turns out to involve much more than I realized.
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.
They are expensive, but if you truly are listening to too loud sounds you need them.
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.
This tinnitus mitigating trick on reddit somewhat works, it's odd: https://np.reddit.com/r/WTF/comments/3l3uri/these_guys_light...
Also, as the other commenters said, do not damage your hearing.
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.
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.
Ok, but why do programmers exclusively (being "special") deserve these things, but not employees in other fields, or employees in general?
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).
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.
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.
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.