Reviewing Pull Requests is a fundamental part of every software engineer’s role. Plenty of benefits, both for the company but also for the engineer:

Catching bugs early on saves a lot of time and thus money for a company.

By reviewing each other’s code, engineers improve their skill set and learn about new paradigms, patterns, tools, etc., but also learn more about the product they are building.

Diversity of opinions for solving challenging technical problems is always welcome.

Spotting repeating problems allows senior engineers to start thinking about raising those issues in team meetings, creating more guidelines around them, giving presentations or writing articles, or possibly writing custom static analysis rules to catch these problems before code reviews.

It can be a good way to engage with the rest of the team! : )

At the same time, we want the PRs to get merged as quickly as possible to avoid them from becoming stale and getting merge conflicts. Here at Babylon Health, with a team of about 25 engineers, we are averaging about 12 PRs every day, which means that we used to see messages like this one quite often:

I should note that we require 2 approvals for every PR to be merged, which essentially doubles the load, requiring everyone in the team to review on average about 1 PR per day. While this doesn’t sound like a lot, it means that unless everyone does their part, PRs might start piling up and becoming stale.