English for developers: 1-on-1s and code reviews
How to Give Feedback in English (Without Sounding Harsh or Vague)
October 21, 2026
The language senior engineers use to give direct, useful feedback in English, in 1-on-1s and after a code review, without it landing as an attack.
Key Takeaways
- Use situation, behavior, impact: what happened, what the person did, what it affected. It stays specific instead of vague or personal.
- 'Good job' alone gives nothing to repeat. Name the specific thing that was good.
- Critical feedback on a pattern or habit usually belongs in a 1-on-1, not a PR comment, since tone reads more clearly out loud.
- Propose an alternative instead of only judging the decision that was made: 'have you considered ____?' beats 'that was wrong'.
- A short check-in ('does that land okay?') closes the gap between technically correct feedback and feedback that actually landed well.
If you want to know how to ask for feedback from your manager, see our guide on 1-on-1s. This one is about the other half: giving it, as a senior engineer or tech lead to a report or a peer.
Giving feedback in a second language tends to land in one of two wrong places. Either it comes out too vague to actually change anything ('maybe try to communicate a bit more'), or it comes out so blunt it reads as rude ('this code is bad'). The fix is not softer or harder language, it's more specific language: naming the exact situation, the exact behavior, and the exact impact.
The situation, behavior, impact framework
El formato situación, comportamiento, impacto
This is the structure behind every piece of feedback in this guide: describe the situation (when and where), the behavior (what the person did, as an observable fact, not a character judgment), and the impact (what it affected).
Example: 'In yesterday's standup' (situation), 'you said the ticket was done without mentioning the PR was still waiting on review' (behavior), 'which made the team think it had already shipped' (impact). This stays specific and avoids 'you never communicate clearly', which is a judgment about the person, not a fact about what happened.
7 rewrites: vague or blunt to direct and specific
7 reescrituras: de vago o duro a directo y específico
Instead of
"You need to communicate better."
Say
"In yesterday's standup, you said the ticket was done without mentioning the PR was still waiting on review. Next time, flagging what's still pending would help the team plan around it."
Why it works: Names the specific situation instead of a general character trait.
Instead of
"This code is a mess."
Say
"This function is doing five different things, which makes it hard to test. Would it help to split out the validation logic into its own function?"
Why it works: Talks about the code, not the person, and ends with a question instead of a verdict.
Instead of
"Good job."
Say
"Good job handling the migration rollback. That was a tricky edge case and you caught it before it hit production."
Why it works: Names what exactly was good. 'Good job' alone gives the person nothing to repeat.
Instead of
"You're too slow."
Say
"I've noticed the last two tickets took longer than estimated. Is there something blocking you that we should talk about?"
Why it works: States the observation, then asks instead of assumes. Often there's a real blocker behind it.
Instead of
"Why didn't you ask for help?"
Say
"Next time you're stuck for more than an hour, feel free to ping me. I'd rather you ask early than lose a day."
Why it works: A forward-looking offer lands better than a backward-looking 'why didn't you'.
Instead of
"That was a bad decision."
Say
"I think there was a simpler approach here using the existing cache layer. Can I walk you through it?"
Why it works: Proposes an alternative instead of only judging the one that was made.
Instead of
"You always interrupt people in meetings."
Say
"In today's planning meeting, I noticed a couple of times where a teammate got cut off mid-sentence. Could you try leaving a beat before jumping in?"
Why it works: 'Always' invites denial. A specific instance from today is harder to argue with and easier to act on.
Giving positive feedback that isn't hollow
Dar feedback positivo que no suene vacío
'Good job' or 'nice work' alone tells someone nothing about what to repeat. Naming the specific behavior turns praise into something they can do again on purpose.
- "That was a clean fix for a tricky bug. I liked how you added a regression test for it."
- "Your PR description made this really easy to review. More of that, please."
- "You handled that production incident calmly, and the postmortem was thorough."
- "I appreciated that you flagged the risk early instead of waiting until the deadline."
Giving critical feedback on a peer's code or approach
Dar feedback crítico sobre el código o el enfoque de un colega
This is for spoken feedback in a 1-on-1 or a pairing session, not a PR comment. See our guide on code review comments for the written version.
- "I want to flag something about the approach on ____ before you go further: ____."
- "Have you considered ____? I think it might be simpler."
- "I'm not sure this will scale once we have ____. Can we think through that together?"
- "This works, but I'd push back gently on the pattern. Here's why: ____."
Checking it landed well
Confirmar que el mensaje se entendió bien
Feedback that is technically correct can still land badly if the other person walks away unsure whether you're upset with them. A short check-in at the end closes that gap.
- "How does that feel to hear?"
- "Does that land okay?"
- "I want to make sure this came across as feedback on the approach, not on you."
- "What's your take on that?"
Related articles
Ready to practice your English at work?
Lingua-e has interactive exercises built around real developer conversations: standups, code reviews, retrospectives, and more. Practice until it comes naturally.
Try Lingua-e for free
Written by
Roxana LafuenteLingua-e's founder
Roxana Lafuente is a software engineer with 8+ years of experience. At the beginning of her career, even though she had already passed the First Certificate in English, she still froze every time she had to speak up in the daily standup. That was a gap nobody was fixing. After 2,000+ standups, she figured out what actually builds fluency: practice that looks like your real work. She built Lingua-e so other developers wouldn't have to take the long road to feel confident working in an international development environment.