Why it can feel personal
Writing code takes effort and some creativity, and it is natural to feel attached to the result. When a colleague points out a problem in public, in writing, it can feel like a judgment of you rather than of the change. Text also strips out tone: a short comment that the reviewer meant neutrally can read as blunt or cold.
It helps to remember what review is for. The reviewer is checking whether the shared code is correct and understandable. Nearly every engineer, including very experienced ones, has changes that need work. Comments on a change are a normal part of the process, and a change with no comments is not necessarily a sign of better code; it may only have been read quickly.
Before you reply
Wait if you are annoyed. A first reaction written in a hurry is rarely the best one. Reading the comments, stepping away for a short while, and returning usually changes how they look.
Read every comment once without answering. Often a later comment explains an earlier one, or several comments point to the same underlying issue.
Assume good intent. Most reviewers are trying to help. If a comment seems harsh, consider that it may simply be terse. Assuming a neutral or friendly meaning costs nothing and usually turns out to be correct.
Separate the code from yourself. “This function is hard to follow” describes the function. The code you wrote last week is not you; it is a draft that others can help improve.
Responding to each comment
A useful approach is to respond to every comment in one of a few ways, so the reviewer can see what happened.
- Agree and fix. Make the change and reply briefly, such as “Done” or “Good catch, fixed in the latest commit.”
- Agree but defer. If the point is valid but outside this change, say so and record it somewhere trackable, such as a new issue, rather than promising and forgetting.
- Ask a question. If you do not understand, say so (see below).
- Disagree with reasons. Explain your view calmly (see below).
Do not leave comments unanswered. Silence leaves the reviewer guessing whether you saw it, agreed or ignored it.
Asking clarifying questions
Not every comment is clear. It is entirely reasonable to ask what is meant, and doing so is better than guessing and fixing the wrong thing.
Some useful questions:
- “Can you point me to an example of the pattern you would prefer?”
- “Do you mean this should be handled here, or earlier in the call chain?”
- “Is this a must-fix before merging, or a suggestion for later?”
- “What case are you worried about? I want to make sure I test it.”
That last question is helpful because it turns a vague concern into something specific and testable. If a concern can be expressed as a case, you can write a unit test for it, and the discussion becomes concrete.
If a comment feels cryptic and a written exchange is going round in circles, a quick conversation often resolves it faster than another round of typing.
Disagreeing constructively
You will not agree with every comment, and you do not have to. Reviewers can be wrong, or may lack context you have. The aim is to reach a good outcome, not to win.
- Acknowledge the concern first. “I see why that could be a problem.”
- Give your reasoning. Explain the constraint, the reason for the choice, or the evidence. “The helper you mention rounds differently, and this report needs the exact value.”
- Offer a compromise if one exists. Perhaps a comment in the code explaining the choice would address the reviewer’s worry.
- Ask for their view. “Does that change your thinking, or am I missing something?”
- Know when to stop. If the point is a matter of taste, follow the team convention or defer to whoever owns that area. If it is important and you still disagree, bring in a third person or hold a short call rather than escalating a long comment thread.
Avoid phrases that read as defensive, such as “that is how it was already” or “it works on my machine”. If something truly works, show the evidence calmly, such as a test or a log.
The skills involved overlap with handling technical disagreements and with soft skills more generally, since much of this is communication rather than coding.
Learning from patterns
Individual comments matter, but repeated ones matter more. If several reviewers mention unclear names, missing tests or unhandled errors, that is a pattern worth working on. Keeping a short personal list of recurring comments can help you catch them before the next review. Some teams turn common comments into checklists or automated checks, so the machine catches them first.
If you are early in your career, review comments can be one of the quickest ways to learn how an experienced colleague thinks, so asking “why” is a legitimate and often welcome question.
Looking after the relationship
- Say thanks when a comment helps; it makes people more willing to give honest feedback.
- Keep replies short and specific.
- Do not make changes silently that a reviewer has not agreed to, especially after approval.
- If tone in a comment has genuinely crossed a line, raise it privately and calmly with the person, or with a lead, rather than in the thread.
When feedback is truly unfair
Sometimes feedback is poorly delivered, repetitive or unreasonable. Respond to the technical content, ignore the tone where you can, and if a pattern continues, talk to your lead or the reviewer directly. How teams handle such situations varies, and no single approach fits every workplace.
The goal is that the code improves and both people can work together next time. A calm, curious response nearly always serves that goal better than a defensive one.