Flow, a state of total immersion in a task, was researched by Mihaly Csikszentmihaly (pronounced - "six-cent-mihaly"), and first presented in his 1990 paper: Flow: The Psychology of Optimal Experience. He describes flow as:

A state of concentration or complete absorption with the activity at hand and the situation. [...] The flow state is an optimal state of intrinsic motivation, where the person is fully immersed in what he is doing. This is a feeling everyone has at times, characterized by a feeling of great absorption, engagement, fulfillment, and skill.

He goes on to describe that the key to attaining flow is to pursue an activity for its own sake rather than the rewards it may bring. Like writing something you have no desire to publish, or completing a r/dailyprogrammer task that will never leave your editor. We're all chasing that feeling of being in the zone, where your fingers dance across the keyboard effortlessly and it feels fantastic just to be creating something, anything.

That's a great feeling but how often do we attain flow when we're writing code that does have a greater purpose? I find it quite easy to do so when it's on a personal project. There, the goals of the project are clear in my mind and how deep I go on each part is up to me. I also set the standards of the code and the project and don't need to worry about a linter's approval.

Is it possible to attain flow in an environment where standards are set by committee? I started a new role four months ago and have yet to really feel like I reached that flow state yet. On the other hand, I definitely was able to achieve it in my previous job: in part because of a sense of familiarity from being there for three years. I could quickly tell if a developer was serious or joking; I knew their code quality and trusted their ability to improve mine; I had internalised our JSHint and JSCS preferences so they had become second nature to the way I wrote.

Something else we had, and the aspect I think is the most important to achieving flow, is a deep understanding of the goals: of the code, the feature and the product.

Performance, accessibility, reusability and lifespan are all spectrums on which your code lies. Knowing where it needs to sit in advance allows you to make your decisions at a higher level and trust your own judgement on whether or not it is "correct" when completed.

Understanding the feature will allow you to know what is required of you and also how much time you think is worth spending on it. If it's a critical piece like implementing authentication then you'll want to spend time on it up-front and ensure it has a great test suite. If it's a feature to add a map to a page perhaps you want to just get it out as fast as possible to see if your users will actually even use it before spending more time on it.

And understanding the goals of the product are crucial. Who are you building it for? Who are your competitors? Having a mission statement can help but can often be too vague and ethereal. Simple tangible goals such as: "It must be easier to complete for a first time user than product X" or "It doesn't need to be extremely performant because it's only accessible from the office" lets you know that what you're writing at a micro level actually contributes to the eventual success.

The state of flow itself has downstream benefits beyond speed and morale: it is conducive to making better decisions. As Daniel Kahneman wrote in Thinking, Fast and Slow:

Riding a motorcycle at 150 miles an hour and playing a competitive game of chess are certainly very effortful. In a state of flow, however, maintaining focused attention on these absorbing activities requires no exertion of self-control, thereby freeing resources to be directed to the task at hand.

It needs effort from everyone to achieve this but could be crucial to getting the most out of yourself and your team. Good products are also products of a good development environment and this goes beyond the purchase of headphones or beanbags for each employee. If it's possible to achieve flow on your own projects it must be possible to achieve it in any project given you are able to craft the right environment.