> If the product quality depends on you maintaining a flow state for extended periods

I think you've conflated quality and productivity; you started talking about one then switched to the other. They are related but not the same.

Certain dev tasks require deep flow for good results/quality. Robust refactorings, abstraction design and prototyping. Basically anything where you have to preserve invariants under code transformations. This isn't all dev work, and isn't necessarily frequent either, but when flow state is required it's usually important work that's core to a program's operation, so product quality definitely depends on flow.

If you're working on such a task, an interruption requires a return to that flow state to ensure good quality, and that takes time and will definitely impact productivity.

Other tasks do not require going very deep though and so achieving comparable quality doesn't require much depth in your flow. Interruptions won't affect productivity much in such cases.

My two cents.

I think the key point of the line you quoted was "for extended periods". Obviously flow states are useful, perhaps even required in some contexts, but to demand a full day of uninterrupted flow-state engineering bliss is IMO unrealistic and very often counterproductive. Software development at the company level is a team sport, and being actively hostile to necessary communication simply because it "interrupts your flow state" is the act of a prima donna or "rock star" developer. I've refactored a lot of code/been doing deep design work and been interrupted during said work. Did it make my personal task take substantially longer to complete due to the task-switching/getting my flow state back? Sure, but the interruption was for a good reason and my help was actually needed. On balance the interruption saved the company money and time because the drop in efficiency of execution for my slice of the pie was less impactful than what my help was needed for.

Now if you're getting constantly pinged for stupid shit that anyone could Google, then perhaps you should politely confront the person(s) doing so and make your expectations clear rather than declaring a pox on all interruptions.

> Sure, but the interruption was for a good reason and my help was actually needed.

Wouldn't this be true of just about everyone complaining about such interruptions though? I can't imagine anyone would mind being interrupted if the building were on fire. People just differ on what they consider to be good reasons.

I'm sure there are unreasonable people on all sides, both those asking for unreasonable conditions to interrupt them and those not respecting reasonable conditions for interruptions, but I don't think it's the majority of the people complaining about it. I've been in this situation a few times, and lots of people just don't have good impulse control and so don't even think twice about interrupting you if it's more convenient for them.

I disagree. I can move through quite alot, quite well, when I can work in a deep flow. 2-4 hours of deep work can be incredibly productive end to end and we follow TDD pretty strictly, which lends itself well to really thinking about problems and their solutions in my experience thus far, but it requires the ability to really walk through a problem space.

Our code quality here has improved significantly around this, and we are shipping faster than ever.

That isn't to say I'm unavailable (or anyone else) its that there is an acceptance that not all things are urgent, and if they are, its warranted to break through any focus periods.

Doesn't sound like we disagree that much. You are actually available, but not all things are urgent. I'd say the difference at my workplace is that pieces of the product are extremely old, developed under different architectures with different technologies under multiple management regimes of varying quality. There's a lot of tribal knowledge, so everything is kind of urgent by default as someone new to a specific piece of code can't move forward efficiently without picking the relevant SME's brain. Forbidding interruptions would be akin to mandating "only the SMEs can work, and the rest of you need to waste money twiddling your thumbs or banging your head against obscure legacy code until they feel like helping you". Most of the time when I'm interrupted it's because someone's blocked and I have the knowledge to unblock them, or I can at least point them to who does, so my loss of flow state is their gaining the ability to move forward at all, and everyone benefits.

By contrast it sounds like you guys designed your product around maximizing the impact of flow states and minimizing the need for interruption. I bet you have good documentation too. I'm honestly jealous, it would take tens of millions and years of re-writes to do the same here, and our prime customer wouldn't be willing to accept the delay even if we had the funding.

It may not be that "only SMEs can work" but that "SMEs don't have 5 tickets this sprint but 3 high level deliveries over the next quarter" thus they are allowed work uninterrupted from the daily churn and focus intensely (contributing to their already high base knowledge). Whereas other engineers are constantly distracted and stay surface level trying to stay afloat.

I completely agree with this way of working, and we have the same “protocol” as it were. I check my comms once every one or two hours to see if there is any pressing matters.

So little is actually urgent, unless you have some business critical infrastructure you have to maintain, but that sounds like a different role entirely.