>> slower than having everyone work on their own problems

That’s fascinating, i recognise every bit of everything else you said but in my experience this was the golden redeeming quality - velocity of correct code is massively (maybe 4x) sped up.

Maybe the difference is overall - pairing becomes too tiring so you might be extremely productive but the short periods of it mean that the slow and steady solo approach wins out because you can do it for longer.

Pair programming if done on task such as "let's make this completely standard thing we've done five times already and need a slight variation of" is horrible. When working with new developers, if they're senior or junior, is great though. It doesn't have to be full days but a few hours a day of pair programming brings someone up to speed incredibly quickly.

When there's hard problems to track down, I think all developers go to pair debugging. If not only for the rubber duck effect.

Ha, humorously, I like pair debugging even less than pair programming. I need to think deeply when debugging a thorny issue, and I can't do that while interspersing communication.