13 Ways to Give Effective Code Review Feedback
Learn how to give constructive code review feedback to promote open communication and positive collaboration within your engineering team.
As the year comes to a close, you may be conducting or receiving your final code reviews of the year.
Code reviews are challenging for managers and developers alike. However, when done correctly, these reviews can improve efficiencies within an entire engineering team or company. With regular code reviews, managers can spend more time on their main priorities like designing and optimizing processes for building code while developers write it.
Let’s explore code reviews and 13 tips you can use to give effective ones!
What is a code review?
A code review is a methodical assessment of code delivered by a peer. It is used to identify bugs, help developers learn the source code, and increase overall code quality. Once a software developer has completed coding, they can ask a teammate to review their work to flag issues like uncovered edge cases and logic problems.
Code reviews are important because they set a foundation for continuous improvement within an engineering team. When you frequently have your work critiqued by more senior team members, you spread knowledge across the organization. A strong code review process also prevents businesses from shipping unstable code to customers.
Run efficient meetings, come to a decision, and get back to work
Level up your engineering meeting habits to boost engagement and productivity with a collaborative meeting agenda. Try a tool like Fellow!
How to give effective code review feedback
- Check for functional defects
- Check for coding conversion
- Check how APIs are used
- Show validation scenarios and corner cases
- Be honest
- Be specific
- Ensure you’re familiar with the code
- Assume good intent
- Keep code reviews small
- Get experience delivering code reviews
- Explain the why behind your feedback
- Avoid using sarcasm
- Give your developers praise
1Check for functional defects
One of the first things you should look for when reviewing code is functional defects. These are the errors you’ll see if the behavior of the software is not compliant with the functional requirements. Check to see if there are bugs that hinder the functionality of the code. Categorize defects into one of three categories: minor, major, and critical. The nature and severity of a defect will determine in which of the three categories it belongs.
2Check for coding conversion
Code conversion refers to the method or technique used to convert code from one format to another. Code reviews are beneficial for ensuring a codebase is coherent and maintainable. For this reason, it’s important to identify code that doesn’t follow coding conventions so it can be fixed.
3Check how APIs are used
It can be extremely challenging to trace changes through an application to see how they affect your interface. During code reviews, check to see if application programming interfaces (APIs) or third-party libraries are being used correctly. You should also look to see if the code falls into a standard design pattern, if the code provides a sufficient abstraction for other modules, and if the developer is using the proper construct.
4Show validation scenarios and corner cases
Provide feedback around edge cases and alternate scenarios in which the current implementation would fail. During code reviews, you should identify problems with the logic, forgotten validation scenarios, or corner cases that haven’t been covered.
5Be honest
Be honest when delivering feedback during your code reviews. Code reviews are a social activity that will help you form better connections with your teammates and direct reports, so you need to be frank but kind in your comment delivery. Don’t skip out on negative feedback, but keep it balanced and affirm positive behaviors. Give suggestions on how you would go about improving the code in the future.
With Fellow, it’s easy to deliver honest feedback on meetings, projects, and performance as you work. Our prebuilt templates can help you give and receive meaningful code review feedback without overthinking the process.
“Honest feedback from those whom you trust is invaluable for personal development.”
– Alison Vidotto, CEO and author
6Be specific
Be objective and give specific examples that the developer will be able to look back on in the future. For example, instead of leaving a comment that says “Please change X,” you can say “Let’s change X as it could cause nasty bugs” with a further explanation of why it’s important to make the change.
Tip: Use emojis in your code reviews to add context or additional meaning to your comments. For instance, use a thinking face emoji to emphasize your curiosity about a line of code in your comment. But remember that emojis aren’t an excuse to give unnecessarily harsh feedback!
7Ensure you’re familiar with the code
You won’t be in a position to give meaningful feedback if you don’t understand the code. You may even do more harm than good if you start giving feedback on a codebase with which you’re unfamiliar!
If you haven’t worked with the codebase before, ask a colleague to walk you through the code before conducting the review. Then, once you complete the review, have that same colleague take a look and let you know if your feedback is thorough enough. While the focus should be to check if the code is correct and of high quality, it can also be a great learning opportunity for you.
8Assume good intent
You should assume the developer you’re working with wrote their code with good intent. When something is unclear, ask for clarification instead of assuming ignorance. Avoid possessive pronouns in your review like “your method has a bug” and absolute judgments like “this will never work.” If a problem requires an in-depth explanation, provide the developer with links or other resources that can help them improve.
After each review, let the code author know to what extent you expect them to respond to your comments or whether you’d like to review their revised code after they make changes.
9Keep code reviews small
If each code review with a direct report is lasting more than an hour at a time, you’re conducting your reviews too infrequently. Just as you shouldn’t review code too quickly, you shouldn’t review it for too long in one sitting either. Conducting more frequent reviews should reduce the need to complete lengthy ones and can even improve the quality of the work.
10Get experience delivering code reviews
The best way to learn is by doing. The more code reviews you do, the better the feedback and guidance you can provide your teammates moving forward. With practice, you’ll begin to understand how to provide the most value to your code author during each review. For example, you’ll learn how to effectively approach sensitive topics if you find yourself consistently reviewing the work of junior developers who are trying to impress with unnecessarily complicated code.
11Explain the why behind your feedback
It’s a great idea to explain your intent, the best practices you’re following, or how your suggestion improves code health when conducting a code review. Don’t assume every developer will understand your reasoning without elaboration. Clarify why you’re suggesting each change with a brief explanation.
“Your why is your purpose, cause of belief – the driving force behind everything you do.”
— Simon Sinek, American speaker and author of Find Your Why
12Avoid using sarcasm
Sarcasm is not a leadership competency. Sarcasm meant to belittle another person can diminish confidence and degrade trust within a team. It can even lead to conflict or long-term passive aggression.
Avoid critiquing the person and focus on the code itself. Using sarcasm in bad faith will only harm your relationship with the individual. Instead, help your teammate or direct report by giving them plenty of advice and tips to write better code. Imagine code review as a sport where you and your teammate improve with each practice session.
13Give your developers praise
Code reviews are challenging for both parties. It can feel intimidating to be on the receiving end of constructive feedback, so don’t forget to pat developers on the back for the things they’ve done correctly after each review. Remember that positive feedback can be just as useful as constructive feedback for a developer!
Parting advice
Developers are humans too, meaning that your colleagues and direct reports are bound to make a few mistakes here and there.
Code reviews are an important step to get a second opinion before code is merged into an upstream branch. The practice can improve code quality, support knowledge transfer, and even make quality assurance (QA) testing easier. Additionally, giving constructive feedback—on code or otherwise—will help your colleagues improve their skills and even enrich relationships within the team.
Whether you’re new to code reviews or a seasoned pro, try out our 13 tips to promote positive collaboration and open communication with your teammates. Happy reviewing!
