Pair programming—the practice of two developers working as a pair, with one at the keyboard and the other looking over the first developer's shoulder—is a key discipline of Extreme Programming. While many developers agree that there is value in having two pairs of eyes looking at every line of code as that code is being written, relatively few practice pair programming.

In a recent blog post, Pair Programming vs. Code Reviews, Jeff Atwood compares pair programming to code reviews, suggesting that both can accomplish the goal of more than one person looking at every line of code:

I'm intrigued by the idea of pair programming, but I've never personally lived the pair programming lifestyle. I do, however, enjoy working closely with other developers. Whenever I sit down to work side by side with a fellow developer, I always absorb a few of their tricks and techniques. It's a fast track learning experience for both participants. But I've only done this in small doses. I'm a little wary of spending a full eight hours working this way. I suspect this might be fatiguing in larger doses, unless you're very fortunate in your choice of pairing partner...

I've written about the efficacy of code reviews before. That is something I have personal experience with; I can vouch for the value of code reviews without reservation. I can't help wondering if pair programming is nothing more than code review on steroids. Not that one is a substitute for the other-- you could certainly do both-- but I suspect that many of the benefits of pair programming could be realized through solid peer review practices...

The advantage of pair programming is its gripping immediacy: it is impossible to ignore the reviewer when he or she is sitting right next to you. Most people will passively opt out if given the choice. With pair programming, that's not possible. Each half of the pair has to understand the code, right then and there, as it's being written. Pairing may be invasive, but it can also force a level of communication that you'd otherwise never achieve.

In the end, I don't think it's a matter of picking one over the other so much as ensuring you have more than one pair of eyes looking at the code you've written, however you choose to do it. When your code is reviewed by another human being -- whether that person is sitting right next to you, or thousands of miles away -- you will produce better software. That I can guarantee.

Do you practice pair programming on your projects? If so, how would you compare the value of pair programming to that of code reviews?