When a student is ready, a teacher will appear. On an agile team, everyone can be a student and teacher. One team member may be more knowledgeable about the unit testing framework, but another may know more about object-oriented design. One team member may be more skilled with the IDE, and another knows the in-and-outs of the mocking framework.
Pair programming is an excellent time for these kinds of knowledge transfer. Code-reviews (particularly those conducted asynchronously over email) are a low-bandwidth medium for teaching and learning. It can happen, but teaching and learning has a lot more room to occur with in-person interactions.
The converse: "When a student is not ready, a teacher will not appear." also happens. People who reject pair programming without giving it a serious try are sometimes afraid to expose their fallibility. I didn't expect to enjoy pair programming, and when I first gave it a try, I was making typos and exposing my fallibility right from the start. And then the person I was pairing with was just as clumsy and fallible. As we continued to pair, we learned not only how fallible we are, but also how smart we are. We get to know we each as human beings. We find out that instead of being a waste of time, we make progress faster than we could if we were programming alone.
It takes courage to pair program. Do it for a while, and you'll find it also provides more safety than programming alone does.
