The flow state is valued too highly by the programming community

The term “flow state” was coined by psychologist Mihály Csíkszentmihályi and refers to the mental state of being completely immersed in a task. This state is highly valued by programmers because it allows them to maintain a larger amount of information regarding the task they are working on in their short term memory than they are usually able to. Anecdotally, many of us find that we are able to solve complex problems more effectively when we are in the flow state, and that we find our work more enjoyable.

Accordingly, some developers attempt to optimize their practice towards spending as much time as possible in a flow state. Many have shared their experiences of optimizing along these lines. A quick internet search for the term “flow state in programming” returns copious articles explaining the flow state, enumerating its benefits, and advising on how individuals can achieve it. However, I am not aware of any literature which questions its value within a broader software engineering context, which I feel is something of an oversight. In the remainder of this article, I’m going to argue that attaining flow perhaps isn’t the holy grail that many software practitioners make it out to be.

My argument rests on the idea that software development is predominantly about people rather than technology. This is a widely accepted view. Gerald Weinberg’s claim that “no matter what the problem is, it's always a people problem”, is quoted frequently within the programming community, and the image of the “10x developer” hacking away on their own for days on end before emerging with the perfect program is largely considered undesirable or unrealistic. It follows that if software engineering is a “people problem”, then code is written principally for people, rather than machines.

So, what does this have to do with flow? Well, the flow state allows an individual to maximize their own productivity and problem-solving ability, but at the often unmentioned cost of reducing that individual’s awareness of other people (and indeed themselves - Csíkszentmihályi considers a loss of self-consciousness one of the defining characteristics of being in a flow state). The reduction in awareness is unavoidable if one is seeking to achieve flow, because being distracted can cause the state to evaporate in an instant. Consequently, many writers advocate techniques such as blocking out large swathes of calendar time so that you can work entirely alone and without interruption.

Unfortunately, while this may be great in terms of one’s personal output, in my experience it’s rarely optimal for that of the wider team. Typically, developers that derive the greatest value from being in a state of flow are those who are able to work highly independently due to their experience and skill. However, these are also the developers whose time is in high demand from their team and other parties, either to assist less experienced team members or to contribute to broader concerns such as architecture. Over an extended period, forcing others to regularly wait for access to the knowledge they require to unblock their work can significantly slow the team’s overall progress.

I also question the assertion that being in a state of flow allows developers to deliver their highest quality work. While it is undoubtedly true that being able to hold more of the state of the program in one’s immediate memory can be useful when solving complex problems, I would argue that the intense focus required to achieve this can be detrimental to a developer’s recognition of the wider goals they are trying to achieve. On many occasions, I have found myself diving deep into a problem for several hours, convinced that I’m making progress in a good direction. Upon departing the flow state, I’ve realized that either a better solution was available or that, if I was being honest with myself, I had invested that time more because I was enjoying the experience rather than because the work I was doing was valuable to the project. Stopping to take a step back and review the situation would probably have delivered a better outcome.

Fortunately, there is an alternative approach available. The trick is to store as little information as possible in one’s brain whilst programming, thereby enabling one to work effectively without entering a flow state. One way of achieving this is to take extensive notes while you work, but the technique that I and many others prefer is test driven development. I find having a failing test to remind you of exactly what you need to do next to be incredibly powerful because you need to remember only the bare minimum of state you need to make the next test pass. Then, you can forget it completely and start with a new test. The beauty of this is that you get resumability for free - you can be interrupted without needing twenty minutes to get back into the flow of your work. Done well, test driven development also forces you to factor your code in such a way that state is not shared across testable units, meaning that it can be read without first building significant context. In fact, I would go so far as to say that if you’re finding yourself needing to get into a flow state to do your work, perhaps you need to look at how your system is designed to ensure you have the right abstractions in place.

I want to wrap up by saying that of course the flow state still has its place in software development. There are times when the codebase you’re working in is so gnarly that only complete focus will enable you to join the dots, and I’m not so curmudgeonly as to wish to deny programmers the joy of a couple of hours of flow now and again. But I would ask us as a community to consider our relationship with the flow state a little more thoroughly. Is it something we should prize above being consistently available to our teammates and leaders? Is it something we absolutely need to do our best work, as individuals, and as a team? I believe the answer to both those questions is no.