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 s

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.