Three Thumbs Up

The Code Review
Software development teams often employ code reviews, sometimes called peer reviews, to go over code in order to reduce bugs or enforce standards. Some teams implement this in a committee-like way with developers sitting around a conference room table reviewing each other's code on a projector. Other teams place this responsibility on a single review, sometimes an architect or team lead.

Experiences in these styles can be less than ideal as the developer being reviewed feels like he or she is being "piled on." To be called out in front of your peers on opinion driven issues can be demoralizing. It also promotes individual ownership of the code.

This process can, over time, create animosity between team members resulting in, usually, an end to following this process. It doesn't become productive, it takes too much time and you are reviewing large blocks of code which may be too late to change without major refactoring efforts.

The Core10 Way

Quality
We believe that the peer review is an important factor in overall quality of the software we write. If you've ever asked someone to read over a proposal, letter or paper for you then you recognize the benefit of having a second set of eyes on your work.

Learning & Sharing
Core10 uses the peer review process to also share ideas, effectively teaching other team members about new ways to handle code in a certain situation. Many times the reviewer learns as well. Constructive comments and suggestions are a fantastic way to share ideas.

Promotes Team Ownership
One of the problems in the large, overbearing processes previously mentioned is that it promotes individual ownership of the code - therefore the review becomes personal. It promotes of a feeling of "It's MY code, how dare you!"

In an agile process the team owns the code. Each team member is accountable to the team as a whole. Once you understand that point of view, as both a reviewer and one being reviewed, the personal ownership becomes less of an issue. It's not personal, but rather for the good of the team. Everyone becomes an advocate for good, clean code. Yes, it takes discipline, but if your team believes in it from the beginning, they reap the rewards.

How We Do It
When Core10 started to implement the peer review process we tied it to our source control system. We use Gitlab Enterprise and require merge requests before merging into our development branch. The merge request is reviewed by peers, conversations take place and the code is passed or changes are made.

Three Thumbs Up
As part of Gitlab's merge request feature you can click on a thumb's up emoji. This became the initial practice to approve a merge request. When a dev has three thumbs the code can be merged into the development branch.

So our practice has become to be known internally as "Three Thumbs Up". Since the inception we've utilized more features in Gitlab to enable gates to require approvers instead of just relying on the voting, but the principle is the same. We can scale it based team size, and ensure a second, or third set of eyes to collaborate more as a team.

Conclusion
While we employ other tools to ensure quality of the software we develop, the "Three Thumbs Up" is the beginning of team code ownership. Everyone has a say. Everyone contributes. Everyone has one goal - excellence in software development.

Photo by ål nik on Unsplash