The benefits of code reviews are plentiful; sure, they improve code quality and ensure consistency in a code base. But they also help development teams knowledge-share, as a committer may use a technique or algorithm that reviewers can learn from and incorporate into their own work.
Ultimately, code reviews raise the quality standard across an entire organization.
At Pinpoint, an Austin-based tech company that provides users with software analytics based on proprietary artificial intelligence, Director of Engineering Rick Blalock distributes pull requests among team members to make the work manageable. He also makes sure each developer has the tools they need to critique their peers’ code as efficiently as possible.
Blalock splits pull requests into two brackets: those that require immediate attention and those that are more nitpicky. And when engineers disagree on how to write certain code, they prototype it out, as was the case with the recent adoption of React Router.
“Rather than make assumptions, someone on the team demonstrated how it would tackle some of our advanced use cases,” Blalock said.
Blalock shared the results of that session, as well as additional advice on fostering a culture of positive code reviews, below.
What best practices does your team follow when doing code reviews?
Because of SOC 2 compliance, we must do things like lock down merging into master and ensure that all pull requests (PRs) have approval. If there’s an approval but a new commit comes in, we revoke the approval and start over.
Apart from those strict, compliance-related processes, we try to have three reviewers with at least one reviewer running the code. We also try to be cognitive of the PR review load and make sure not one person is burdened with a ton of PRs a day. GitHub has a new round-robin feature for this but we haven’t implemented it yet. By doing this, we get the added benefit of knowledge-sharing and awareness around code changes in the product.
When there’s a difference in opinions about how to write certain code, how does your team handle it?
Visibility, collaboration and efficiency are core values. If there’s a new approach to some code, architecture or pattern, someone will usually prototype it out and share it with the team for feedback. This allows us to agree upon the right approach quickly. As the saying goes, “a prototype is worth 1,000 meetings.”
For example, we recently switched to React’s Router component. Some were skeptical that React Router met every single one of the requirements we had. Rather than make assumptions, someone on the team prototyped it out and demonstrated how it would tackle some of our advanced use cases. We reviewed it as a team, got quick consensus and made the pivot.
For smaller, code-level reviews, the reviewers can usually come to an agreement in the PR or after talking it out in person. Ultimately, the tech lead on the team has the final say.
Analyze and scrutinize the code, not the person.’’
What advice do you have for fostering a positive code review culture?
Analyze and scrutinize the code, not the person. Make sure PRs are spread out among the team. Encourage team members to label nitpicky things as such, so it’s clear what’s minor, versus what is an important code critique. Enable the team through tooling for quick review.
For example, on the front end, Zeit or Netlify do PR previews of a build that improves velocity. If you have to spin up an entire stack for every PR, it can discourage a good PR review.
