The concise case for code reviews

Google engineer and former Harvard professor Matt Welsh does a great job of making the case for code reviews. I have never worked in a shop where code reviews were mandatory for every change, or even commonly held, but I’ve always wanted to for all of the reasons Matt Welsh explains. There are a lot of excuses for not doing code reviews, but I can’t think of any more efficient way to encourage developers to learn from one another and to develop a cohesive coding style that spans an entire team.

2 thoughts on “The concise case for code reviews

  1. I have worked in a few places where we did code reviews for every check-in, no matter how small, and I really liked it. It meant that we had less ownership of sections of code, which meant that nobody was afraid of parts of code. In one case there was code with 20 year old comments that was still maintainable and usable. Contrast that with my current gig, where there’s lots of ownership, and when a coder leaves his products become big scary places which everybody disses but nobody ever goes near.

    I think similar arguments can be made for pair programming, though I’ve found less of a payoff for that mode when I’ve tried it. But: yeah, code reviews are awesome.

  2. I think pair programming is great for productivity, learning, and avoiding bugs. Unfortunately, sitting at the same desk with someone else all day would make me completely miserable.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may 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>