Five Categories of Feedback in Code Reviews
This article is inspired by Peter Muldoon’s talk at CppCon 2025 - Mastering The Code Review Process.
When you review someone else’s pull request and you decide to leave a comment there are plenty of things to consider. Plenty of things that we are not going to cover today, except for one!
Just by looking at the comment you left and reading in once, it should be very clear to the author what to do with the comment you left. You might even start your comments with a corresponding emoji. Of course that should be recognized easily by your organization.
Let’s differentiate between 3 types of categories.
Asking for a change
Asking a question
Kudos
Asking for a Change
This is the most common and also most diverse form feedback. You noticed something in the code. Maybe a bug, a discrepancy, some anomaly and you think it should be fixed. Let’s differentiate between 3 sub-categories.
A Blocker ⛔️
In this category, you will find outright mistakes that shouldn’t get merged in the first place. They might be bugs in the program logic, technical issues, such as lifetime issues in C++ or maybe severe violations of best practices.
Approval Delay 🛠️
Sometimes you can accept a given solution, it’s fine, but you’d like to know if the author thought about - certain - alternatives. Ask it. Tell them that you’re fine with approving the pull request, but you’re interested what alternatives they’d considered. Or maybe you can outright point out an alternative solution and ask the authot to consider it because you think it might fit better.
Approval Given 🔨
Not everything has to be your way or the highway. There are nitpick, or personal preferences that you’d like to highlight without blocking the approval. Then it’s up to the author whether they agree with you or not. They can choose not to fix it, update the current pull request or maybe fix it in a follow-up PR. All is fine. You shared your personal viewpoint and told the author take it or leave it.
Question ❓
Sometimes you don’t want to block the pull request - or you don’t know whether you want to block it - you just need to understand it better first.
You’re unsure why something is done in a given way or what’s the intention of the code in general? Ask it!
Kudos 👏
This might be the most rarely use category and indeed you shouldn’t leave a dozen of it in each code review because it would devalue it. But it’s still important to give credit where it’s due. If you see a nice implementation, a great idea expressed in code, something outstanding, don’t just approve. Leave a comment of “kudos” or “great job”. It doesn’t cost anything to you, but it might mean the world to someone else in a world where workplace stress is so prevalent.