Code Review and Pair Programming

I was recently reading comments on Slashdot

While most developers agree that code reviews are a good thing, the people that don't like code review seem to think of it as a matter of the developer's skill level. If you write good code, then you don't need code reviews.

I don't believe this is right. At a big giant newspaper, or even for a book publisher, there are professionals that are really good writers. But this doesn't stop the publishers from hiring editors to review what they are writing. This is an example of feedback that ensures a high quality product. Even in school you can always agree that any paper you write is a better quality if you have at least one person proofread it first. I know I've gotten A's from papers that went through this process.

At my current job we do pair programming. I was skeptical at first, but this process ensures that every line of code checked in has been reviewed by a peer. I know this is not for everyone. It's an extreme diversion from the school of thought that programmers are best left alone in a cave.

Not only is code review built into pair programming, but it almost feels like an apprenticeship to new hires. It helps get them up to speed a lot faster than the old way where the new developer would bang their heads on code and then come ask a bunch of whiny questions to the more experienced developers. And usually the more experienced developers always give an indication that they don't have time to answer questions. When you pair, asking questions is part of your job and the more experienced person encourages you to stop them and explain what they are working on.

The final thing I like about pair programming is that it actually focuses you better. Let's say you are by yourself and feeling tired. You might want to goof off and go on Facebook or surf the web. When you are pairing, the other developer can help pick up slack, or you might help them. This is especially helpful during the after-lunch food coma.