Peak Performance: Programming and the “Flow” State

Like any professionals, programmers strive to be the best that they possibly can in their field. Whether by studying algorithms, learning new programming languages, or working with and creating new libraries, ours is a career that involves lifelong learning. Today, however, I want to discuss an aspect of coding that goes beyond knowledge: that of performance.

What does peak performance look like for coders? In some professions, it’s evident: the lawyer that wins an extremely difficult case, the doctor who performs surgery with flawless accuracy, the athlete at the proverbial ‘top of their game,’ and so forth. In ours, it’s a bit more difficult to measure, as coding is often a solitary pursuit — we spend hours by ourselves, poring over documentation, measuring our code against test specs, and fixing bug after bug. There is, of course, the idea of optimal code, which achieves results by using a minimal amount of resources — writing such code is certainly a good measure of a programmer. But how do we get into a mental state that would enable us to code like that?

One frequently referenced answer is the Ballmer Peak, an old programming joke that posits a programmer is at the height of their coding powers when they reach a certain level of inebriation. This isn’t always achievable, however, due to most companies frowning on drunkenness in the workplace and the fact that, well, it’s a joke rather than a serious prescription.

Instead, the answer may lie in a concept drawn from psychology. In 1990, the psychologist Mihaly Csikszentmihalyi (roughly pronounced like “chick sent me high”) published a book called Flow: The Psychology of Optimal Experience, in which he described what he deemed the “flow” state of mind. Flow, to Csikszentmihalyi, is a state of complete absorption with the task at hand — when one is so consumed with an activity that nothing else seems to matter. More colloquially known as being “in the zone” or “in the groove,” a flow state is a feeling of great fulfillment, skill, and engagement.

In a 1996 interview with Wired, Csikszentmihalyi characterized flow as “being completely involved in an action for its own sake. The ego falls away. Time flies. Every action, movement, and thought follows inevitably from the previous one, like playing jazz. Your whole being is involved, and you’re using your skills to the utmost.”

I first encountered this concept as part of my educational psychology classes at Teachers’ College, where we discussed it in the context of how to guide students into such a state of mind to ensure an optimal learning environment. After becoming a coder, I realized that the flow state could be applied to programming as well — just as it’s possible to get students into the perfect mental state to learn, so could we get ourselves into the perfect mindset to code.

So how do we achieve the flow state and potential programming Nirvana? Csikszentmihalyi outlined three key criteria that must be fulfilled for flow to occur. First, one must be involved in an activity with a clear set of goals and progress. This can sometimes be difficult when one is programming on one’s own — if we’re just playing around aimlessly, flow cannot occur. This is why structures like test-driven development and the ‘skateboard-to-racecar’ paradigm exist; they enable us to break our tasks down into a series of achievable goals on which we can bring our focus.

Second, flow requires that task at hand have clear and immediate feedback. Fortunately, feedback is abundant in the programming world — while error messages may not always be welcome, they nevertheless provide us with important information that enables us to adjust our approach and our performance.

Finally, to achieve a flow state, a person have a good balance between their perceived skills and the perceived difficulty of the activity. In other words, we need confidence in our ability to complete the task at hand. If something is beyond a person’s ability, it produces anxiety and self-doubt, while on the other hand, a task that’s too far below someone’s skill level induces boredom and apathy. Csikszentmihalyi plotted the relationship between skill and difficulty thus:

Ideally, we want to get ourselves in the upper right areas of the chart — this is where optimal performance as programmers lives. It’s hard to get there sometimes, though, as our working conditions may not allow for it. Sometimes the goals of our job aren’t clear, for example. While our work may fit within a larger organizational chart, this isn’t always made apparent. Furthermore, when there is little communication of feedback, an employee may not be assigned tasks that challenge them or seem important, which could potentially prevent entering the flow state.

Thus, to enable ourselves to enter the best possible headspace to code, three conditions must be present: goals must be clear, feedback must be quick, and there must be a balance between difficulty and ability. If we remain cognizant of these factors, it could help our coding immeasurably.