Code Reviews - Not just a quality tool

I’m a big fan of Code Reviews, or Peer Reviews, within the work flow of a team. But many times when talking about them people refer to them mostly as a tool to avoid bugs, improve quality or the overlooking of details. While these things do surely come out of having a review process, I do not believe they are the real reason why they are a good thing for teams.

Code Reviews, to me, are about getting the team in sync. They are about making sure the team’s core values are spread throughout the team and observed. I’m not talking about Coding Standards, those can be enforced and checked with automated tools, I’m more concerned about architecture, code simplicity and conventions, things that are not measurable to some extent and more about making sure code reflects the core values you have.

In my previous team I made sure to on-board every developer by having them read up on Object Calisthenics , a practice that helps code awareness and promotes simplicity. This practice cannot be enforced by automated testing like coding standards, and this is where I believe Code Reviews have a role to play. While having your code reviewed and then reviewing other people’s code, you are exposed more and more to these aspects, and both of those parts are equally important.

During our on-boarding process the first thing developers are exposed to is reviews by the team lead. In our case we were expanding from a one man team, so the team lead held the core values, what we believed good code should look like. The first few weeks were about expressing this and showing, by example, to the team. This is where you can show what your thinking would be to solve these problems in alternate ways. For this step its very important that both sides keep an open mind, because at this point you are building the new core values, which the team will believe in, this means no one is right.

Now, only having your code reviewed and criticized is not a learning experience, the real learning happens when you start reviewing other people’s code. This is where you have to start internalizing the agreed values and projecting them on other people’s code. In our process I noticed that some developers were focused on large tasks and some on short tasks, the ones on longer tasks took more time to integrate into this, due to the long feedback loop. I recommend you try to make sure new developers have a balance of short/long tasks so they are not out of the feedback loop.

After a few months of our team expansion we noticed that the comments made on each other’s code were a lot more standardized, especially to me, the team lead. I noticed that by the time I came in to make a comment, another team member had already made it. This was a good sign that the core values were being spread.

One thing to note is that when a big change happens in the team, here we went from 2 devs to 5, it is important to re-build core values together, not simply impose them. We had many team meetings to discuss code together in order to evaluate if our values were indeed useful and made sense. The practice of “code burns” is great for this. Code Burns are nothing more then team code reviews where you can make comments and discuss as a team about each point.

If you are trying to implement a Code Review process or if one is being implemented in your team, be sure to keep this in mind, its not about having your code criticized by someone else, its about helping everyone be on the same page about what the team believes is good code.

Looking for someone to do this in your company? I’m currently looking for new challenges