When Flow-State is Dangerous
The bliss of flow is something countless other developers and I work hard to create every day. The effort of our mentally taxing work relaxes, and magic happens as we lose ourselves in this wondrous state. Though, as the years went on, I concluded that this flow-state might not only be undesirable but irresponsible.
On the Road
A good example of the flow-state outside of coding is when we’re in the car. Everyone has that experience of realizing that we’re in the car and we’ve been calmly on autopilot the whole time. If we’re lucky, we snap-to for no reason. If we’re unlucky, we snap-to because something dangerous happened where we had to engage fully.
Why this analogy? Because the same thing is a lot like what we experience when we code. As we enter the flow-state, our entire body synchronizes up and moves into autopilot, and things just happen.
Most of the time at work, what snaps us out of that state is an interruption like a meeting or someone trying to get ahold of us.
The Danger
Just like on the road, we may be on autopilot, but that doesn’t say anything as to the quality of our autopilot. The same is true of our flow-state.
Take two developers as an example. One is a true master of their craft whose code is a marvel and seldom has a bug. The other is one whose work is a guaranteed source of bugs and outages and manages to create technical debt faster than they make code.
Now imagine both developers entering their flow-state for 4-6 hours, each producing code in their altered state of consciousness.
Whose do you want to maintain?
If that question is making you a little nervous, it should. Flow allows us to produce what we naturally do in a zen-like manner. It doesn’t make us produce better, just easier and sometimes more.
The next dangerous part is that flow can last for a long time. That prolonged state of flow, while joyous for the developer, might be a prolonged danger to the team, company, and codebase.
Yeah, But…
Look, I’m not trying to say flow is evil or that we shouldn’t enjoy it. I am saying that just because we enjoy it doesn’t mean the results match our opinion of it. Or, what we enjoy may not be what’s best.
A chef that routinely messes up dishes going into a flow state would ruin a whole dinner service.
Where I’ve landed is that pursuing flow continuously with headphones and all of that is irresponsible.
Instead, I focus on two things. First, I build into how I work specific moments of review and reflection. TDD is one of my preferred ways to do this. Second, I make sure some part of my day is intentional and high-effort around some nuance about how I code.
The best way to relate that last one is related to my writing. Unsurprisingly I can have a flow-state for writing, but it means I produce the same awkward sentences and grammar issues. On the other hand, if I forego flow and stay intentional through my writing and fixing some problems in my writing, when I do allow flow again that fix will remain.
Flow is a wonder to experience, but we have to pay attention to the product of our flow is and find a way to continually improve it, or we’re doomed to get more of the same.