Flow: Not All It's Cracked Up To Be

As savvy internet consumers, you have undoubtedly stumbled across an article — or ten — about the importance of the“flow state”, especially in coding and programming work. Articles about the flow state are abundant— and abundantly positive. 

They make the flow state seem like an otherworldly achievement, noting its importance as a mental environment that enables developers (and the focus is usually on developers) to do their work better and faster than seems humanly possible. And there’s certainly some truth to those assertions. But they’re not the whole truth.

There is no denying that being in a flow state feels good. Even if you’re not a programmer, you’ve probably been “in the zone” at some point. Maybe you’ve had a “runner’s high”, or you’ve written 3,000 words in a single sitting, or you’ve been so engrossed in data entry you missed lunch entirely — all of these are, in their own ways, flow states.

It doesn’t matter what the action is: being focused and productive in that way feels good. And there’s a fair bit of research to back those feelings up. Including research from noted positive psychology researcher Mihaly Csikszentmihalyi, who describes the flow state as “a feeling of great absorption, engagement, fulfillment, and skill — and during which temporal concerns (time, food, ego-self, etc.) are typically ignored.”

Csikszentmihalyi is a firm believer in flow as the ideal mode of operation for people. He even has a TED Talk titled “Flow, The Secret to Happiness”, just in case it wasn’t clear how important to well-being he thinks flow is. But just because something feels good doesn’t mean it is good—at least, not unequivocally good.

And that’s where our trouble with the endless font of praise for flow lies. Elements of flow are great — no doubt about it — but it’s not always the best thing for the task at hand. To help explain what we mean, let’s bring it back to developers, the group that is cited most often when discussing the benefits of working in a flow state. 

Routinely you’ll hear developers talk about being in the zone in reverent tones, saying things like:

“I enjoyed being in the zone… I lost track of time. I lost awareness of my surrounds. I was detached from everything around me and was immersed in my task.”


“Ask any programmer what they love about their job and inevitably the conversation will turn to flow states… periods of intense absorption in the task at hand, where time seems irrelevant. Anybody who has gotten lost in the pleasure of an all-night coding session knows what I’m talking about.”

All-night coding sessions? Losing awareness of one’s surroundings? These don’t sound like particularly healthy ongoing lifestyle choices. And while a lot may get done in that state, one of things we value most highly isn’t really possible when you’re “detached from everything”.

Achieving that kind of separation from the world around you makes it extremely hard to produce thoughtful, user-friendly outcomes. You may code all sorts of features, but when you zone out you’re no longer critically evaluating what you’re doing. And when you’re creating products that millions of people will use, you can’t simply run on auto-pilot.

Eric Goldsmith, an Engagement Lead here at Myplanet, notes that while flow is a great way to get bulk work done, you miss out on the enormous benefits harnessed by connecting, sharing, and communicating with your coworkers. “I think when communities find a good rhythm for sharing information and perspective they start unlocking a very powerful growth mechanism for individuals and teams.”

And Shanly Suepaul, one of our Senior Drupal Developers, agrees: “Flow isn’t the best way to create value. I understand that it feels good when we’re in the zone,” says. “It’s natural to be drawn to flow. But even if flow allows a person to reach individual mastery, in most non-trivial development a single person is incapable of creating the best solutions on their own. We need to kill our cherished belief that flow reigns supreme and take a sober look at how we actually deliver value best.”

Flow feels nice. Flow is a great way to get a big chunk of stuff done. But we’re not aiming to simply complete tasks when we do our work. We want to create solutions, solve the real problems people face every day, and above all, we want to produce the best work we can. And we can’t do that without meaningful collaboration.

That’s why, to foster a more group-oriented methodology on a recent project, Eric and his teammates instituted a weekly session geared towards collaborative problem solving. They set it up so that while one person types, the rest of the room dictates the solution, instructing the typist on what to input. The results were spectacular. 

“It was really interesting how it started getting the information moving among teammates (things like style and syntax and how to think about problems).” And it’s exactly the kind of thinking Shanly points to as the way to arrive at the best solutions, not just the ones you can code quickly and in isolation.

To be clear, we’re not here to tell you to abandon flow altogether. But here’s the reality: clients are demanding. Offices are busy. Coffee shops are loud. Kids don’t respect the boundaries of the “home office” space. Basically, life doesn’t cooperate.

Is it worthwhile to do what we can in shared workspaces to minimize disruptions and give people the chance to focus on the tasks at hand? Of course it is. Setting quiet work hours, using asynchronous communication to allow people to respond at their own leisure, and having quiet spaces are all great ways to promote non-distracted work.

But we refuse to believe that it isn’t at least equally worthwhile to be able to effectively work with (and in the presence of) others, to learn to have the mental agility to switch focus when necessary, to recognize that as individuals, we are not infallible, and to call on the strengths and thoughts of others to make our work stronger.

When we praise flow as some sort of be-all state, we send a number of troubling messages:

  1. That you should be staying at work all hours of the night, completely neglecting your personal relationships and life outside the office, not to mention your health.
  2. That developers who work in this way are somehow better than the rest, contributing to a culture that gives extreme coding a mythical, “unicorn”-type status.
  3. That individual output matters more than the overall output. One person may produce a large quantity of work with few errors when they work in flow states predominantly, but if the work produced isn’t the right solution to begin with, it’s not the right way to work.

Flow has benefits and advantages, but so does work produced outside the flow state. All night sessions can be inescapable on a deadline, or even be a satisfying way to work from time to time, but promoting that mode of work as a lifestyle is a sure-fire way to burn out staff, create myopic work, and discourage collaboration across teams.

Instead of lauding a singular mode of production as the best, it’s time to be honest about the limitations of the flow state and encourage greater balance — both in the methods we use to produce work and in the way we live our lives.

Whether you're anti- or pro-flow, we want to hear from you! Let us know what you think or share the article with your colleagues and spark discussion in office.

Written by

Leigh Bryant

Leigh Bryant

Sign up for our newsletter