Scaling Code Review as a Staff Engineer

July 18, 2023

When I first became a Staff Engineer I struggled to keep up with Code Reviews. I was drowning in review requests from different teams and different parts of the application. I couldn’t keep up and I felt guilty about not getting to reviews quickly or providing detailed enough reviews. It turned out that the way to improve my code reviews was to spend less time doing them.

Adjust your expectations

When working on a small team on a codebase that you understand well it may be possible to do line-by-line reviews of your teammates’ code. To provide valuable feedback on code you need to understand the context around that code. How the surrounding code works, what the intent of the feature they are working on is, and team-specific conventions. The members of a team are exposed to that context daily and can quickly start doing a meaningful review. For someone outside the team, the majority of the code review time may be spent just downloading that context into your brain. This doesn’t scale.

You need to change the teams’, and your own, expectations for your reviews. You shouldn’t be doing line-by-line reviews anymore. Nor should you be trying to identify issues that need team-specific domain logic. Trust the team to do those. That is no longer where you can add the most value.

What to Review

If not these things what should you be looking for in code review? As a Staff Engineer, you must take the time to think about the unique value you can provide. If you don’t you may end up doing a bunch of code reviews slower and worse than a developer on a team would. You aren’t adding value as a Staff Engineer if this is the case.

These are things I focus on when reviewing code:

Things you know best

What are you an expert in? Where is your deepest experience? Backend? Frontend? Performance? Platforms? Security? Whatever that is these are the places you should go a bit deeper in code reviews. This is where you can provide unique insight. You will also improve your understanding of how the application handles those concerns.

Things that are difficult to change

This is the best way I’ve found to do impactful reviews. Ignore the code that will be easy to change and focus on the things that will be difficult to change. Often this means focusing on whether the code is following architecture patterns and what dependencies the code has.

Sometimes it means understanding the public API of the code you are reviewing. If the code exposes an API that will be used outside of the team, either via web endpoint or internally, then you should understand that API. Approach it as someone who would be trying to use it. Having someone approach the API with fresh eyes and experience using good and bad APIs can lead to incredibly valuable feedback.

What if the API/interface is difficult to understand or find? Read the docs, there are no docs? That’s great feedback right there. If it’s hard for you to discover in code review it will be difficult for a developer trying to use it to discover. Ask the team to write some documentation or at the very least to describe its usage in the PR description.

Things that affect longer-term technical vision

Team members tend to be very focused on the work their team is doing often at the expense of what other teams and the wider organization is working on. This isn’t a bad thing. You want your teams to be experts in their domain and not be distracted by what every other team is doing. As someone outside the team, you can bring relevant context from the wider org to the team.

As a Staff Engineer, you should be spending more time understanding cross-team goals. The technical vision for the project, the application architecture, and large migrations or deprecations in progress are common examples. Helping teams move towards those goals as they work is important work.

When moving into a Staff Engineer role it’s easy to continue doing things the same way you always have. You must adjust some of the activities you’ve always done to take advantage of the unique strengths of your new role.