Last month I attended OSCON 2012 in Portland, Oregon. OSCON is the largest open-source convention in North America. Pretty much nerd heaven, which suits me perfectly fine. While there were some hits amoung the misses, my colleague Scott Hyndman and I came away with some motivating ideas to take back to Blu Trumpet.

One of those ideas is peer reviewing code. Yes, we were guilty of not reviewing code before commits. So three weeks ago we decided as a team to have every git commit be peer reviewed, as a first run. Our process works as follows:

  • commit changes as a feature branch via git flow and push the branch upstream
  • create a pull-request via github
  • randomly assign someone on the team to review the code via Campfire (this is done via Hubot, our IRC robot we’ve programmed internally at BT)
  • pair program and have the commiter explain the code to the reviwer before merging

After three weeks of this, I can personally say that our code quality has improved. We are slowly getting everyone on the same page on coding style because it’s enforced during the pair programming phase. Futhermore, we are getting nice knowledge transfer across our team as the random selection forces members to familiarize themselves with different components of our system.

It has also dawned on me that peer review is a great way to refactor the code base. We often think of refactoring as a hammer job, but minor refactors over time can really clean up the code long term. We’ve taken a “always have a commit make the code base better” attitude on every merge.

But what I love most about peer review is that it feels good. I get a little dopamine spike every time I commit something knowing that the code style has improved and any minor refactors have taken place. This is probably it’s most powerful benefit.

You see, over time, when building a team, you want good habits. And how do you build habits? By applying a well-known pattern known to create them:

  • have a stable repeating anchor (pull-request)
  • engineer as easy an habit as possible (review the code for style and design improvements)
  • be rewarded for the habit (the good feeling I get when I know I’ve done my job)

This is precisely why peer review works. It plugs into a habit-forming routine that transfers across team members. We plan to make improvements and adjustments as we move forward, but so far it’s been a positive experience.