Every page in this book has been checked over by an editor. Why?

Because even if you’re the smartest, most capable, most experienced writer, you can’t proof-read your own work. You’re too close to the concepts, and you’ve rolled the words around your head for so long you can’t put yourself in the shoes of someone who is hearing them for the first time.

Writing code is no different. In fact, if it’s impossible to write prose without independent scrutiny, surely it’s also impossible to write code in isolation; code has to be correct to the minutest detail, plus it includes prose for humans as well! (You do write comments, don’t you?)

It’s common sense that two heads are better than one, especially when the second head is a domain expert or when the author is a junior developer who hasn’t been around the block.

But it’s not all rosy; it’s also true that code review occupies expensive developer time. After all, four people in a meeting for 90 minutes is six on-task hours—an entire on-task person-day. That’s a significant time investment, so we also have to ask whether the benefits outweigh the costs.

Fortunately, there’s data. In the past 10 years we’ve made significant leaps in our knowledge of how to perform code reviews efficiently. Executed properly, code reviews find bugs faster than testing or other known debugging techniques—but when done inefficiently they can quickly become unproductive.

This survey will start by presenting findings that apply in any type of code review, from formal inspections to a single developer double-checking his own work. After establishing these fundamental best practices, we’ll look at data from group reviews.