Author here, that’s a great question! We approach this by ensuring that there are always multiple people that can review a given codebase or service. In practice what this looks like is we have teams that own our different services. Rather than just assign a random person from that team if you’re making a PR for one of their services, we utilize what we call “open” slack channels, where any one can ask questions of the team. So you’ll go to the teams’s slack and ask for someone to review. We recommend @ mentioning the people who’ve most recently made significant changes to the code you’re working in as they’re most likely to be the best reviewers. But by sharing the responsibility across each team, that ensures there’s no piece of code that only one person across the whole engineering organization is qualified to review. For projects within a team, there will generally be one or two dedicated reviewers and we utilize stand ups to check in and make sure no one is overloaded with reviews. And since the whole team has familiarity with the project, it’s easy to swap out a reviewer if someone is overwhelmed or on vacation.
Not everyone is the right person for a specific code review. Even on small teams someone may be more of a subject matter expert in one facet of your system or code. Therefore load balancing isn’t really the right way to look at it. The idea should be to seek feedback inclusively and welcomed from all teammates. As a submitter your job is to make sure you get the right feedback if there is someone more knowledgeable of a topic. This is why standup is a good place to discuss a code review where you can identify need for time and also identify right people.
Agreed it shouldn’t be an even distribution of review requests across the board. That said, if a few people are getting all the reviews, it’s difficult for them to make progress on their project work, and for other engineers to learn code review best practices and get familiar with the codebase.
It’s a balance but you need to balance team priorities. If you aren’t shipping code because of your time on code reviews you need to better manage your time. Call it out during stand up (assuming your team has them) and make it clear you don’t have time or code reviews today because you need to focus on your deliverable. If the review is more important your team can identify this collectively. However, individuals should never feel you describe, if so it’s a lack of coordination across team.
I always thought that it was ideal that the most experienced person does the bulk of code reviews and clicks the merge button even if that means that they don't write much code themselves. It's a model that, for example, works very for Linux.
I think that there's a lot of value in having somebody who has a picture in their head of the entirety of a system who can spot impedance mismatches across projects and spot germinating code smells before they cause major problems.