Code review is the only place in software where "LGTM" can mean "I read every line" or "I have a meeting in two minutes," and you are expected to know which.
The comments are in English. The meaning is not. Below is a field guide to the 18 phrases you will see most often on a pull request, what each one says, and what the person typing it was thinking. After that there is a short, serious section on how to write review comments that need no translation. The joke only works because the problem is real.
If you would rather paste a comment and have it decoded for you, the PR Comment Translator does that, and scores the passive-aggression from 0 to 100.
The translation table
| What they wrote | What they meant |
|---|---|
| LGTM | I did not open the diff. I trust you, or I have a meeting. |
| nit: | I will die on this hill, but I want it on record that I was casual about it. |
| Can we... | You will. "We" is you. |
| Why not just... | I would have written this differently and I need you to know that. |
| Interesting approach | I have never seen anyone do it this wrong before. |
| I'm curious why... | I already know why, and I disagree. |
| Not blocking, but... | This is blocking. I will remember if you ignore it. |
| Can be a follow-up | This will never happen and we both know it. |
| As discussed... | I have told you this before and I am keeping count. |
| Have you considered... | You have clearly not considered. |
| I might be missing something | I am not missing anything. |
| Personally, I'd... | This is the team standard as of this comment. |
| What happens if... | I found a bug and I'm letting you discover it yourself. |
| Tests? | I am not approving this, and now I have a reason. |
| Hmm | I'm about to write four paragraphs. |
| Quick question | This is neither quick nor a question. |
| Do we need this? | Delete it. |
| Approved with comments | I don't want to look at this again. Please fix it without telling me. |
The three you will see every day
"nit:" is the most abused prefix in software. It is short for nitpick, and it is supposed to mark a comment as optional: a naming preference, a blank line, something that should never hold up a merge. Used that way it is a kindness. The trouble starts when "nit:" sits in front of a request to restructure the module. A nit that takes an afternoon is not a nit.
"LGTM" has a time problem. An approval that arrives eleven seconds after a 900-line pull request opens is not a review. Everyone knows this, and everyone has done it, usually because the PR was too big to review properly in the first place. Large pull requests do not get careful reviews. They get LGTM.
"Can we..." is a command wearing a question's clothes. The reviewer is not proposing a joint project. Phrasing an instruction as a question feels polite, but it leaves the author guessing whether "no" is an acceptable answer. Usually it is not.
Why reviews sound like this
None of this is malice. Review comments are written for three audiences at once: the author, the rest of the team, and whoever reads the thread a year from now trying to work out why the code looks the way it does. Nobody wants to be the person who was rude in writing, in a permanent record, with their name on it.
So people hedge. Hedging feels safe, but it moves the work to the reader. The author now has to decode whether a comment is a preference, a suggestion, or a hard stop, and the cost of guessing wrong is another review round. Multiply that by every comment on every pull request and you get the slow, tense review culture that teams complain about and rarely name.
The dialect exists because the alternative, as most people imagine it, is bluntness. It isn't.
How to write a comment that needs no translation
Four habits fix most of it.
1. Say whether it blocks. Start the comment with its weight. Some teams use labels like blocking:, suggestion:, and question:. The exact words matter less than the habit. If "nit:" always means optional, people will stop fearing it.
2. Give the reason, not just the request. "Rename this" is an order. "Rename this to retryCount, since n is also used for the batch size ten lines down" is a reason the author can agree with, or correct you on.
3. Ask real questions only. If you know the answer, state it. "This will throw when the list is empty" is kinder than "What happens if the list is empty?", because it saves the author the round trip of finding out what you already knew.
4. Review the code, not the author. "This function does three things" is about the code. "You always do this" is about the person, and it will be remembered long after the pull request merges.
Here is the same feedback, both ways:
Interesting approach. I'm curious why we're not just using the existing helper? Not blocking.
blocking: please use
formatCurrency()fromutils/moneyhere. It already handles the rounding rules for JPY, and this version will be off by one for zero-decimal currencies.
The second one is longer, more direct, and far easier to receive. The author knows what to change, why, and that it has to happen before merge. Clear is not the same as harsh. Vague is not the same as kind.
It works in the other direction too
Authors have their own dialect. "PTAL" often means two lines changed and every comment resolved without discussion. "Good catch!" can mean "I was hoping you wouldn't see that." And "works on my machine" has been ending conversations for decades. If you need that last one in writing, there is a certificate for it.
The PR Comment Translator runs in both directions: paste a review comment to see what it means, or type what you actually want to say ("this is wrong", "did you even test this") and get a version you can post. It is a joke, though the polite rewrites are usable.
Your commit history tells the other half of the story. If a review went badly, the Commit Log Therapist will find the evidence: fix, fix again, address comments, pls.
Send this to someone
Every team has one person who writes "nit:" on everything and one who approves in eleven seconds. They may be the same person. They may be you.
Send them the table. Then agree, as a team, on what your prefixes mean. It takes one short meeting, and you can work out what that meeting costs first.