Yeah, speaking as an increasingly older developer, "resistance to interruption" is probably one of the cardinal skills you can learn as a developer. The ironic

Yeah, speaking as an increasingly older developer, "resistance to interruption" is probably one of the cardinal skills you can learn as a developer. The ironic thing about it is the actual skill you're developing when you do this is extremely valuable even when doing "solo, uninterrupted work", because, ironically, one of the greatest sources of distractions is your own mind's brainstorming. In doing "solo, meditative work", the hardest skill you have to develop is keeping your mind trained on the direct thing you're trying to accomplish, and not letting other parts of the problem intrude on your though process. If you've got any drop of ADD/ADHD (which by the "any drop" definition basically includes everyone), your mind will constantly get pulled away from the "task at hand" and start thinking about other parts of the problem. You'll be working on subsystem A (i.e. the task at hand), and you'll start thinking about how it interacts with subsystem B, and start thinking "oh gosh, I didn't realize this will also impose some constraints on subsystem C". One of the key reasons this is a mind trap is because these side-things are genuinely useful; you'll run into caveats as your mind starts exploring "the interaction of subsystem A and B", and start to realize B's actually going to impose some hard constraints on A. The naive thing to do is to assume "well, there's no point in designing A because of what I just discovered - I better figure out all those constraints first". What happens then is a sort of writer's block - no matter what you end up thinking of, you constantly get distracted with caveats and gotchas, and rarely manage to have a session where you can fully "think through" subsystem A and draft a complete design. If this tendency isn't policed, you'll have a tendency in all of your "deep flow" sessions to have your mind start the session by thinking about the real thing you're trying to build, but then aimlessly wander off onto the paths of all the ways your thing interacts with other stuff. Don't get me wrong - it's a useful thing to be able to do, but it needs to be deployed "at will" rather than being a gravity well your mind gets pulled into by compulsion. Ideally, even though you know some of it will violate some constraints, it's a hugely useful skill to be able to keep your mind on target and fully think through "subsystem A", any constraint-violations-be-damned. Sure, it won't work, but at least you'll have a mental sketch of the whole thing which can then be amended. Usually you'll find that the sketch is still mostly right, and more importantly, you'll now be able to conceptualize "the whole thing" instead of always getting stuck on the first third. --- The skills to maintain - and reestablish this "mental target lock" seem IME to be identical with the ones you need to stay in a flow state even with people around you constantly distracting you. Even if no "other people" are distracting you, and you're in a private office, you'll still be distracting yourself, so — I've found that a bulk of the improvement has to come from you, yourself, developing mental discipline on this, rather than from you having a favorable environment. Otherwise you'll have a private office to just daydream about development, rather than constructively thinking through things. A favorable environment can be great to have, but the ability to rapidly recover from distractions is something that makes a developer extremely effective even if they've got a favorable, external-distraction-free environment, rather than being a skill that becomes worthless if the external distractions are removed.