Code Reviews: Starting is difficult. Completing work is harder
If code changes take a day to review, that actually means it takes 2-4 days to be reviewed, improved, re-evaluated again, and finally merged. If as a technical lead manager or staff engineer, you are constantly pulled into meetings, block off a small amount of time every day. This works hand-in-hand with my recommendation of setting meetings with yourself on your calendar to prevent burn out.
A few ways to approach code reviews as a team
It really depends on your cadence and expectations within your team, and within your company. The following are a few ways to consider code (or other units of work) for review.
Give and take
To use an agricultural metaphor, creating pull requests for others to review is like eating crops while reviewing seeds new plants. Whenever you open a pull request, dedicate some time to looking at one or two open pull requests others have. Agree as a team that everyone should do the same, since we were already at a context-switching point.
Incentive for small changes
Small to medium PRs are often easy to review either instantly, or after an hour or so of "deep work" time depending on team members' work habits. You can quickly gauge the complexity of a change based on the number of line changes within a pull request. With that information, you can informally set an expectation for the time to review
Small code changes are reviewed within 1 hour
Medium code changes are reviewed within a half day
Large code changes are reviewed before the end of the next day
There will always be exceptions to these rules based on the urgency of importance. However, these should be set up before work begins such as during sprint planning or goal setting and not at review time.
Some red flags to watch out for
If you see it as a pain to review PRs because it takes so long, the PRs are probably too lengthy and/or too complicated.
Consider incentivising smaller PRs. Typically, the larger a feature is, the more likely it has bugs and the less thought is put into reviews. Depending on a team's shared sense of ownership, large changes can cause rubber stamping without line-by-line reviews.
If team members are located in different timezones, ask folks to be mindful of this and prevent long multiple-day delays.
Come to a team agreement
Whatever cadence your team chooses, normalize it within your onboarding or working agreement documents. And remember no matter your skill level, above all else be kind and thoughtful with your critique of others' efforts and work!
Be clear and quickly come to an agreement on how to "pass the baton" of code reviews to your teammates during your sprint.
