Pair Programming Economics

I've always wondered if the people who move into decision-making spots are extroverts, who then go on to make decisions affecting introverts, like open-plan seating.

Joking aside, pair programming (not as in occasional bout of problem-solving which needs a fresh eye, but as an everyday routine) only works when the problem is well-defined and people involved are of about same level of skill (otherwise it becomes a training session rather than production - which could be valuable but is definitely not the stated goal).

I am a highly skilled and experienced software engineer who did make notable contributions in a bunch of subfields - with awards and such. I noticed that most my peers (including those I consider at my level of skill) have a real trouble following my thought process - for example I tend to work in highly non-linear fashion, jumping all over the place, and in stop-and-go bursts. I could spend a month or two literally doing nothing, letting my mental model of what I'm building to settle and clarify. When the time comes the actual coding becomes nearly an exercise for fingers.

Another issue is depth of the abstraction stack - for most software people I met it's rather shallow. My personal notion of a "full stack engineer" is somebody who understands computers from how quantum effects make transistors work all the way up to the psychology of users, corporate finance, and macroeconomic trends - and everything in between. When you are aware of the fact that programming choices you make do not exist in a vacuum, and are dependent (or should be dependent, if you have a clue) on deep understanding of computing substrata, math behind it, the ways the product will be used, and the business objectives and environment - you would either need to force your choice on your pair peer (in which case there's no benefit of the "second opinion" as there's none) or to spend a lot of time and effort just giving him the background necessary to understand justification for your decisions. In my experience attempts to do so usually get dismissed as "that's philosophy", "it's irrelevant", or "we have work to do".

The stated advantage of PP - the better code quality - could be just as well achieved by a combination of disciplined thought, careful and elaborate execution, and actual learning from errors and mistakes - reflection on the ways I make mistakes is somewhat of an obsession for me; by now I usually know where I made a mistake even before I fire a debugger to confirm it (interestingly, I observed the same obsession in people who are engaged in seriously risky and technically complex endeavors like flying search-and-rescue missions or technical diving). (FWIW I'm of a very low opinion of merits of code reviews... wastes way more time on bikeshedding than saves on troubleshooting. Of all my decades writing code I may recall maybe a handful cases where it actually helped to find a bug which wouldn't be immediately apparent otherwise.)

I don't think I've heard this argument, and I haven't observed programmer behavior in the wild :)

I'm happy working solo 1 day a week or so, to do things maybe only I care about, or explore/learn things.

Pair programming certainly isn't for everyone, but don't knock it until you've done it for a few weeks, hopefully with some good pros!

I've never learned so much about programming as during my first ~6 months working together with people and learning their wisdom and tricks.

You're right that the restricted schedules are a downside.

* Really talented junior engineers blossom extremely quickly. They will easily be a multiple better after a year vs not pairing.

* Middle of the road junior engineers can be stunted and continually depend on the decisions / skill of the more senior pair. Pairing them more frequently with same level or lower helps. Sometimes this doesn't happen because this lower quality pair goes significantly slower and the result may need some code review/cleanup cycles, but it's a worthwhile investment.