I support code reviews and look forward to them. I would expect other professional software engineers to embrace code reviews. They have many uses, one of the most useful to me is identifying mistakes in code changes. I’ve seen many situations where even a quick informal code review would have caught bugs that would be easily fixed. A user familiar with a code base will look over lines of code and not notice some obvious mistake, it’s part of the human condition. It’s a common issue that writers also have, it’s why editors and peer reviews are crucial.

The argument against code review is ‘does anyone actually perform the review?’ because ‘they take up a large chunk of time’. There are jobs where developers are pushed to pump out code quickly. Based on my limited research and experience this leads to low quality code. High quality code requires either a top notch developer who never makes mistakes, or peer review. QA doesn’t perform code reviews, they just test the input and output. Only other software developers can accurately peer review another’s piece of code. Good companies make time for their employees to perform code reviews, better product makes for better profit.

Some developers are afraid of code reviews because they’re embarrassed about their code. I remember being extremely self conscious about my code only six years ago. Since then I have performed numerous peer reviews and review numerous other pieces of code. I got to see first hand the code that worked well versus code that would cause issues. It also encouraged me to increase my code’s readability and it is why I started using doxygen to generate technical documents. This eased the code reviews for my peers, I was optimizing code for performance and reliability which significantly increased code complexity.

The key to proper code review implementation is a proper code review process, a good discussion for another time.