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.
If you liked this post there're two more things I'd like to tell you about. First, I'd love to have you join my newsletter that everyone from first-time devs to CTOs read weekly.
Second, I just wrote a completely free email series with the kind of stuff I wish someone told me sooner after 10 years of development.
Top comments (2)
The most universal life lesson I learned as an EMT was that "in a crisis situation, you revert to your level of training." If you don't know what you are doing, no amount of concentration will save you.
I was in ocean rescue, I know what you mean. The neat thing about being in/near emergency services is the amount of training and practice that happens behind the scenes.
Almost like... setting up intentional time to get good so our autopilot works better than not.