np. The "Stuff" that surrounds coding is very social (point 1), but the actual activity of writing code is very inward focused and ideally uninterrupted. The idea of FLOW is a very real thing, its very zen: hours just fade away until you look up and everyone has gone to lunch. I'm tilting at the open office windmill and idea that whilst I'm actually coding, I need to interact with others.

Being a "Developer" (planning, designing) is very social, however writing the actual code, for me at least, is a very inward activity and suits my quiet personality. The problem here is that non-coders don't understand this and it can cause a lot of friction when working in the usual group office environment.

It's a catch 22, people want me to code for them, but then they have a problem with me socially when I'm trying to code ;)

This is off-topic, but I have never experienced the "flow" you mention but I've had a decent career so far. I'm not the best or anything but I've done well in terms of promotions or projects shipped.

I've never lost track of time coding like you say - I stop at 12:30pm for lunch and then at 5:00pm to go home. I've always wondered if I am doing something wrong or maybe I just like programming enough as a job.

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.

I get it reasonably often when I'm coding my projects late at night, when there's nobody there to bother me. The downside is that it messes with my sleep, since I'll start at midnight, write some code, think "okay I need to go to bed by 1 because I haven't been sleeping well" and I look and it's 5 am.

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.

I’m the person you replied to - I’m a big film fan but I have the same “issue”. The only time I can get immersed is at a movie theater and even then it’s rare (last time I was immersed it was with Parasite). But again, I enjoy the film and am able to remember all of it so not sure if it’s a problem.

I'd not intended to suggest it was a problem, only that it was perhaps related to the inability to get into the flow. Merely an observation.

Parasite the korean film?

What do you think of pair programming and the more extreme nature of it called mob programming. Have you seen either of those two things work well in any context?

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.

Yeah but just about nowhere did XP properly, though many places claimed to in the late 90s, early 00s whenever it was the extreme hotness. It was one of those peculiar cults everyone talked up, but just about no one understood or had even read the book.

One place I was at did everything, including onsite customer etc. In context pair programming managed to stay enjoyable for the entire time and they didn't seem to have high turnover. It actually kept on feeling more productive. I was there around a year (contract). I never encountered it again so can't comment if that was sheer luck or the people (or project) they happened to have...

There was a spell when every job ad seemed to want to claim it, but basically picked pair programming and two to five of the bullets and handwaved or ignored the rest. Or merged it with plenty of old school waterfall project management, Gantt charts, random bits of UML or some other tangent. I guess I'm not surprised so many ended up hating everything around XP and pair programming as it took many forms. It made for a few surreal interviews after that one encounter of an employer who'd adopted it fully and properly.

Any practice which almost no one gets it right, may be there is something inherently wrong about the practice that so many smart people are failing to implement it right.

I've done non-forced pair programming for suitable tasks that were really math heavy in a controll algorithm where I essentially double checked the math. Worked that time really well but always doing it would make me hate my job.

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.

"intended"? By who? Based on what?

I worked at companies that had full time pairing and it worked well.

When you tried full time pairing, what were the issues you observed that made you conclude it was "moronic"

.. by the people who started it and popularized it. I have never tried it full time because it's obviously patently moronic to do it that way, and would destroy all enjoyment of the job. I have worked with highly talented developers and can not recall any one of them wanting to pair full time. I have received huge benefits from occasional pair programming with senior developers in my less senior days. However, I need to try full time pair programming as much as I need to try jumping into a fire to verify that it's not a smart idea. If my employer forced me to do that I would quit on the spot.

Pair programming works if used as a mentorship. You’ll need to have a senior dev and a less experienced one.

But I guess this is but the original intent of pair programming

I agree with that and can also relate to this point (as I experience exactly this in my current project) my colleague already complained about being interrupted many times already. The problem is that the non coding colleagues want to ask just a 'quick question'.

Thanks for the quick reply.