Code reviews are one of the most powerful tools a tech lead has — not just for catching bugs, but for mentoring developers and building a shared understanding of quality. But the way you communicate during a review matters as much as what you say.

As a Vietnamese developer working in international teams, I’ve learned that how you phrase feedback in English can make the difference between a developer feeling mentored and feeling attacked. Let’s explore the language patterns that make code reviews more effective.

Why Your Wording Matters

In Vietnamese technical culture, direct feedback is often normal and expected. But in many international teams — especially with Western colleagues — tone and framing carry significant weight. A comment like “This is wrong” versus “I wonder if this might cause issues when…” can lead to completely different reactions, even though both identify the same problem.

The goal is to be clear, specific, and constructive — not vague, not harsh.

🗣️ Key Phrases to Say Out Loud

Practice these phrases until they feel natural. They’re the foundation of professional code review communication:

  1. “I’d suggest considering…” — /aɪd səˈdʒɛst kənˈsɪdərɪŋ/
  2. “This might cause an issue when…” — /ðɪs maɪt kɔːz ən ˈɪʃuː wɛn/
  3. “Have you thought about edge cases here?” — /hæv juː θɔːt əˈbaʊt ɛdʒ keɪsɪz hɪər/
  4. “Nice approach — I’d refine it by…” — /naɪs əˈproʊtʃ aɪd rɪˈfaɪn ɪt baɪ/
  5. “Can we talk through the reasoning here?” — /kæn wiː tɔːk θruː ðə ˈriːzənɪŋ hɪər/
  6. “This looks good to me. One thought…” — /ðɪs lʊks ɡʊd tə miː wʌn θɔːt/
  7. “Let’s align on the pattern we want to use.” — /lɛts əˈlaɪn ɒn ðə ˈpætərn wiː wɒnt tə juːz/

📚 Vocabulary

1. Nitpick /ˈnɪtpɪk/ A small, minor suggestion — not blocking but worth noting. → “Just a nitpick: variable names could be more descriptive here.”

2. Blocking /ˈblɒkɪŋ/ A comment that must be addressed before merging. → “This is a blocking issue — it could cause a race condition in production.”

3. Non-blocking /nɒn ˈblɒkɪŋ/ A suggestion that’s optional or a personal preference. → “Non-blocking, but I prefer early returns to reduce nesting.”

4. Edge case /ɛdʒ keɪs/ An unusual or extreme input/scenario the code might not handle. → “What happens here when the list is empty? That’s an edge case we should cover.”

5. Refactor /ˌriːˈfæktər/ Restructuring existing code without changing its behavior. → “This works, but we should refactor it before it gets harder to maintain.”

6. Trade-off /ˈtreɪd ɒf/ A balance between two competing factors. → “There’s a trade-off here between performance and readability — which matters more in this context?”

7. Idiomatic /ˌɪdiəˈmætɪk/ Code that follows the natural conventions of a language or framework. → “This works, but it’s not very idiomatic C# — let’s use LINQ instead.”

The Code Review Comment Framework

A useful structure I follow is Observation → Impact → Suggestion:

  • Observation: What I see in the code
  • Impact: Why it could matter
  • Suggestion: What I’d recommend instead

For example:

“I see we’re calling the database inside a loop here [observation]. That could cause N+1 query issues at scale [impact]. We could preload the data before the loop instead [suggestion].”

This structure keeps feedback objective and forward-looking.

Tone Spectrum: From Soft to Direct

Different situations call for different tones. Here’s how to calibrate:

Gentle (for junior devs or style preferences):

  • “Just a thought — would it be cleaner to…”
  • “This is totally fine, though I personally lean towards…”

Neutral (standard feedback):

  • “I’d suggest extracting this into a separate method.”
  • “Let’s add a comment here — this logic isn’t obvious.”

Firm (for bugs, security issues, or design problems):

  • “This needs to be addressed before we merge — it could break the production flow.”
  • “We should align this with our existing pattern for consistency.”

🎯 Practice Now

Dialogue 1: Reviewing a junior dev’s PR

You: “Hey, I left a few comments on your PR. Overall it looks good — nice clean structure. There’s one thing I want to flag as blocking: the auth check is missing on this endpoint. That’s a security issue we’d want to fix before merging.”

Junior dev: “Oh, I didn’t realize. Should I add middleware or check inside the handler?”

You: “Good question. Let’s go with middleware — it keeps the handler clean and is consistent with how we do it elsewhere. Take a look at the /orders endpoint as a reference.”

Practice reading this dialogue out loud. Focus on the smooth transitions: “Overall it looks good… There’s one thing I want to flag…”

Dialogue 2: Async code review comment (written)

Write this comment as if in GitHub:

“Non-blocking, but worth a note: this method is doing three things — fetching data, transforming it, and updating the DB. At this complexity level, I’d consider splitting it into smaller private methods. Makes testing a lot easier too. Happy to pair on it if helpful!”

Exercise: Rephrase These Comments

Rewrite these harsh comments into constructive ones:

  1. “This is terrible code.” → Try: “I see a few areas we could improve here…”
  2. “Why did you do it this way?” → Try: “Can you walk me through your reasoning on this approach?”
  3. “This is wrong.” → Try: “I think there might be an issue here when the input is null — let me show you…”

⏱️ 5-Minute Drill

Read this script out loud, then repeat until it feels natural:

“Thanks for the PR. I’ve reviewed it and have a few notes.

First, the happy path looks solid — good job structuring the service layer.

I have one blocking comment: the method ProcessOrder is returning early without logging the failure reason. That’ll make debugging production issues really painful. I’d add a log line before the return.

Two non-blocking suggestions: one, consider using a constant for the timeout value instead of the magic number 30. Two, the variable name x on line 47 — could we make it more descriptive? Maybe retryCount?

Overall, solid work. Once those are addressed, this is good to merge.”

Time yourself. Aim to deliver this in under 90 seconds with natural pacing.

Key Takeaways

  • Use the Observation → Impact → Suggestion structure for clear, constructive comments
  • Label comments as blocking or non-blocking to set clear expectations
  • Match your tone to the situation — firm for critical issues, gentle for style preferences
  • End reviews with something positive — it motivates the developer and keeps trust high

Great code reviews make your team stronger. The language you use shapes the culture — and as a tech lead, that’s one of your most important responsibilities.

Export for reading

Comments