A job is for wage. You don't mention programming as a hobby. Flow happens when you're personally engaged and truly interested in the solution you're building. This happens more on personal side-projects than at work, where the modern work-environment makes sure to interrupt us as much as possible. If programming is just the objective of codifying some business logic for a company, you won't become personally engaged. Also, non-trivial and complex solutions may break flow, as you have to walk and think more. Flow is more for those passages of coding where you jot down simple, but lengthy solutions, then realize a simple refactoring will DRY up the code. Then after 5 such iterations with some YAGNI, you've skipped lunch that day! You became engrossed in the work itself. Music may help, but becomes a distraction for any deeper design-thoughts.

Nothing magical about flow, but feels very productive even though one might be working on the wrong solution all along! For gaming industry and huge codebases, programmers absolutely need to get into flow in order to manage to complete it all in time.

To enter a flow state you need to be working on something moderately challenging, but within your ability. It has to be a task that takes concentration and will take at least an hour to complete. You need to be relaxed and cannot have any distractions around you. It takes a good 15-20 minutes to get into a flow state.

For me flow is very pleasant but I don't get to experience it often, maybe once a month. It always feels very productive. I can be in a light flow state where I am still slightly aware of my surroundings, but on rare occasions I have experienced deep flow where I am aware of nothing but my internal monologue and the code. I daydream about being able to get into that mode sometimes.

Being able to enter that state isn't reliable even for people who do it often. I've never been able to do it at work, it happens somewhat often when I'm doing home projects if my environment is suitably quiet.

I've found that I experience a kind of embarrassed reluctance to fully commit all my attention to something while I'm at work surrounded by people, that prevents it for me.

Sad to hear. Every job I've had I've been able to get into that flow. But Ive also always had my own office or work from home. 20+ years of doing this professionally and as a hobby.

My advice is to find some way to take some pride in the work you do and or change employers when that flow stops happening. life is too short not to.

Our minds work very differently... if you're good at producing results and enjoy what you're doing keep doing it :)

Some of us do most work in stretches of "flow" that involves disconnecting our minds form the outside world and from the people around us. We "go deep" like in a state of trance for stretches of time. We probably work faster, but we also need more and longer breaks between these stretches of hyperintense work. Others like you (maybe most?) can work while aware of time and their surroundings. It's good that we're different, each approach has advantages and disadvantages, we all discover what works best for us individually... just respect the needs of the people around you, let them work however fits them best!

As a "flow-er", the most important skill I've learned is how to be productive even when I can't get into flow. As a non-flow-er, you should probably learn the opposite: find tasks and ways of working that can help you discover "flow"... even if you won't experience it very often, it's worth experiencing it!

I was going to type a more detailed response, but the people below have done an excellent job already. The body has to be balanced, distractions at a minimum, the mind open and curious and the problem "not too easy and not too hard". I like to think of it as "chasing the white rabbit". One thing that can help is to write a detailed plan of what your coding session is going to achieve, with some stretch goals. If you do it right you will enter a cycle of achieving small goals leading to refactoring and bigger goals and then you.... look up and the whole team has gone to get Tacos without you again.

For me there are two big contributors to flow (and flow may not be the same for everyone): requirements are very well understood and willingness to code the requirements.

If it's boring or boilerplate it doesn't work. Otherwise, some kind of flow normally happens. I believe you require some amount of concentration hence the need to not be interrupted, and it has to be a bit challenging to require concentration.

An example would be an interview or college exam: you are pressured and needed to stay focused, yet the time passed very quickly.

Many artists are also similar, who experience flow in creating.

But then there are many successful ones who follow a schedule and still create amazing body of work. For example - Roald Dahl. Based on the notes in his books, he was someone who followed a daily time schedule and he did alright.

So, do what works for you I guess.

I agree, I've heard of 'the flow' but it's never happened to me.

Perhaps related, perhaps not, I never 'sink in' to films I'm watching. My old GF seemed to be able to, but I'm always on the outside looking in, never immersed. I wonder if that's linked.

Some thoughts;

1. At some point in the 90s there was an "Extreme Programming" movement, or XP as it were. I distinctly remember the dogma built up around this, to the point where I started being forced to do pair programming in a formal sense, all day. Thankfully I just quit. I guess I prefer my coding to be less than extreme.

2. As others have mentioned, short term pair programming (never works >2 imo) is an excellent way of transferring knowledge (a model) to someone else, or to make progress on complex problems when you are stuck (the rubber duck effect is real).

3. I'm afraid I really must be getting old as I've never heard of "mob programming", and to be frank I've spent the last hours being horrified that such an idea exists. I guess in a way code reviews can be like that sometimes. lol.

In my experience pair programming works wonderfully for short, intense and complex problem solving scenarios. The extra pair of eyes and a second brain gnawing at a nasty problem is a good way to augment each other's capabilities.

In fact, I dare say that pair debugging is where the practice really shines. Doing it all the time, for all tasks? That won't fly.

I’ve only seen mob-programming to be adopted by teams of junior-slackers, but YMMV

Pair programming was never intended to be a full time mode of development. Half an hour once a week (or whenever) is good enough, and can help with mentoring junior developers. But it is really moronic to do that full time.