I disagree. > 1. Business value isn’t always a measure of coding velocity. Interruptions are often gifts in disguise. The value isn't in the interruptions its

I disagree. > 1. Business value isn’t always a measure of coding velocity. Interruptions are often gifts in disguise. The value isn't in the interruptions itself, but rather in the injection of context and perspective to the work being done. Those can be delivered through interruptions like email and chat, but it is by no means necessary. Relying on interruptions is just a lazy default that results in much less real value delivery than could be achieved with a more thoughtful approach to organization design and workflows. > 2. The ability to work in a way that allows for interruption is a skill that can be learned. Working deeply on a problem without interruption (no checking email, HN, etc.) is the real skill, and one that is getting increasingly difficult to practice. > Over the years I’ve learned to recognize interruptions as opportunities to re-assess my priorities. That's a good habit, but it would probably be better to just minimize interruptions and set aside time for such reflection. > I’ve also learned to write code in a way that reduces cognitive load so that interruptions aren’t so disruptive to my productivity. This seems promising, but I would be willing to be that the benefits of reducing cognitive load would be even greater in an environment of minimal interruptions.