Code review is one of the most important rituals in software engineering. But for many Vietnamese developers moving into senior or tech lead roles, the challenge is not the code — it is the words. How do you point out a mistake without sounding rude? How do you suggest a better approach without shutting down the conversation?
This guide gives you the exact phrases and patterns that experienced engineers use during code reviews, especially in international teams.
Why Tone Matters in Code Review
In Vietnamese culture, directness is normal. You might say “Cái này sai rồi” and nobody takes it personally. But in many English-speaking workplaces — especially remote international teams — the same message delivered bluntly can feel discouraging or even aggressive.
The goal of code review is to improve the code and grow the engineer, not to prove you are smarter. That intention should come through in every comment you write or say.
A senior engineer does not say: “This is wrong.” They say: “I think there might be a better approach here — what do you think about…?”
The difference is subtle but powerful.
🗣️ Key Phrases to Say Out Loud
Practice reading these aloud. Notice the softening words: might, could, I wonder, what do you think. These are not signs of weakness — they are signs of professional communication.
- “I think we could simplify this by…” — /aɪ θɪŋk wiː kʊd ˈsɪmplɪfaɪ ðɪs baɪ/
- “Have you considered using X instead of Y here?” — /hæv juː kənˈsɪdərd ˈjuːzɪŋ/
- “This looks good overall — one small suggestion though…” — /ðɪs lʊks ɡʊd ˈoʊvərɔːl/
- “I wonder if this could cause issues when…” — /aɪ ˈwʌndər ɪf ðɪs kʊd kɔːz ˈɪʃuːz/
- “Nice work on the error handling — that’s clean.” — /naɪs wɜːrk ɒn ði ˈerər ˈhændlɪŋ/
- “Can you walk me through the reasoning here?” — /kæn juː wɔːk miː θruː ðə ˈriːzənɪŋ/
- “This might be a bit tricky to maintain long-term.” — /ðɪs maɪt biː ə bɪt ˈtrɪki tə meɪnˈteɪn/
📚 Vocabulary
1. nit /nɪt/ A small, optional suggestion. Not a blocker. “Just a nit — you could rename this variable to make it clearer.”
2. blocker /ˈblɒkər/ Something that must be fixed before the PR can be merged. “This is a blocker — we’ll get a null pointer exception in production.”
3. approach /əˈproʊtʃ/ The method or strategy used to solve a problem. “I like the approach, but I think we can make it more efficient.”
4. edge case /ˈedʒ keɪs/ An unusual situation or input that might break the logic. “What happens in the edge case where the list is empty?”
5. trade-off /ˈtreɪd ɒf/ Accepting a disadvantage in one area to gain a benefit in another. “There’s a trade-off here between readability and performance.”
6. clarify /ˈklærɪfaɪ/ To make something easier to understand. “Could you add a comment to clarify what this regex is doing?”
7. LGTM /ˌel dʒiː tiː ˈem/ Short for “Looks Good To Me” — approval phrase in code review. “All comments addressed. LGTM — feel free to merge.”
🎯 Practice Now
Dialogue: Async Code Review (written comment style)
Imagine you are reviewing a pull request. Your teammate wrote a database query inside a loop. Practice saying or writing these comments out loud:
Situation 1 — Potential bug:
“Hey, I noticed this query runs inside the loop — that could be N+1 queries in the worst case. What if we load all records upfront and filter in memory instead? Happy to discuss if you want.”
Situation 2 — Style nit:
“Nit: I think
getUserByIdreads more clearly thanfetchUser. Up to you, either works.”
Situation 3 — Positive feedback:
“Love how you handled the retry logic here — this is exactly the pattern we should use across the service.”
Situation 4 — Asking for clarity:
“Can you help me understand this condition? I want to make sure I’m reading it right before approving.”
Role-play: Verbal Code Review (for 1-on-1 or pair review session)
Practice this short script with a colleague or read both roles yourself:
Tech Lead: “Hey, I had a quick look at your PR — overall it looks solid. Can I walk through one thing with you?”
Developer: “Of course, go ahead.”
Tech Lead: “In the processOrder function, I noticed you’re catching all exceptions with a generic catch block. I wonder if we might miss some specific errors that need different handling. What do you think about splitting it out?”
Developer: “Ah, yeah — I was worried about that too. I just wasn’t sure which exceptions to handle.”
Tech Lead: “Let’s look at the docs together. The key ones to watch for are usually timeout and network errors. We could add two specific catches and let the rest bubble up.”
The One Rule That Changes Everything
Before you submit any code review comment — written or verbal — ask yourself:
“Am I saying this to help the engineer, or to prove I know better?”
When your intention is genuine, the right words usually follow. And when you are unsure, a simple “What do you think?” at the end of a suggestion turns a directive into a dialogue.
That small shift in language builds trust, improves team culture, and makes people actually want your review on their next PR.
This post is part of the Tech Lead English series — practical English for Vietnamese engineers working in international teams.