The Rules of Programming

Rule 6. Code Reviews Are Good for Three Reasons

One of the biggest changes in the thirty-something years I’ve been programming full time is the gradual acceptance of code reviews of various forms.

I’d never even heard of code reviews until the early ’90s. I’m not saying they didn’t happen, because of course they did, but they weren’t widespread outside of failure-is-not-an-option situations, like medical-device firmware or control code in rockets. You know, the sort of thing where bugs kill people.¹

For most programmers 30 years ago, the thought of someone else looking through your code felt…invasive. Sure, if you’re collaborating with people, you have to at least look at the interface to your teammate’s code to figure out how to interface with it, and you’ll probably end up single-stepping through someone else’s code—but actually walking line-by-line through code and passing judgment on it felt deeply weird. Like reading someone’s diary, or (in modern terms) stumbling onto someone’s browsing history.

Anyhow, in the early ’90s I transferred into a team at Microsoft that had a code review policy. Lucky for me, my project was so inconsequential in that team’s grand scheme of things that my project team and I were completely ignored. Among other things, we were left to decide what our code review process was. I’m not even sure what the actual official code review process for the big team was; we just did what we thought made sense and nobody ever checked up on us. I certainly wasn’t ...