I think he's right. A culture where flow is encouraged is bad because the risk of going down a rabbit hole increases enormously when in the zone. This makes it

I think he's right. A culture where flow is encouraged is bad because the risk of going down a rabbit hole increases enormously when in the zone. This makes it an inefficient way of working. I like to compare solving a programming task with navigating to a goal. Being in the zone is the equivalent of going really fast. Speed might be good in general, but it's really useless if you're going in the wrong direction. Navigation skills are in fact a whole lot more important than speed. In solving programming tasks you have to be smart - try to find shortcuts, ask interrogative questions about the requirements to avoid unnecessary work, check with your colleagues if someone has already done something similar, find libraries which will help you solve the task etc. So being in the zone is in my world just a sign of someone who's probably in a hurry and/or isn't working strategically. The only exception to this rule is when you're pair programming, because then you have a co-driver who's handling the navigation, so you're allowed to focus on going fast.