I think that's the most important point you made. Pair programming is not for all programming, and in fact the goal is not to produce code. It's more about sharing thought processes with other people
I had a very positive experience with pair programming on a project for about ten months. We (myself and one other guy) definitely did serious work. We built and delivered a complex piece of well tested software that is now running on aeroplanes (non safety-critical software). It was also a distributed system, adding to the complexity, where some parts run on AWS and some on the planes, communicating over satellite internet (which may or may not be available).
We did it because we decided it would be the most effective way to work. There were only two of us on the project, so it was very important that both of us understood all aspects of the design and code. It was important to us that we spot issues early and that our test cases were comprehensive (we also used generative property-based testing to find actual bugs, which included simulating network errors, crashes etc).
We designed on a whiteboard, then we would pair to implement it. We worked remotely about 50% of the time (using ScreenHero to do remote pair programming. I miss ScreenHero). Yes, the goal was to share thought processes, but it was also to produce high quality code, spot errors, come up with edge cases and tests. And to document everything.
Personally, it was one of the most successful projects I ever worked on. The pair programming was exhausting, but very effective.
We do mob programming at my company, but do so 100% remote. We do it via zoom for screen share, and use https://mob.sh/ for handling the quick code handoff between drivers.
I agree, I've commented this exact things on the Copilot discussions: that the actual programming isn't the hard part.
Regardless, pairing helped us keep the code quality up and defects low, as well as making sure everything was properly tested and all corner cases were being dealt with. It of course also helped make sure we both understood every aspect of the code.
The goal in sole programming is also to produce code. The value-add of pair programming is usually knowledge transfer, rather than code produced. And it's not just knowledge about the code being written, but work practices too.
Not the way it's been sold to me. The goal is precisely to produce code, more effectively than two devs would individually, because a concurrent second pair of eyes avoids blind alleys and problems that would otherwise take a handoff to spot, and handoffs are efficiency tarpits. Knowledge transfer is an unavoidable beneficial side-effect, but it's not the point.
FWIW, although I only ever got to do very little pair programming (and it's long ago now), from all I heard about it (and the way it worked for us when we used it), I've got the same impression as regularfry and twic: It's at least as much about the actual code produced as any knowledge transfer.
Seems to me that it has suffered the same fate as so many other original "Agile" practices: The image of them nowadays is gravely distorted, sometimes to the extent of being a caricature, of what they originally meant.
I think that's the most important point you made. Pair programming is not for all programming, and in fact the goal is not to produce code. It's more about sharing thought processes with other people