Peer Code Review

60 team-peer-code-review

Peer Code Review, when paired with a pull-request workflow, is one of the most cost effective ways to resolve both quality and consistency issues before the code is added into a shared branch.

Explore More.

Related Mindset:

Continuous Delivery

Operational Excellence




The input for Peer Code Review is completed work on a particular feature or enabler ready to be merged into a principal source code branch and deployed for testing.


The output of Peer Code Review is a merge of the pending source code into a Continuous Integration branch.

Peer Code Review may refer to a gamut of activities ranging from formal compliance or security reviews to informal “over the shoulder” discussions to the pair programming concept from extreme programming.

The Linus’ Law principle — “given enough eyeballs, all bugs are shallow” — underlying all of these efforts has proven effective in catching defects1 prior to QA or production releases. It is also an efficient way to promote knowledge sharing on development teams, which increases consistency and decreases overall ramp-up time for development team members. A recent study indicated that peer review led to knowledge sharing increases from 66-150%2.

Peer Code Review may focus on:

  • Functional Correctness - A peer review is the first opportunity for another individual to validate that the acceptance criteria of a user story has been met. In particular, there are often easily overlooked edge cases that can be caught during a review.
  • Coding Standards - When an organization has coding standards such as formatting style, naming conventions, etc., a peer review can present an opportunity to ensure consistency with established patterns.
  • Architecture/Organization - A code review may uncover departures from established coding patterns that should be corrected, which leads to suggestions for better code reuse or prompt refactoring activities as a code base evolves with changing business functionality and requirements. Regular reviews across team members builds a shared understanding of what “fits” the code base.
  • Unit Tests - While unit tests should be run prior to a code review by the developer whose code is going to be reviewed, the review may lead to suggestions for improving/updating existing unit tests or adding new ones, which contribute to overall stability and confidence in regular releases.

An ongoing peer review process should enhance the knowledge and mutual trust of each participating team while improving the quality of code delivered to QA.

Common Pitfalls

Peer Code Review has many benefits, but be sure to watch out for the following counter productive practices:

  • Forgetting that Peer Reviews Take Time - Peer Code Review effort should match the complexity of the change under review. Some changes may take only a few minutes to review but extensive changes or even small changes to critical code sections deserve more effort. If the development team doesn’t account for the time to actually do these reviews, they will either become ineffectual rubber stamp exercises or not happen at all. This time should be considered part of the Definition of Done for each development commitment.
  • Being Over or Under Critical - Especially when first adopting a peer review process, there might be a tendency for developers to be overly critical. In some cases, developers may focus on issues that don’t resolve bugs or improve code maintainability. Conversely, some may hesitate to make valid comments concerned about interpersonal impacts. Neither extreme will realize the benefits of Peer Code Review.
  • Very Large Code Reviews - The capacity to effectively review code diminishes with the number of lines of code and time required for review. Smaller code reviews are really a result of properly sized user stories and tasks. Outside of some occasional refactoring tasks, a trend of large code reviews is probably a sign that work should be broken down into smaller chunks for review.


At Universal Mind, we favor reviews that occur in an isolated branch prior to merging with the main development trunk. Most modern source control systems support this flow: