Programming Flow considered harmful

For several years I believed that a developer should strive to reach the flow state for optimal performance. The flow state, colloquially as being in the zone, is a state of mind in which one is fully immersed in the task they are currently working on. The job will feel effortless, and we often make rapid progress.

As developers, we find this state valuable since no distractions can influence our thought process as we juggle variables, conditions, and loops in our heads. We are constructing a mental model of the behavior of our application in our mind. The downside is that we lose our thought when interrupted, and the entire mental model collapses. And thus, we need to start over, recreating our mental model.

As a result, many developers try to prevent interruptions, and certain companies will encourage this behavior since there is a clear and measurable difference in performance. A blog post on Stackoverflow even provides us with a few numbers. For example, some interruptions, but not all, will result in a developer having to take 10 to 15 minutes to restore their mental model before they can continue working.

As such, there is no denying that the flow state can be advantageous. Yet I will claim that the flow state is harmful in the long run.

How to enter and exit the flow state

Entering the flow state requires a few conditions. First and foremost, the task should be straightforward, and the method of completing it should be known. The job should be of such a size or complexity that it can preoccupy us and must be considered achievable yet challenging. Any progress should trigger the reward center of our brain. Too easy, and our brain won't think it was rewarding. Too complicated, and the constant flow of happiness in our brain gets interrupted, and we will exit the flow.

Entering the flow state itself is relatively easy. We most likely do it all the time, but we don't consider it"being in the zone" since we exit it reasonably quickly, sometimes within seconds. And this can easily be proven with the most prominent distraction device ever: The mobile phone.

I'm sure most of us have grabbed our phones, visited a few sites, read the news, looked at our email, and put it back down, only to repeat the entire cycle a few minutes later. And we do this multiple times a day. At the same time, many of us have experienced that we have opened a game or started doom scrolling only to be surprised by the amount of time lost when we are interrupted by the low energy warning. The last example is also an example of being in the flow. A game is designed to provide us with increasingly more difficult challenges that match our growing mastery of the game. At the same time, doom scrolling rewards our curiosity by giving us more information.

By the way: I recently realized my experience with generative AI (such as Stable Diffusion, Dalle2, or mid-journey) could easily be compared to gambling. Every time I hit "generate," I pray that the result will be appealing; it feels a lot like the one-more-turn syndrome that I have when playing games like Civilization.

The most challenging thing of the flow state is thus not entering it but staying in it when we want and need to.

How to prevent the downside of the flow state

You may have picked up a few of the difficulties when the working of the flow state was explained. For starters, we need a task with a specific size and complexity. Of course, if the tasks don't meet the criteria, we can remedy this by proposing a change to the task. For example, we might choose to over-engineer it. That way, our brain's reward center is more likely to be triggered. Thus, we are more motivated to work and therefore seem more productive. The fact that developers are willing to increase the work shows that the flow state might be addictive. The worst part is that we end up developing subpar solutions.

The flow state only results in an above-average performance because we are comfortable. Our performance is optimized because we are doing work that comfortably challenges us. But is the amount of output and comfort we experience a good metric? Or should we prioritize the quality of our work and the needs of our users?

Although staying away from the flow state should not be a goal, we can limit the adverse effects. There will always be work that can result in us achieving the flow state. However, we should consider leaving the flow state a good thing. If leaving the flow state becomes problematic, consider it a clear signal that we have a skill, knowledge, or scope issue. The first two can be resolved with training, while the scope can be overcome by breaking down the work into smaller jobs.

Entering the flow state, although advantageous, can be considered harmful and a signal for limits within the team. Therefore developers should not optimize for it. Instead, they should use different techniques that improve both quality and performance.

Thank you for reading Powered By Developers. This post is public so feel free to share it.