The widely accepted norm for reviewing code is to raise a Pull Request, open for comments from the entire team. However, this does not bode well when people prioritize their own work over reviewing. Either the Pull Request awaits reviews for a long time, or is even merged without a proper review. The unending delay to review causes the developers, the overhead of context switching between features while the merge conflicts start to pile up.
There are also teams where the responsibility of reviewing the majority of the Pull Requests ends up on just one person. Only that developer who reviews is aware of all the features that are being developed, and the learning that comes out of the review comments is not shared with the entire team.
Code reviews are best done as soon as possible. A daily routine of reviewing your peers' work can help in the overall quality and learning.
A Disciplined Approach To Code Reviews
I was a part of a team, where there was a definite time blocked after daily standup, and each developer would discuss the code written the previous day with the entire team. This soon transformed into team culture and helped in quickly getting quality review comments, with the involvement of the entire team. It also helped in transferring knowledge of the features being developed across the team members and code reviews became sessions of learning and sharing.
Also, you don’t have to wait till the entire functionality is done to get comments. The immediate feedback makes it much easier to refactor. As for your teammates, it’s easier to understand and give feedback on your code when you yourself showcase it.
Pragmatic Pairing Over Each Commit
Pair programming definitely improves the quality of code, but it may not always be feasible to pair during remote work. In such cases, it’s good to have another pair of eyes go through your code before each commit. You can pull in a fellow developer, give a walkthrough and ask for feedback.
Review Smaller Changes
For a reviewer, it’s always easier and faster to give suggestions on chunks of code rather than an entire feature or story. As for the developer too, it’s easier to incorporate review comments and refactor when the change list is small. Even if you are raising a PR or having pragmatic pairing over each commit, make sure the changes to be reviewed are small, which can be just one logical flow and not necessarily an entire feature.