Photo courtesy of Dav Yakinuma. Click to see it on its original page.
Jeff “Coding Horror” Atwood can’t help wondering if pair programming is nothing more than code review on steroids. Like me, he’s only tried code review and found it useful, but hasn’t given it a shot yet. I’ve done what you might call pair design, where another programmer and I sketched out how to tackle a problem, divvied the work between the two of us and then each went to our own machines to implement, but I haven’t done actual pair programming since Crazy Go Nuts University (and then, it was a matter of a shortage of terminals, not technique).
I understand the expounded benefits of pair programming on an intellectual level. If you view code reviews as being similar in spirit to using a compiler, then pair programming is analogous to working in an interpreting language with an interactive mode or REPL: the feedback comes at you, pronto!
It’s a harder sell on the emotional level. I consider myself a social and outgoing guy — something only reinforced by my work as a technical evangelist and from accordion busking — and even I like to “lower the cone of silence” and zone out when I’m coding. I think I could do a couple of hours’ worth of pair programming a day, but all day, day in, day out? I’ve got my doubts.
There’s also the matter of who you’d get paired up with. Would I have the patience to work with someone with less skill than me, or worse, who could code circles around me?
An unlikely pair programming team-up. But remember this: He died for your segfaults!
Click to see the site from which this image came.
Theory and practice being two different things, I should give pair programming a try.
Jeff concludes his article with a request to his readers for their experiences with both code reviews and pair programming, followed by this:
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.
Links
- Coding Horror: Pair Programming vs. Code Reviews
3 replies on “Jeff Atwood on Pair Programming vs. Code Reviews”
>>or worse, who could code circles around me?
I think it is a pitty for you that you would find coding with someone more skilled than you a problem.
It appears to me that this approach would cut you off from learning.
I pair when I have a problem too big for one brain, I have to learn something or I have to teach, and there is also the social team building factor. I don’t think pairing all the time is a good thing, although in some situations it also has its place.
james ladd: “Would I have the patience to work with someone with less skill than me, or worse, who could code circles around me?” was not so much a question of mine as it was an attempt to put that question in the reader’s mind, particularly those with very competitive natures.
Please, read a little more about pair programming. Pair programming is a little more than only code review; In fact, the other programmer shouldn’t care about your syntax error (that’s your compiler job) or even your logic error (that’s your unit tests job) but instead of the general direction of your coding. That’s why their are called “driver and navigator” or “pilot and co-pilot” instead of “executor and examinator” for example.
This is a job more apt for your right brain when your left brain is occupied to coding and avoiding syntax error and other programming pitfall. And unless you’re the next evolution of humanity, you probably have the same limitation than any human which is that when one-side is very busy doing something, the other side is put in a silent veil, awaiting some break to wake up and react on what you were doing.
See this excellent conference of Martin Fowler about this (and other agile things): http://www.universite-du-si.com/fr/conferences/6/sessions/909