Exactly what to say in code reviews
7 techniques to add to your daily toolkit when giving code review feedback
You want to give someone feedback in code review, but you know text is so hard to get right. It’s misinterpreted all the time.
You don’t want your message to come across the wrong way. You want the other person to be open to your suggestion and see your point of view.
This is surprisingly hard to get right!
In the past, I gave feedback which slowly built tension throughout the review until there were multi-paragraph-long comment threads. My teammates were defensive, and I was at fault.
I tried a few approaches to fix this and observed other engineers who gave great code reviews. After learning a few tricks, I never ran into the same issues.
This article will give you 7 simple techniques I learned to respectfully give feedback in code reviews.
For each technique, I’ll give you examples of how and when to use it.
📣 Announcement: Actionable insight library
I released a library of 100+ actionable career growth insights you can read in an hour!
It’s perfect if you want a condensed version of everything you can do to level up in your career from the past articles. You can get it for free as the second referral reward!
Finally, this is the last call to lock in a paid subscription at $5/month before it goes up to $12/month this Wednesday. If you’re interested in the TLDR library, you can even get a 40% discount after upgrading.
Alright, let’s get into the techniques!
1) I wonder…
I wonder if we could use a switch statement here instead of multiple if-else blocks.
I wonder about the scalability of this solution. As the dataset grows, will this approach continue to perform well, or should we consider implementing pagination or lazy loading?
When to use it: When you want to suggest lightly while opening it up for discussion.
2) I’m curious…
I'm curious about the use of this external library. Have we evaluated its performance impact and compatibility with our codebase?
I'm curious about the accessibility of these custom UI components. Do we have something in place to give us guarantees around that?
When to use it: When you want to call out that something about the current approach might not be the best and understand the author’s perspective.
3) What do you think about…
What do you think about using `map` here instead of mutating the array for safety?
What do you think about abstracting this repeated logic into a separate function or a custom hook to reduce duplication and improve testability?
Another quick alternative to this one is: “Would <x> make sense?”
Would adding an error boundary here make sense to serve a fallback UI?
When to use it: Making a direct suggestion while still leaving room for the other person to give their thoughts.
Below are similar suggestions from Aleksandar (Senior Software Engineer) when you want to make a direct suggestion.
4) What would happen if…
What would happen if this list was empty?
What would happen if the API returns an error here?
Another variation of this one is: “If <x> happened, would we run into <y> issue?” This is a little more direct of what you’re thinking could happen.
If we received a large spike of users, would out-of-memory issues be a concern?
Swapping to that variation for the original 2 examples, it would look like: