Inglés para developers: 1-1s y code reviews
Cómo dar feedback en inglés (sin sonar duro ni vago)
21 de octubre de 2026
El lenguaje que usan los engineers senior para dar feedback directo y útil en inglés, en 1-1s y después de un code review, sin que se sienta como un ataque.
Puntos clave
- Usa situación, comportamiento, impacto: qué pasó, qué hizo la persona, a qué afectó. Se mantiene específico en lugar de vago o personal.
- 'Good job' solo no da nada para repetir. Nombra lo específico que estuvo bien.
- El feedback crítico sobre un patrón o un hábito suele ir mejor en una 1-1 que en un comentario de PR, porque el tono se lee con más claridad en voz alta.
- Propone una alternativa en lugar de solo juzgar la decisión tomada: 'have you considered ____?' funciona mejor que 'that was wrong'.
- Un chequeo corto ('does that land okay?') cierra la brecha entre un feedback técnicamente correcto y uno que realmente se entendió bien.
Si quieres saber cómo pedir feedback a tu manager, mira nuestra guía de 1-1s. Esta es la otra mitad: darlo, como engineer senior o tech lead, a un report o a un colega.
Dar feedback en un segundo idioma suele caer en uno de dos extremos equivocados. O sale demasiado vago como para cambiar algo ('maybe try to communicate a bit more'), o sale tan directo que suena grosero ('this code is bad'). La solución no es un lenguaje más suave ni más duro, es un lenguaje más específico: nombrar la situación exacta, el comportamiento exacto y el impacto exacto.
El formato situación, comportamiento, impacto
The situation, behavior, impact framework
Esta es la estructura detrás de cada feedback en esta guía: describe la situación (cuándo y dónde), el comportamiento (qué hizo la persona, como un hecho observable, no un juicio de carácter) y el impacto (a qué afectó).
Ejemplo: 'In yesterday's standup' (situación), 'you said the ticket was done without mentioning the PR was still waiting on review' (comportamiento), 'which made the team think it had already shipped' (impacto). Esto se mantiene específico y evita 'you never communicate clearly', que es un juicio sobre la persona, no un hecho sobre lo que pasó.
7 reescrituras: de vago o duro a directo y específico
7 rewrites: vague or blunt to direct and specific
En lugar de
"You need to communicate better."
Di
"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."
Por qué funciona: Nombra la situación específica en lugar de un rasgo de carácter general.
En lugar de
"This code is a mess."
Di
"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?"
Por qué funciona: Habla del código, no de la persona, y termina con una pregunta en lugar de un veredicto.
En lugar de
"Good job."
Di
"Good job handling the migration rollback. That was a tricky edge case and you caught it before it hit production."
Por qué funciona: Nombra exactamente qué estuvo bien. 'Good job' solo no le da a la persona nada que repetir.
En lugar de
"You're too slow."
Di
"I've noticed the last two tickets took longer than estimated. Is there something blocking you that we should talk about?"
Por qué funciona: Plantea la observación y después pregunta, en vez de asumir. Muchas veces hay un bloqueo real detrás.
En lugar de
"Why didn't you ask for help?"
Di
"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."
Por qué funciona: Un ofrecimiento hacia adelante funciona mejor que un 'por qué no' hacia atrás.
En lugar de
"That was a bad decision."
Di
"I think there was a simpler approach here using the existing cache layer. Can I walk you through it?"
Por qué funciona: Propone una alternativa en lugar de solo juzgar la decisión que se tomó.
En lugar de
"You always interrupt people in meetings."
Di
"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?"
Por qué funciona: 'Siempre' invita a la negación. Un caso específico de hoy es más difícil de refutar y más fácil de corregir.
Dar feedback positivo que no suene vacío
Giving positive feedback that isn't hollow
'Good job' o 'nice work' solos no le dicen a nadie qué repetir. Nombrar el comportamiento específico convierte el elogio en algo que la persona puede volver a hacer a propósito.
- "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."
Dar feedback crítico sobre el código o el enfoque de un colega
Giving critical feedback on a peer's code or approach
Esto es para feedback hablado en una 1-1 o una sesión de pairing, no para un comentario en un PR. Mira nuestra guía de comentarios en code reviews para la versión escrita.
- "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: ____."
Confirmar que el mensaje se entendió bien
Checking it landed well
Un feedback técnicamente correcto igual puede caer mal si la otra persona se queda sin saber si estás molesto con ella. Un chequeo corto al final cierra esa brecha.
- "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?"
Artículos relacionados
¿Listo para practicar tu inglés en el trabajo?
Lingua-e tiene ejercicios interactivos basados en conversaciones reales de developers: standups, code reviews, retrospectivas y más. Practica hasta que salga solo.
Prueba Lingua-e gratis
Escrito por
Roxana LafuenteFundadora de Lingua-e
Roxana Lafuente es ingeniera de software con más de 8 años de experiencia. Al comienzo de su carrera, aunque ya había aprobado el First Certificate in English, se bloqueaba cada vez que tenía que hablar en el standup diario. Era un problema que nadie estaba resolviendo. Después de más de 2.000 standups, descubrió qué es lo que realmente construye la fluidez: practicar situaciones que se parecen a tu trabajo real. Creó Lingua-e para que otros developers no tuvieran que tomar el camino largo para sentirse seguros trabajando en un entorno de desarrollo internacional.