I find that I can tolerate distractions like getting up to get a cup of coffee or stretch or do a few push-ups without much issue. I am able to maintain complex state and jump back into the flow. Maybe this is just a young brain thing and will go way, but in any case, this advice seems to be more tuned to those sorts of distractions. What happens in an office is entirely different. Your working memory is finite and social interactions are complex. Moreover, most people become personally offended (whether they will admit it or not) if you do not appear to be paying full attention. This was a particularly bad case but I once had a boss who would become visibly angry if you even stopped to write some notes when he showed up to interrupt you. Many of these interruptions are totally irrelevant too. Your boss does not need to stop by 4 times a day to get a detailed progress report. Your chatty coworker does not need to talk about his weekend at the lake. It's perfectly natural to feel some annoyance in a situation like this and it seems kind of absurd and subservient to me to ask devs to bend over backwards to accommodate the personality flaws of their bosses and coworkers. Sure, you shouldn't let this annoyance derail you, but that doesn't mean you also shouldn't tell your chatty coworker to shut up occasionally. Okay, maybe you shouldn't be so rude about it, but you need to set healthy boundaries and be allowed to block off time for the work you need to do. If you aren't, you are probably working for a shitty boss or organization. No amount of distraction management is going to help you there.

Beyond that, I think that there is a limit to the complexity of problems that can be tackled without periods of extreme focus. Some problem domains are full of deep and irreducible complexity. It's probably true that we often mistake accidental complexity for irreducible complexity or fail to break down problems, but, and this may come off as arrogant, I find that it is generally people that have never had to deal with a problem domain with such irreducible complexities who think that we can solve all of our problems by breaking up work into smaller chunks. Sometimes you also have to deal with business requirements that effectively turn accidental complexity into irreducible complexity. Like, yes, technically things like regulatory compliance are accidental complexity but we also can't just simplify them away without facing serious repercussions. It's also much much easier to maintain context and state in problem domains you have worked in extensively for years, and you tend to be able to write more concise yet still complete descriptions of things within that problem domain. I suspect that has something to do with why the author only adopted this working approach later in life, in addition to the health problems he mentions. For instance, I find that I can pick up physics and math problems with minimal friction because I spent the better part of a decade studying those subjects intensely, but ask me to debug a SQL script (an area where I have minimal domain knowledge) and I will need probably 30 minutes before I can even think a useful thought about it. Most devs do not have the luxury of only working on problems they are domain experts on. Business requirements and capacity are fluid things.