This is a repost from the Software Mastery newsletter. If you like what you see, consider subscribing to get emails delivered right to your inbox!
Welcome to the fifth issue of the Software Mastery newsletter.
In this issue, I want to share a few tips on getting faster code reviews.
When I started working in the tech industry as an intern, I was shocked at how long it took to get a code review.
Sometimes, a published code review would take up to a week before someone looked at it and left feedback. This delay is particularly frustrating when working on features that require multiple sequential code changes.
Over time, I’ve learned that there are some things you can do to improve the time it takes to get an approval:
Make your change easy to review.
Assign the change to specific people.
Use your manager as a forcing function.
Make Your Change Easy To Review
Code reviewers are human. Sometimes, your code isn’t getting reviewed because the reviewer opened the pull request, thought it would take a lot of time/effort, and decided to procrastinate.
If this is the problem, here are a few suggestions on how to create beautiful pull requests:
Self-review the code before publishing the pull request. The longer you stay on a team, the better you should understand your code reviewers. After putting up a draft pull request, take the time to review the change yourself and anticipate concerns your reviewers might have.
Test your changes enough to convince your reviewer that it is correct. This tip is important when your reviewer doesn’t have a lot of context. If you can show through thorough automated and manual testing that the change works, they will be more inclined to sign off on it.
Try to keep the pull requests short and focused. To make pull requests easy to review, keep the changes focused on one thing. Try not to mix refactoring with behavior changes, for example, as that bloats the size of the pull request, making it harder to review.
Assign The Change To Specific People
At companies, pull requests typically notify an entire team. If you don’t request a review from specific people, it is common for the bystander effect to occur, where everyone thinks someone else will review the pull request, so nobody reviews it!
To combat this, I recommend two solutions:
Request a review from specific people. To find out who to request a review from, look at who has previously pushed changes to this software package or area of the codebase. These engineers are likely the most capable of reviewing your change.
Message them and follow up. After publishing the review, consider sending a direct message to the reviewer to let them know you are waiting for their review. If they haven’t reviewed after two days, follow up with them. After four days, follow up with them again. This might seem aggressive, but sometimes engineers forget because they’re busy.
Use Your Manager As A Forcing Function
If you’ve done everything in the previous sections and you’re still not getting your code reviewed, it’s time to escalate to your manager.
Make it clear to your manager that you have been waiting on a code review, and that the long wait times are impacting your productivity.
Assuming you have a reasonable manager, they will likely reach out to your reviewer, which should help move things along.
If you find yourself having to do this too often, however, there may be systemic issues at play (e.g., the engineers are so overworked that they don’t have time to review code).
Your Turn!
I hope this issue gave you some ideas on how to get faster code reviews.
I’ve personally used all three of these suggestions throughout the past year and have seen some success.
Do you have any suggestions on getting faster code reviews? Reply to this email or comment below to let me know!
As always, thanks for reading!
Sammy
Top comments (0)