Article summary
Peer feedback is a crucial part of software development. Requiring other developers to look over and approve pull requests before merging is vital to preventing bugs and other issues. Sometimes other developers are too busy to be thorough, and pull requests are frequently given little feedback. Here are some tips to get better pull request feedback.
Include some context.
Sometimes it’s unclear to a reviewer what the code they’re looking over is supposed to be doing. This means that reviewers can look out for logical errors in your code but will have trouble determining if the code is accomplishing what it should. Including a high-level description of what the code does can help reviewers understand what they should be looking for.
Also helpful is including some steps on how to run the code you’ve written. A description of how the feature should work means reviewers can quickly test it out. If applicable, including screenshots or a short video clip can also provide a lot of context.
Pair on reviewing.
If time allows, it’s beneficial to work directly with the reviewer while they review your code. It allows you to walk through your code and explain your thought process. It also gives the reviewer a chance to ask questions quickly and point out their concerns.
Pairing on reviews means you can also pair on solutions to any problems that come up. Not only can you get pull request feedback quicker, but you’re also getting issues fixed quicker.
Identify process issues.
Sometimes issues with the process itself will provide feedback. If there is a sense of needing to get work in quickly after someone has opened a pull request, reviewers can feel pressure to approve quickly. Some teams may not feel they have the time to be as thorough as they should be, resulting in code reviews becoming a rubber stamp process.
Code review should be considered just as important a part of development as programming itself. A feature is not done when a pull request is opened. It is done when it’s been approved and closed. Teams should ensure that developers don’t feel pressure to complete open pull requests quickly and have enough time to be as thorough as necessary.