You’ve just finished reviewing a pull request. The logic has a subtle bug, the naming is confusing, and there’s a whole chunk of code that should be a shared utility. Now you need to write your comments — in English — in a way that is clear, respectful, and actually gets the developer to improve.
This is one of the hardest English skills for Vietnamese Tech Leads. We’re taught to be indirect and humble in Vietnamese culture, but code review comments that are too soft get ignored. Too blunt, and you damage trust. The sweet spot is direct but kind — and English has specific patterns for this.
Why Code Review English Matters
In international teams, written comments are often asynchronous. The developer reading your comment might be in a different timezone, under deadline pressure, or a junior who is still building confidence. Your words carry weight. A poorly phrased comment like “This is wrong” can shut someone down. A well-phrased one like “This approach might cause issues when X — have you considered Y?” opens a conversation.
Key Phrases by Situation
When something must change (blocking)
Use clear but non-aggressive language:
- “This will cause a bug when the list is empty — we need to add a null check here.”
- “This breaks the existing contract — let’s align on the expected behavior before merging.”
- “I think this logic is inverted — can you double-check the condition?”
- “This is a blocker for me. Once we fix the edge case, I’m happy to approve.”
Avoid: “This is wrong” or “Why did you do this?” — these sound aggressive in English, even if you didn’t mean it that way.
When suggesting improvements (non-blocking)
Mark non-blocking comments clearly so the developer knows they have a choice:
- “Nit: you could rename this to
getUserByIdto be more descriptive — just a suggestion.” - “Optional: consider extracting this into a helper function if you plan to reuse it.”
- “Not a blocker, but this pattern might be harder to test — worth thinking about.”
The word “nit” (short for nitpick) is standard in code review culture. It signals: “I noticed this, but it’s minor.”
When asking for clarification
Never assume. Ask with curiosity, not accusation:
- “I’m not sure I follow the intent here — could you add a comment explaining why we skip this step?”
- “Is there a reason we’re not using the existing
formatDateutility?” - “What’s the expected behavior when
userIdis null? I want to make sure the tests cover that.”
When giving praise
Don’t skip this! Positive feedback builds trust and tells people what to repeat:
- “Nice refactor — this is much easier to follow now.”
- “Good catch on the race condition. I missed that.”
- “This is a clean solution. I like how you kept the interface simple.”
Example Dialogues
Dialogue 1: Async comment thread on a PR
Tech Lead (comment):
I see we’re calling the API inside the loop here. This will create N requests for N items, which could be a performance issue under load. Could we batch this or cache the results? Happy to discuss options if you’d like.
Developer (reply):
Good point! I wasn’t thinking about the load scenario. Let me look into batching — I’ll update the PR.
Tech Lead:
Sounds great. Let me know if you want to pair on it.
Dialogue 2: Sync code review call
Tech Lead: “Thanks for putting this together. Overall it looks good — I just have a couple of things I want to talk through.”
Developer: “Sure, go ahead.”
Tech Lead: “On line 47, we’re catching a generic Exception. In production this will swallow errors we’d actually want to know about. Can we be more specific — maybe catch IOException and TimeoutException separately?”
Developer: “Ah, right. I’ll fix that.”
Tech Lead: “Perfect. The other thing is more of a question — is there a reason we’re building the query string manually here instead of using the existing QueryBuilder class?”
Developer: “I didn’t know that existed, actually.”
Tech Lead: “No worries — it was added last month. Take a look, it handles encoding edge cases for us.”
Common Mistakes Vietnamese Speakers Make
1. Being too indirect to the point of being unclear
Vietnamese style: “Maybe this could potentially be a bit improved?” Better: “This could be cleaner — let’s extract the logic into a separate method.”
Being direct in English is not rude. Vagueness often reads as uncertainty, not politeness.
2. Skipping the “why”
Bad: “Change this to use async/await.” Better: “Let’s switch this to async/await so we’re consistent with the rest of the codebase and avoid callback nesting.”
Explaining why turns a command into a teaching moment.
3. Using “you” in a way that sounds personal
Bad: “You wrote this wrong.” Better: “This logic needs to be updated — when the user is unauthenticated, this will throw.”
Focus on the code, not the person. English uses passive constructions or references to “the code / this function” to depersonalize feedback.
4. Not labeling comment severity
Without labels, developers don’t know what to prioritize. Use clear prefixes: blocker, must-fix, suggestion, nit, question, or FYI to signal importance upfront.
Quick Reference Card
| Situation | Phrase to use |
|---|---|
| Must fix | ”This needs to be addressed before merging.” |
| Suggestion | ”Consider / You might want to / One option is…” |
| Minor | ”Nit: …” |
| Question | ”Could you clarify…? / I’m curious why…” |
| Praise | ”Nice work / Good catch / Clean solution.” |
| Offer help | ”Happy to pair on this / Let me know if you’d like to discuss.” |
Final Thought
Code review is not just about finding bugs — it’s one of the most powerful ways a Tech Lead teaches and builds team culture. In international teams, the quality of your written English in reviews directly affects how your team grows. Practice these patterns until they feel natural, and over time, your reviews will be something your team actually looks forward to reading.
Start small: in your next PR review, try labeling every comment as blocker, nit, or suggestion. That one habit alone will make your feedback dramatically clearer.