I think pair programming requires some 'investment' at the team level. For example, the work environment (think desk arrangements) need to be set up to make pairing natural.
It's helpful if pair programming is the default mode (i.e. a dev will only go solo when there's a consensus that pairing would be counter-productive).
If you pair-off at the morning standup, so that ongoing tasks retain one dev from yesterday and gain one fresh dev, then after a couple of weeks everyone on the team can cover for anyone else, and everyone has a birds-eye view of the whole system. This was a revelation to me; prior to my encounters with pairing, I'd never worked on a team where anyone had a good overview of the whole system, including the leader. Morning standups help, but pairing-with-rotation does a much better job of knowledge-distribution.
Re. Sociability: I've paired with some very nerdy, shy people. It generally worked out well; most nerds are just fine when they are explaining what they are currently nerding about.
I've paired with people who were much brighter and more knowledgeable than me, and the other way round. Either way, it worked out fine (as long as you don't develop a Master-Apprentice syndrome).
Pairing involves quite a lot more mental effort than solo coding. I was always dog-tired after a day of pairing. Keeping track of what your pair is up to (or making sure your pair is keeping up) requires attention. And IME breaks are generally shorter.
I only had a problem when I had to pair with someone quite far along the aspie continuum; he was bright, but he was completely unable to explain what he was doing, and his code was far from self-explanatory. If you see coding as a way of communicating with programmers, rather than with machines, strongly aspie types become a workplace hazard.
I've never worked at an org or on a team with an explicit 'we do pair programming', but in general if someone wants to explicitly start watching while ai walk through something, or have me watch whilethey show me something and we figure something out together, that's fine.
I will fumble the keys and be much slower if I'm the one being watched, but I'm fine with that because I know they're there and they asked.
I'd still be bothered by others walking past behind us while the person who came over to 'pair program' (if I can call what we're doing that) watches and doesn't bother me.
I don't. I could never really pair programming, even in school.
Interestingly, I can share my screen with people that have different tasks than mine. I just can't make it work when both people have the same state of mind.
pair programming is really a forced socializing in a field where a lot of people have trouble socializing, never really understood how it got as far as it did.
Pair programming is an anti-procrastination trick that works by setting two people in a situation where both are afraid to lose face by trying to goof off. This works, but builds up anxiety.
Pair programming seems to be social in some ways, but I could imagine two programmers with very little social awareness or self-consciousness being able to find a cadence for pair-programming.
Depends on the definition of pair programming imo.
Bad definition (the one I encountered in school): two people of about the same skill level sitting at one computer and programming together. I hated it, akin to my hate of backseat drivers.
Good definition (the one I encountered at my workplace): as a junior engineer, I was tasked with implementing this tricky caching thing in one of our systems that I had zero previous experience with. One of our senior engineers was tasked with helping me with that. I would implement as much as I could myself, and when I get stuck, the senior would either give me hints on how to get unstuck or program some parts himself while explaining to me how and why he did things a certain way. This helped me out tremendously in my skill development and got me running confidently in our codebase really quickly.
Interaction between devs is unavoidable, at the code review stage if not sooner. Pair programming provides tighter feedback loops and helps get things done quicker than playing CR tennis after a lot of hours have been sunk into something.
