I don't want to constantly be explaining why I'm doing something, it just seems tiring.
This is my biggest objection to pairing. Usually when I'm first working on something new I don't really understand the problem so I'll slap together a very quick & dirty solution and then either refine it from there or toss it and start over. Being forced to slow down and verbalize my thought process at this stage just slows the process way down and makes me less willing to experiment.
Good code reviews seem to me to provide most of the upside of pair programming with none of the downside.
>Good code reviews seem to me to provide most of the upside of pair programming with none of the downside.
Your suspicions are accurate. I can't find it right now, but I remember reading a thorough study on software and the bugs eliminated by various processes. It was code reviews (multiple variations of them, in fact) that stood head and shoulders above the rest in preventing bugs from reaching production.
This is my biggest objection to pairing. Usually when I'm first working on something new I don't really understand the problem so I'll slap together a very quick & dirty solution and then either refine it from there or toss it and start over. Being forced to slow down and verbalize my thought process at this stage just slows the process way down and makes me less willing to experiment.
Good code reviews seem to me to provide most of the upside of pair programming with none of the downside.