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.
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.