Jeff Atwood on Pair Programming vs. Code Reviews

by Joey deVilla on November 19, 2007

Guy pair programming with his cat. Cat: “You forgot a semicolon.” Guy:”Shizzle, my kizzle, I’m coding Ruby!”
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?

Jesus and secretary working together at a terminal
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

{ 2 comments… read them below or add one }

1 james ladd November 24, 2007 at 5:10 pm

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

2 Joey deVilla November 24, 2007 at 11:18 pm

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.

Leave a Comment

You can use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Previous post: Not Yet!

Next post: Harmonix’ Pros and Cons for Making “Guitar Hero”