You open a pull request. The code works, but there are three major issues: unclear variable names, a missing error handler, and a logic flaw that will blow up in production. Now you need to tell your teammate — in English — without making them feel attacked.
This is the real skill behind code reviews. Not just spotting bugs, but communicating feedback in a way that teaches, motivates, and builds trust. For Vietnamese developers working in international teams, getting this tone right in English is a career-defining skill.
Why Tone Matters More Than You Think
In Vietnamese culture, direct criticism from a senior is often expected and accepted. But in many international teams — especially with Western colleagues — the same directness can feel harsh or demotivating.
The goal of a code review is not to prove you found the bug. The goal is to help the code get better and help the developer grow. Your English phrasing either opens that door or slams it shut.
🗣️ Key Phrases to Say Out Loud
Practice these until they feel natural. Say them aloud three times each.
-
“This looks good overall — I have a couple of suggestions.” IPA: /ðɪs lʊks ɡʊd ˈoʊvərɔːl — aɪ hæv ə ˈkʌpl̩ əv səˈdʒɛstʃənz/
-
“I’m wondering if we could simplify this a bit.” IPA: /aɪm ˈwʌndərɪŋ ɪf wiː kʊd ˈsɪmplɪfaɪ ðɪs ə bɪt/
-
“Could we add a guard clause here to handle the null case?” IPA: /kʊd wiː æd ə ɡɑːrd klɔːz hɪr tuː ˈhændl̩ ðə nʌl keɪs/
-
“This might cause an issue when the input is empty — want to discuss?” IPA: /ðɪs maɪt kɔːz ən ˈɪʃuː wɛn ðə ˈɪnpʊt ɪz ˈɛmpti — wɑːnt tuː dɪˈskʌs/
-
“Nice approach — one thing I’d change is the naming here.” IPA: /naɪs əˈproʊtʃ — wʌn θɪŋ aɪd tʃeɪndʒ ɪz ðə ˈneɪmɪŋ hɪr/
-
“Not blocking, but this could be cleaner if we extract it.” IPA: /nɑːt ˈblɑːkɪŋ, bʌt ðɪs kʊd biː ˈkliːnər ɪf wiː ɪkˈstrækt ɪt/
-
“Happy to pair on this if it would help.” IPA: /ˈhæpi tuː pɛr ɑːn ðɪs ɪf ɪt wʊd hɛlp/
📚 Vocabulary
| Word | Meaning | Pronunciation | Example |
|---|---|---|---|
| guard clause | early return to prevent invalid state | /ɡɑːrd klɔːz/ | “Add a guard clause to exit early if the list is empty.” |
| blocking | something that must be fixed before merge | /ˈblɑːkɪŋ/ | “This is blocking — we can’t ship without fixing it.” |
| nit | a minor style comment, not required | /nɪt/ | “Nit: you can use const instead of let here.” |
| extract | pull code out into a separate function | /ɪkˈstrækt/ | “Let’s extract this logic into its own method.” |
| edge case | an unusual or extreme input scenario | /ɛdʒ keɪs/ | “What happens in the edge case where userId is null?“ |
| idempotent | same result when called multiple times | /aɪˈdɛmpətənt/ | “This endpoint should be idempotent — calling it twice should be safe.” |
The Three Levels of Code Review Comments
In international teams, experienced reviewers label their comments by severity. This saves time and sets clear expectations.
Blocking / Must Fix:
“This will throw a NullReferenceException in production if
useris null. We need to handle this before merging.”
Suggestion / Should Consider:
“This works, but I’d suggest extracting the retry logic into a helper — it’ll make this easier to test.”
Nit / Optional:
“Nit:
userDatamight be clearer thanudfor the variable name. Up to you.”
The magic word is “nit” — it signals: “I noticed this, but it won’t block the merge.” Vietnamese developers often skip this word and write comments that sound more serious than intended. Saying “nit:” changes everything.
Giving Feedback on a Junior’s Code
When reviewing a junior developer’s PR, your English needs to teach, not just correct.
Instead of: “This is wrong.” Say: “This approach will work for now, but there’s a subtle issue with concurrency here — want me to explain why?”
Instead of: “Why did you do it this way?” Say: “I’m curious about the reasoning here — did you consider using a dictionary lookup instead of a loop?”
Questions are more powerful than corrections. They invite the developer to think, explain, and learn.
🎯 Practice Now
Dialogue: You’re reviewing a PR from a teammate
Read this dialogue aloud. Focus on your tone — friendly but clear.
You: Hey, I finished reviewing your PR. Overall, really solid work — the structure is clean and tests look good.
Teammate: Thanks! Any issues?
You: A couple of things. One is blocking: on line 47, if config is null, we’ll get an exception. We need a guard clause before that call.
Teammate: Oh right, I missed that. I’ll add a null check.
You: Perfect. The other is just a nit — the function name processData is a bit generic. Something like validateAndSaveUserRecord would make it clearer at a glance. But that’s optional, your call.
Teammate: Makes sense. I’ll update it.
You: Great. Once you push those changes I’ll approve. Happy to jump on a quick call if the null handling gets tricky.
Exercise: Rewrite These Comments
Rewrite each comment to sound more constructive. Say your rewrite aloud.
-
❌ “This code is messy.” ✅ Your version: ___
-
❌ “You forgot to handle errors.” ✅ Your version: ___
-
❌ “This is inefficient.” ✅ Your version: ___
Sample answers:
- “The structure here is a bit hard to follow — could we break this into smaller functions?”
- “I don’t see error handling for the API call — if it fails, what should happen?”
- “This loop runs O(n²) — for large inputs it could slow things down. Want to explore a map-based approach?”
One Mindset Shift That Changes Everything
The best tech leads think of code review as teaching in writing. Every comment you leave is a small lesson. Your teammate will read it, think about it, and remember it next time they code.
When you write in English, choose words that show you’re on the same team: “we,” “us,” “let’s.” Avoid “you should” — use “we could” or “what if we.”
The PR improves. The developer grows. The team trusts you more.
That’s the return on investment of good code review English.