All good points and I was of the same opinion before I underwent almost 2 years of mostly pairing. My takeaways:
People are different. The core bunch came from Pivotal which performed pair-programming interviews so were self selected. That accounted for about half the engineering staff so the other half didn't undergo this process. I myself have always been a solo developer so pairing was very unnatural at first and I didn't pair well with everyone. We rotated pairs every week (sometimes two) so that wasn't a big problem.
There are times when solitary deep thought is useful and breaks for that activity could be taken at will while the other pair works on maintenance tasks etc. Most of the time the work isn't of this type and more often less complex requiring light whiteboarding or on-screen prototyping which both work well when pairing.
The style of code that comes out of pairing tends to be more plain than when working solo. There is incremental progress in both implementations and design refinements when pairing. When working solo there tends to be grander designs with a moment where it all comes together or not. I enjoy the latter but find the former higher by average throughput. Pairing tends to eliminate more of the 'might need soon' or 'will need in the future anyway' implementations.
After pairing with someone a few times, verbal communication becomes very terse and fluid. An unexpected benefit was the ability to immediately resume context after interruptions or breaks.
The biggest advantage of pair-programming that doesn't get mentioned much is the organic spread of good practices and conventions. With approximately 20 devs it's not really worth writing and maintaining standards documentation and conventions for handing new cases that keep appearing. With rotating pairs this discovery of what works well and normalization upon it is natural. Minor tips and tricks aside from the source code can also be invaluable power-ups when learned by others.
Pair programming isn't about maximizing 'your own productivity' it's about maximizing the productivity, quality, and consistency across all dev teams.
Within that period we also tried full-stack dev pairing. This was much more challenging and didn't work nearly as well. We didn't stick with it long enough to know if it could become more beneficial because basically people self-selected into front or back-end development and liked it that way.
These are my findings from being both a solo and pair-programming developer. If you're curious and have an opportunity I highly recommend trying to stick with it for a while and see what your findings are.
People are different. The core bunch came from Pivotal which performed pair-programming interviews so were self selected. That accounted for about half the engineering staff so the other half didn't undergo this process. I myself have always been a solo developer so pairing was very unnatural at first and I didn't pair well with everyone. We rotated pairs every week (sometimes two) so that wasn't a big problem.
There are times when solitary deep thought is useful and breaks for that activity could be taken at will while the other pair works on maintenance tasks etc. Most of the time the work isn't of this type and more often less complex requiring light whiteboarding or on-screen prototyping which both work well when pairing.
The style of code that comes out of pairing tends to be more plain than when working solo. There is incremental progress in both implementations and design refinements when pairing. When working solo there tends to be grander designs with a moment where it all comes together or not. I enjoy the latter but find the former higher by average throughput. Pairing tends to eliminate more of the 'might need soon' or 'will need in the future anyway' implementations.
After pairing with someone a few times, verbal communication becomes very terse and fluid. An unexpected benefit was the ability to immediately resume context after interruptions or breaks.
The biggest advantage of pair-programming that doesn't get mentioned much is the organic spread of good practices and conventions. With approximately 20 devs it's not really worth writing and maintaining standards documentation and conventions for handing new cases that keep appearing. With rotating pairs this discovery of what works well and normalization upon it is natural. Minor tips and tricks aside from the source code can also be invaluable power-ups when learned by others.
Pair programming isn't about maximizing 'your own productivity' it's about maximizing the productivity, quality, and consistency across all dev teams.
Within that period we also tried full-stack dev pairing. This was much more challenging and didn't work nearly as well. We didn't stick with it long enough to know if it could become more beneficial because basically people self-selected into front or back-end development and liked it that way.
These are my findings from being both a solo and pair-programming developer. If you're curious and have an opportunity I highly recommend trying to stick with it for a while and see what your findings are.