I do not recommend doing pair programming as a way to handle long periods of isolated work. If you can not work alone without supervision you have to deal with those psychological issues first or just change your job.
Your boss is not going to pay two salaries for doing the work of one. If you do pair programming, it will be because you can be more productive that way that working alone, and that is not the case most of the time (although most people want to believe that).
As entrepreneur and engineer and programmer for a long time when I hear "pair programming", a big light bulb appears in my head screaming and blinking SCAM!. It can be done sometimes with specific people at specific times for specific reasons but I do not believe that it works for most people.
There are more reasons to do pair programming:
It also transfers knowledge of all kind (domain, tools, techniques), saves the time for code review, strengthens relationships and improves team culture
In 1999, a controlled experiment run by the
second author at the University of Utah
investigated the economics of pair programming.
Advanced undergraduates in a Software
Engineering course participated in the
experiment. One third of the class coded class
projects as they had for years – by themselves.
The rest of the class completed their projects with
a collaborative partner. The results of how much
time the students spent on the assignments are
shown below in Figure 1. After the initial
adjustment period in the first program (the
“jelling” assignment), together the pairs only
spent about 15% more time on the program than
the individuals [4]. Development costs certainly
do not double with pair programming!
Significantly, the resulting code has about 15%
fewer defects [4]. (These results are statistically
significant.) Figure 2 shows the postdevelopment
test cases the students passed for
each program – essentially the percentage of the
instructor’s test cases passed.
The initial 15% increase in code development
expense is recovered in the reduction in defects,
as the following example illustrates...
So the from this paper is the initial work is more costly, anyone that tells you it is not is probably wrong, but not double. But they are producing different work at a different quality level, at a different speed.
Sure there could be problems with the methodology, it might apply to students and not professionals (a classic psyche 101 bias). But it is something, certainly not a scam.
Students can’t be compared to industry workers.
In my 20+ years of professional career in a multitude of companies of various sizes and domains, I have never seen pair programming implemented as a regular working method.
Nothing that even gets close to this.
I agree, students and industry workers are not directly comparable. But one of the issues that I would wager is somewhat comparable is the human factors which, in the study above showed large inefficiencies in the first assignments before the "jelling" of the pair.
This makes most one shot studies problematic, it also makes starting to pair problematic if you are experimenting.
I have never worked in a full time pairing place, it was experimental, here there, sometimes. But the initial inefficiencies rung true to me, along with this jelling.
With all the money spent on software development, I am a bit surprised there are not numerous double blind experiments and studies where two different consultancies are assigned the exact same very complex project with staffed professionals using different processes. It would be extremely costly, but could pay the industry back many-fold.
In a pair programming setup what the pair does when collaboration isn’t needed but just pure coding? Do they separate and code in parallel or how does it go?
You hit on a key concept that we have no way to even measure productivity. We have no units of measure. What is a feature, they are rarely even comparable in any meaningful way. It's possible to have two projects that start the same but rapidly drift apart.
Not only that but different tools have different depreciation rates. I'd much rather try to restart an abandoned Java or C# project vs an abandoned PHP project, even though the PHP project might have been faster to add features at the start.
Because we have no measurements, we have no science.
You can make user metrics/surveys/delivery dates the ultimate adjudicator, in a blind way if you have created complete products. They will diverge significantly!
A method can be effective and practical even if you've never seen it used.
My anecdata: I have worked at four different companies over fifteen years that all had pairing as a regular practice. Those teams had fewer defects, higher "social trust", zero silo areas, no cowboys, and rapidly trained Jr engineers into Sr engineers. They were much more aggressive at paying down technical debt.
I would estimate that pairing at least half of every day can produce Sr engineers 3x faster than just giving a new hire tickets and doing code review on a PR.
Also on a team with strong pairing culture, people often feel safe to "go home" in ways that I don't see in regular teams. Knowing that anyone on the team can handle any ticket you can feels quite liberating.
Obviously most engineers hate it though. It's less comfortable. Everyone I've seen who gets good at pairing comments that they are working a lot harder and getting a lot more done than solo. This is hard if you like to spend most of the day puttering around.
It's also not as great for deep thinking, so in teams with regular pairing culture it's a good idea to have forced solo time without assigned work just to make sure everyone gets that time to read, think, and process.
Of the four teams, one of them definitely was slower pairing, because they actually used mob pairing with 6 people on a zoom call and only the Sr guy typed. That was extremely ineffective but they didn't want to change because the other 5 loved just playing video games all day on a call. That team also was in meetings 6 hours a day, so they only paired like 90 minutes most days. That team had a lot of issues.
In my experience if you build a healthy pairing culture, it's the most effective way to build a highly trained stable team.
Not gonna say it's a scam, but it's quite a stretch to call this science. Your paper only has this snippet about this experiment at the University of Utah. The actual paper about that experiment is here: https://collaboration.csc.ncsu.edu/laurie/Papers/ieeeSoftwar.... It's not a real paper. It's a non peer-reviewed submission of a few pages with no formal methods section and no statistical analysis, its title makes clear it is explicitly being submitted as a work of advocacy, and two of the authors are consultants owning private practices selling programming methodology solutions to businesses.
Given they don't have a real methods section, I guess we'll never know, but the vague description of how they did seems to imply they split the class into people who completed assignments alone and people who completed them in groups of two. This does not seem to meet any definition of "pair programming" I would consider familiar to me. It sounds like a self-organizing team of two. How they split up work is not explained, but there is nothing here to indicate it was two people working at the same time with one typing and one watching for every line of code, just that two people were responsible for the same assignment as one person in the control group.
And you can see with further googling, the results of better sources are all over the place. I did not cherry pick that one, it was just a sort of lazy google, look for a top result that was not clearly a blog.
I am just kind of frustrated at the seemingly poor science in the industry.
But as I posted elsewhere, the "jelling" process rung true. Which complicates all kinds of one shot experiments.
Personal productivity is second to team productivity. Pair programming facilitates discussion, context sharing and alignment. The biggest problems are almost always misalignment and lack of context/shared understanding, not productivity of individual team members.
Pair programming is, first and foremost, a technique for implementing continuous review. The old adage: If code reviews are good, do them constantly and continuously. We pair/mob when appropriate, and we don't do pull requests. If you pair AND do pull requests, it may be worth examining that.
The secondary order effects cannot be ignored either. On our team, pairing is used to:
- Coach more junior developers into being more proficient at their work
- Share knowledge so that norms, standards, and other knowledge can propagate through the team in a more natural (and effective) way than documentation
- Share techniques at the more tactical level
- Further explore the solution space and do better planning and execution (go slow to go fast)
The biggest downside to pair programming is that unless you are a strong communicator and feel like investing the energy, great ideas get averaged down to well.. Average.
It doesn't have to be the case, but because of averages it typically is.
If I understand what you are saying correctly, you are saying that if two people are pairing and the one with the better idea does not successfully communicate their idea, either from lack of trying or lack of effectiveness, then the person with the lesser idea might "win" and that is what would be implemented?
If so, I would say that the appropriate response to that is to, as a team, work to improve communication and collaboration consistently -- every day, in every work item. Leadership should reinforce the import, exemplify it, and observe and coach.
In general, what it sounds like you are saying is that people who are bad at things do things poorly. Yes, that's true, but that's why we have all the tools we have available to us to help them do things better. We don't have to like in squalor, we can choose to help each other rise above it.
As an entrepreneur and engineer and programmer having spent 30 years in software without washing out and still accelerating, I'm shocked every time I encounter the well-conditioned presumption that work cells in knowledge work should be decomposed to the single point of absolute irreducibility, which is inevitably the 1-person/1-work-item presumption. It implies the assertion that parallelization _should_ be maximized to the ultimate, which implies that the nature of the work is largely just implementation details and typing out code on a keyboard. But that's not where delays and inefficiencies are in software. And decomposing work cells to the point of total parallelization only exacerbates the factors that do indeed worsen the delays and inefficiencies.
Software development has been so underperforming for so long that we presume that the natural, unavoidable state of software development is what the average team experiences today. That's only true of average teams with average productivity and average per-person yield. It's true in the middle of the productivity/performance bell curve, but not to the right of it.
The 1-person/1-work-item division of labor sub-optimizes the momentum transfer that high-performance teams harness to get the high-performance results that they're after. Doing so is predicated on a number of factors, but principally it requires a vigorous attention to structural design fundamentals, rigorous norms, the ease of provability of changes and additions made to the design and implementation, and a solid grasp of organizational mechanics and process mechanics with a fluency in the effects of batching and queueing in systems-of-work in knowledge work and product development.
In my work, and in the work in our organization, the 1-person/1-work-item system is the exception and collective work is the norm. That's because of breakthrough levels of productivity that can be unlocked at the upper echelons of quality. In fact, at that level, the terms "productivity" and "quality" don't have any meaningful difference.
In the middle of the software development curve, there is already such middling productivity/quality that any particular strategy is unlikely to have much observable effect at all on outcomes. It's not until quality is increased to a point well over the present average that the effects of the numerous individual virtuous systems amplifying each other in the overall production system that the sub-optimization of the 1-person/1-work-item division of labor is obvious.
At that level, management of software development operates like an accounting system that only records gains and disregards losses from the final bottom line. Every iota of spent effort is counted as a gain without regard for whether the result of the work creates loss-free assets or not.
The field of software development has largely lost track of structural design fundamentals, both in the software itself and the design of the processes and procedures wherein the software is built. The vast majority of software developers operating today don't know what a mistake is in software development. They don't even recognize the design mistakes inherent in the tools they choose, and they tend to live in software ghettos where productivity poverty is the norm. They've got good slum survival street smarts, but have never been outside of the slum, so they couldn't orient themselves toward a healthier approach and healthier work life if they wanted to. They don't recognize the mistakes that are painfully obvious when seen through the lens of design fundamentals, so they don't know what to avoid. Software developers at large don't know where the "true north" heading is.
To me, it's this current state of ghettoized software development that's the scam. It's the productivity balance sheet that fails to recognize losses and setbacks and that books "technical debt" as an asset t...
I believe that thinking your solo work is good enough is hubris. I'm not a fan of pair programming either, but I don't trust my own work enough to not have someone else review it first.
I guess different stuff works for different people.
The pomodoro thing is inhuman in my opinion, too mechanical and the process itself is distracting the mind from the actual work that it should work on.
I found the combination of flow+off keyboard thinking time to be my preferred natural flow of work.
Usually I dive in and work in a flow for as long as I can, which usually is around an hour and up to a few hours in some cases.
Then I naturally take a break.
Then get back again.
But in cases when I stop because I need to think rather than think-and-type, the break becomes longer, as necessary.
I use mini-pomodoro to build momentum when I can’t get started.
Start with 2-3 minutes “work”, 1 minute break. Keep bumping those up toward 25/5.
Usually by the time I’ve done a few rounds, I don’t want a break and I’ve got my momentum, and I ditch the cycles and just work.
This works surprisingly well for me even at a micro level, like exercise 10 seconds, break for 5 seconds, repeat. Before I know it I’m just exercising uninterrupted for 20 minutes.
I left out one part: clap for yourself
The process is more like:
* Pick something
* Do it
* Clap for yourself
* Repeat
And the key is to make “do it” as small as necessary to keep the cycle going, then expand it once the human reward system takes over.
Absolutely this. When I was building up a soldering habit (have a backlog of analog synth modules to make) I made a point of soldering 1 component. But then by the time the iron heated up, I've decided what goes into the board next, and soldered that one component, I might as well do 5 or 10.
> By definition, a flow state is non-collaborative; [...] you’re certainly not going to be in that mindset while you’re in a pair programming session.
This is not true. Group flow is a well documented phenomenom[0]. While it's easiest to recognize for example in an orchestra, group flow can happen with pair programming as well.
I do wonder if group flow and individual flow have more to do with different skill sets, and which path best suits the people you have, as opposed to the idea that group or individual flow is more effective.
Like, I like to whiteboard and mock up a problem in Python to wrap my brain around it. My coworker likes to mock things up in Excel. Usually when we work together, I find myself just waiting to get off the call so I can do my own whiteboarding. What makes sense to him in his Excel file doesn’t hit as much for me.
Whereas it seems like group flow uses some kind of higher level coordination process, whether it’s whatever orchestra “best practices” have been established over centuries, or people chanting together in temples, or whatever.
The question being, while group flow exists, is it simply that it requires people who like engaging in the “group flow activities”? Like we can probably find people who coincidentally like chanting, and those people might make good monks. But will my coworker and I ever work well in a pair programming environment?
I've played in a large band, with over fifty members. I did that for several years. The thing that kept us together was the conductor, not some sort of "group flow".
This is not to say that "group flow" doesn't exist, but I'd want more extraordinary evidence for this claim.
I think the title suggests larger questions. What is Flow? How many different kinds of flow states are there? To what extent are they equal?
I recently listened to "Your Brain: Who's in Control?" [1], a PBS documentary that looked at a musician in an MRI rapping a memorized piece vs an ad-hoc rap. They found the musician's prefrontal cortex was inhibited when doing the ad-hoc exercise. The prefrontal cortex is used as a "filter" center, to predict and evaluate the potential outcome of actions and basically to tell you when something is a bad idea.
When developers are in flow, and they are creating brand new code - do their prefrontal cortex'es also become inhibited? Is that the same kind of flow state?
I believe there are multiple types of flow state:
- gardening/choirs, time drops away and you lose yourself in the trimming, edging and mundane gardening tasks
- gaming, when I was younger and after an approx 16 hour binge of Civilization, my mind was still in the game. I was asleep and was still thinking in-game, solving problems, and wondering "where is the end turn button." Being in that level of flow state, the thoughts of 'end turn', 'move unit' - just occurred, my mind's connection to the game through my body was erased, the motor movements to click, hotkeys, all gone from conscious thought and just automatic.
- music: Type (A) - playing a well known piece, it just happens. Type (B) Improv, jazz musicians do this all the time for hours on end.
- biking/exercise: after a few hours, a sense of time can stop and everything becomes automatic.
- driving: actions to signal, brake, accelerate require no thought; your mind says "speed up" and the body's reaction is automatic and requires virtually no thought. The interface between you and the car disappears, you no longer think "press my foot down" - you only think "accelerate"
- reading: a best example of this I recall was being younger and reading Lords of the Rings. Hours melted away, I experienced complete immersion in the story.
- math homework: I recall calculus homework sessions that took 3-4 hours, and did not feel nearly as long. After a while would just get lost in the problems and lose time.
I think all of these are flow states. I don't think they are all exactly the same. Which is all to say, I suspect there is a lot more to 'flow' state than we think, there are likely multiple facets which are different on their own. Further, individual variation could have a significant impact. Would someone who is ADHD experience the same flow states in the same ways?
Another aspect, common & routine actions get "burned into" our neural circuitry. A persons morning routine is an example, the actions for 'burned-in' things no longer require much if any thought at all to do. You stop thinking "what's next" and just instead follow a routine and pattern that needs no decision making. It takes time and repetition to achieve this. This burn-in I feel is likely super related to 'flow'.
For neural burn-in, I wonder if it's like a thru-hiker. EG: Routine aspects like foot placement and moving the trekking poles become burned in - leaving more space in the conscious for other activities. Yet, I know that things like "watching out for Bears" is not in the conscious space, but very active! I recall some times of seeing Bears almost immediately without realizing I was scanning for them so much. Very much like a high importance CPU interrupt firing, but one that I would have thought would have been a more active process rather than a background process.
All in all, a super interesting area ripe for a lot more research. Our current understanding of flow feels like we now just past the "peak of 'mount stupid' (AKA Child's Hill)" [2] in the dunning-kruger effect, and just realized that we know very little about flow at all.
I have a lightweight way to use the pomodoro technique: I just start a pomodoro at x:00 or x:30 on the clock, and take a break at x:25 or x:55. This lets me work through a pomodoro when I'm super concentrated and doesn't introduce a distracting app or alarm.
It's based on this blog post[^0], which I can highly recommend in general.
33 comments
[ 2.2 ms ] story [ 73.0 ms ] threadYour boss is not going to pay two salaries for doing the work of one. If you do pair programming, it will be because you can be more productive that way that working alone, and that is not the case most of the time (although most people want to believe that).
As entrepreneur and engineer and programmer for a long time when I hear "pair programming", a big light bulb appears in my head screaming and blinking SCAM!. It can be done sometimes with specific people at specific times for specific reasons but I do not believe that it works for most people.
Unfortunately a whole lot of people are totally against that idea so i make do with chatgpt/copilot as my pair programmer these days.
One Lazy google search searching for a paper, and not a blog:
https://collaboration.csc.ncsu.edu/laurie/Papers/XPSardinia....
So the from this paper is the initial work is more costly, anyone that tells you it is not is probably wrong, but not double. But they are producing different work at a different quality level, at a different speed.Sure there could be problems with the methodology, it might apply to students and not professionals (a classic psyche 101 bias). But it is something, certainly not a scam.
This makes most one shot studies problematic, it also makes starting to pair problematic if you are experimenting.
I have never worked in a full time pairing place, it was experimental, here there, sometimes. But the initial inefficiencies rung true to me, along with this jelling.
But, I have visited a place that did implement full time all the time pairing. (https://menloinnovations.com/our-way/our-process)
With all the money spent on software development, I am a bit surprised there are not numerous double blind experiments and studies where two different consultancies are assigned the exact same very complex project with staffed professionals using different processes. It would be extremely costly, but could pay the industry back many-fold.
Not only that but different tools have different depreciation rates. I'd much rather try to restart an abandoned Java or C# project vs an abandoned PHP project, even though the PHP project might have been faster to add features at the start.
Because we have no measurements, we have no science.
My anecdata: I have worked at four different companies over fifteen years that all had pairing as a regular practice. Those teams had fewer defects, higher "social trust", zero silo areas, no cowboys, and rapidly trained Jr engineers into Sr engineers. They were much more aggressive at paying down technical debt.
I would estimate that pairing at least half of every day can produce Sr engineers 3x faster than just giving a new hire tickets and doing code review on a PR.
Also on a team with strong pairing culture, people often feel safe to "go home" in ways that I don't see in regular teams. Knowing that anyone on the team can handle any ticket you can feels quite liberating.
Obviously most engineers hate it though. It's less comfortable. Everyone I've seen who gets good at pairing comments that they are working a lot harder and getting a lot more done than solo. This is hard if you like to spend most of the day puttering around.
It's also not as great for deep thinking, so in teams with regular pairing culture it's a good idea to have forced solo time without assigned work just to make sure everyone gets that time to read, think, and process.
Of the four teams, one of them definitely was slower pairing, because they actually used mob pairing with 6 people on a zoom call and only the Sr guy typed. That was extremely ineffective but they didn't want to change because the other 5 loved just playing video games all day on a call. That team also was in meetings 6 hours a day, so they only paired like 90 minutes most days. That team had a lot of issues.
In my experience if you build a healthy pairing culture, it's the most effective way to build a highly trained stable team.
Given they don't have a real methods section, I guess we'll never know, but the vague description of how they did seems to imply they split the class into people who completed assignments alone and people who completed them in groups of two. This does not seem to meet any definition of "pair programming" I would consider familiar to me. It sounds like a self-organizing team of two. How they split up work is not explained, but there is nothing here to indicate it was two people working at the same time with one typing and one watching for every line of code, just that two people were responsible for the same assignment as one person in the control group.
And you can see with further googling, the results of better sources are all over the place. I did not cherry pick that one, it was just a sort of lazy google, look for a top result that was not clearly a blog.
I am just kind of frustrated at the seemingly poor science in the industry. But as I posted elsewhere, the "jelling" process rung true. Which complicates all kinds of one shot experiments.
The secondary order effects cannot be ignored either. On our team, pairing is used to:
- Coach more junior developers into being more proficient at their work
- Share knowledge so that norms, standards, and other knowledge can propagate through the team in a more natural (and effective) way than documentation
- Share techniques at the more tactical level
- Further explore the solution space and do better planning and execution (go slow to go fast)
And others.
It doesn't have to be the case, but because of averages it typically is.
If so, I would say that the appropriate response to that is to, as a team, work to improve communication and collaboration consistently -- every day, in every work item. Leadership should reinforce the import, exemplify it, and observe and coach.
In general, what it sounds like you are saying is that people who are bad at things do things poorly. Yes, that's true, but that's why we have all the tools we have available to us to help them do things better. We don't have to like in squalor, we can choose to help each other rise above it.
Software development has been so underperforming for so long that we presume that the natural, unavoidable state of software development is what the average team experiences today. That's only true of average teams with average productivity and average per-person yield. It's true in the middle of the productivity/performance bell curve, but not to the right of it.
The 1-person/1-work-item division of labor sub-optimizes the momentum transfer that high-performance teams harness to get the high-performance results that they're after. Doing so is predicated on a number of factors, but principally it requires a vigorous attention to structural design fundamentals, rigorous norms, the ease of provability of changes and additions made to the design and implementation, and a solid grasp of organizational mechanics and process mechanics with a fluency in the effects of batching and queueing in systems-of-work in knowledge work and product development.
In my work, and in the work in our organization, the 1-person/1-work-item system is the exception and collective work is the norm. That's because of breakthrough levels of productivity that can be unlocked at the upper echelons of quality. In fact, at that level, the terms "productivity" and "quality" don't have any meaningful difference.
In the middle of the software development curve, there is already such middling productivity/quality that any particular strategy is unlikely to have much observable effect at all on outcomes. It's not until quality is increased to a point well over the present average that the effects of the numerous individual virtuous systems amplifying each other in the overall production system that the sub-optimization of the 1-person/1-work-item division of labor is obvious.
At that level, management of software development operates like an accounting system that only records gains and disregards losses from the final bottom line. Every iota of spent effort is counted as a gain without regard for whether the result of the work creates loss-free assets or not.
The field of software development has largely lost track of structural design fundamentals, both in the software itself and the design of the processes and procedures wherein the software is built. The vast majority of software developers operating today don't know what a mistake is in software development. They don't even recognize the design mistakes inherent in the tools they choose, and they tend to live in software ghettos where productivity poverty is the norm. They've got good slum survival street smarts, but have never been outside of the slum, so they couldn't orient themselves toward a healthier approach and healthier work life if they wanted to. They don't recognize the mistakes that are painfully obvious when seen through the lens of design fundamentals, so they don't know what to avoid. Software developers at large don't know where the "true north" heading is.
To me, it's this current state of ghettoized software development that's the scam. It's the productivity balance sheet that fails to recognize losses and setbacks and that books "technical debt" as an asset t...
I believe that thinking your solo work is good enough is hubris. I'm not a fan of pair programming either, but I don't trust my own work enough to not have someone else review it first.
Start with 2-3 minutes “work”, 1 minute break. Keep bumping those up toward 25/5.
Usually by the time I’ve done a few rounds, I don’t want a break and I’ve got my momentum, and I ditch the cycles and just work.
This works surprisingly well for me even at a micro level, like exercise 10 seconds, break for 5 seconds, repeat. Before I know it I’m just exercising uninterrupted for 20 minutes.
I left out one part: clap for yourself
The process is more like:
* Pick something
* Do it
* Clap for yourself
* Repeat
And the key is to make “do it” as small as necessary to keep the cycle going, then expand it once the human reward system takes over.
This is not true. Group flow is a well documented phenomenom[0]. While it's easiest to recognize for example in an orchestra, group flow can happen with pair programming as well.
[0] https://www.aalto.fi/en/oasis-of-radical-wellbeing/group-flo...
Like, I like to whiteboard and mock up a problem in Python to wrap my brain around it. My coworker likes to mock things up in Excel. Usually when we work together, I find myself just waiting to get off the call so I can do my own whiteboarding. What makes sense to him in his Excel file doesn’t hit as much for me.
Whereas it seems like group flow uses some kind of higher level coordination process, whether it’s whatever orchestra “best practices” have been established over centuries, or people chanting together in temples, or whatever.
The question being, while group flow exists, is it simply that it requires people who like engaging in the “group flow activities”? Like we can probably find people who coincidentally like chanting, and those people might make good monks. But will my coworker and I ever work well in a pair programming environment?
This is not to say that "group flow" doesn't exist, but I'd want more extraordinary evidence for this claim.
I recently listened to "Your Brain: Who's in Control?" [1], a PBS documentary that looked at a musician in an MRI rapping a memorized piece vs an ad-hoc rap. They found the musician's prefrontal cortex was inhibited when doing the ad-hoc exercise. The prefrontal cortex is used as a "filter" center, to predict and evaluate the potential outcome of actions and basically to tell you when something is a bad idea.
When developers are in flow, and they are creating brand new code - do their prefrontal cortex'es also become inhibited? Is that the same kind of flow state?
I believe there are multiple types of flow state:
- gardening/choirs, time drops away and you lose yourself in the trimming, edging and mundane gardening tasks
- gaming, when I was younger and after an approx 16 hour binge of Civilization, my mind was still in the game. I was asleep and was still thinking in-game, solving problems, and wondering "where is the end turn button." Being in that level of flow state, the thoughts of 'end turn', 'move unit' - just occurred, my mind's connection to the game through my body was erased, the motor movements to click, hotkeys, all gone from conscious thought and just automatic.
- music: Type (A) - playing a well known piece, it just happens. Type (B) Improv, jazz musicians do this all the time for hours on end.
- biking/exercise: after a few hours, a sense of time can stop and everything becomes automatic.
- driving: actions to signal, brake, accelerate require no thought; your mind says "speed up" and the body's reaction is automatic and requires virtually no thought. The interface between you and the car disappears, you no longer think "press my foot down" - you only think "accelerate"
- reading: a best example of this I recall was being younger and reading Lords of the Rings. Hours melted away, I experienced complete immersion in the story.
- math homework: I recall calculus homework sessions that took 3-4 hours, and did not feel nearly as long. After a while would just get lost in the problems and lose time.
I think all of these are flow states. I don't think they are all exactly the same. Which is all to say, I suspect there is a lot more to 'flow' state than we think, there are likely multiple facets which are different on their own. Further, individual variation could have a significant impact. Would someone who is ADHD experience the same flow states in the same ways?
Another aspect, common & routine actions get "burned into" our neural circuitry. A persons morning routine is an example, the actions for 'burned-in' things no longer require much if any thought at all to do. You stop thinking "what's next" and just instead follow a routine and pattern that needs no decision making. It takes time and repetition to achieve this. This burn-in I feel is likely super related to 'flow'.
For neural burn-in, I wonder if it's like a thru-hiker. EG: Routine aspects like foot placement and moving the trekking poles become burned in - leaving more space in the conscious for other activities. Yet, I know that things like "watching out for Bears" is not in the conscious space, but very active! I recall some times of seeing Bears almost immediately without realizing I was scanning for them so much. Very much like a high importance CPU interrupt firing, but one that I would have thought would have been a more active process rather than a background process.
All in all, a super interesting area ripe for a lot more research. Our current understanding of flow feels like we now just past the "peak of 'mount stupid' (AKA Child's Hill)" [2] in the dunning-kruger effect, and just realized that we know very little about flow at all.
[1] BasilPH ↗ I have a lightweight way to use the pomodoro technique: I just start a pomodoro at x:00 or x:30 on the clock, and take a break at x:25 or x:55. This lets me work through a pomodoro when I'm super concentrated and doesn't introduce a distracting app or alarm.
It's based on this blog post[^0], which I can highly recommend in general.
[^0]: https://guzey.com/productivity/#how-i-work-and-rest-how-my-s...