I am now convinced that the only (decent) way to get better at writing code is to get the code you've already written reviewed by someone else, and to review someone else's code. I've seen enough code reviews from both sides to realize the amazing investment in a developer by participating in a code review with them.

Many eyes make all bugs shallow. -Linus' Law

Let me 'splain. No. Let Me Sum Up

First of all, if your code review ever results in the following, you're doing it wrong: shouting matches, gunshot wounds, spitwads, homocide, suicide, genocide, or insecticide. Before doing a code review, take a gander at the Ubuntu Code of Conduct". It's a great guideline for open source development in general, and it's best to adhere to these guidelines in code reviews specifically. The purpose of the code review is the betterment of code, reviewer, and reviewee.

It's been almost a year since I first started hacking on Entertainer. It started as a hobby toy application, with a few young developers. In that time, we have implemented various procedures and code standards. Only recently did I submit some code for review that I realized how insightful these same developers have become, all from code reviews.

Why Review Code?

As I've started reviewing code from other Launchpad developers, and talking with experienced code reviewers, I have seen a few schools of thought on the "why" of code reviews. The first reason to review code is to check for potential bugs. What's great about this is that if you're following TDD, or any test-driven methodology, checking the quality of the tests is a great indicator to see the functionality of the cade you're reviewing. Another reason for code reviews are to doublecheck implementation details. This is helpful when reviewing an area of the code that you're not familiar with. Ask the reviewee plenty of questions. Often, in answering these questions, a reviewee might see issues in their own code.

When introducing mandatory code reviews, the process is a little awkward at first. Why wouldn't it be. You're probably used to just writing code and committing it. Introducing code reviews means many more steps required to get your code into the mainline. But how confident are you in the code your fellow developer is? What happens when you have to work on their code? If you've reviewed that code, you'll probably understand the code in at least some capacity.