Cómo hacer un code review en inglés sin sonar brusco

Acabas de abrir el PR de un compañero, ves un bloque mal montado y lo primero que te sale en inglés es 'this is wrong, change it'. Antes de pulsar enviar, párate: saber cómo hacer un code review en inglés sin sonar a orden seca te va a ahorrar más broncas silenciosas en Slack que cualquier curso de gramática. Aquí tienes el repertorio exacto de frases para que tus comentarios sigan siendo directos sin perder al equipo.

<Callout type="info">**¿Cómo hacer un code review en inglés sin sonar brusco?** Sustituye los imperativos directos ('change this') por preguntas con modal y razón ('could we change this so it handles the empty list?'). Cambia el 'you' señalador por un 'we' colaborativo, etiqueta cada comentario con Conventional Comments (nit, suggestion, issue, question, praise) y añade siempre el porqué técnico detrás del cambio.</Callout>

## Por qué tu primer code review en inglés suena más duro de lo que crees

El problema casi nunca es tu inglés gramatical. Es que traduces palabra por palabra desde un registro español que en su contexto sonaría neutro, y al cruzarlo al inglés pierde todos los amortiguadores que el receptor espera. "Cambia esto" en una review en español es funcional, casi cariñoso entre compañeros. "Change this" en un PR de GitHub leído por alguien de Manchester o Berlín suena a orden seca de jefe enfadado.

El segundo mecanismo es el imperativo sin modalizar. En español usamos imperativos directos sin que nadie se ofenda — "pon esto en una función", "borra ese log". El inglés profesional, en cambio, mete `could`, `might` y `would` por todas partes precisamente para señalar que es una propuesta, no una orden. Saltarse el modal hace que tu comentario suene a ultimátum aunque tú estés siendo amable mentalmente.

El tercero es el más sutil: el `you` señalador frente al `we` colaborativo. "You forgot the null check" es técnicamente correcto y dice exactamente lo que pasó. Pero apunta con el dedo. Cambiarlo a "we'd want to handle the null case here" mueve el problema de "tú metiste la pata" a "esto es algo que el código necesita". Mismo bug, mismo arreglo, cero fricción.

Esta tabla te ahorra el viaje:

| Lo que piensas en español | Traducción literal (suena duro) | Versión natural |
|---|---|---|
| Cambia esto | "Change this" | "Could we change this so it handles the empty list?" |
| Esto está mal | "This is wrong" | "I think this might break when the payload is null" |
| Tienes que validar la entrada | "You have to validate the input" | "We'd want to validate the input before this point" |
| No me gusta este enfoque | "I don't like this" | "I'd push back on this approach because it couples the controller to the DB" |
| Hazlo así | "Do it like this" | "One option would be to extract this into a small helper" |

Si memorizas el patrón "sustituye `you` por `we`, mete un modal, añade el porqué", el 80% de tus reviews ya suenan distintos.

## Conventional Comments: la chuleta que usa medio GitHub

Conventional Comments (conventionalcomments.org) es una convención mínima que resuelve el problema de raíz: en lugar de que cada comentario te haga adivinar si bloquea el merge, te obliga a etiquetarlo. El autor del PR mira la etiqueta y sabe en dos segundos qué hacer con tu feedback.

Las seis etiquetas son `nit`, `suggestion`, `issue`, `question`, `praise` y `thought`. La sintaxis es siempre `**etiqueta:** texto`. Estas son las que vas a usar de verdad:

- `**nit:** missing trailing comma` — comentario trivial, estilo, el autor puede ignorarlo si quiere.
- `**suggestion (non-blocking):** consider extracting this into a helper` — propuesta concreta que mejora algo, pero no bloquea.
- `**issue (blocking):** this throws NPE when payload is null` — esto sí bloquea, hay que arreglarlo.
- `**question:** any reason we're not using the existing UserService here?` — pregunta genuina, no crítica disfrazada.
- `**praise:** clean separation of concerns here, much easier to test now` — un elogio concreto, no un "nice work" genérico.
- `**thought:** wonder if this could be a strategy pattern long term` — idea que se te ocurre pero no pides que se aplique.

Encima de la etiqueta puedes añadir un decorador entre paréntesis: `(blocking)`, `(non-blocking)`, `(if-minor)`. La regla mental es sencilla. Si el comentario tiene que arreglarse antes del merge, va `(blocking)`. Si es una mejora opcional, `(non-blocking)`. `(if-minor)` lo usas cuando dices "si esto es rápido de arreglar, hazlo; si no, mergea y abrimos un ticket".

Así se ve, copiado tal cual, en el textarea de comentario de GitHub:

```text
**suggestion (non-blocking):** consider extracting `validateSignup` into its own
helper — we'd reuse it in the cron that re-runs failed signups.

**issue (blocking):** this swallows `JsonProcessingException`, so the caller
can't tell whether the payload was malformed or the user just didn't exist.

**nit:** rename `data` to `payload` to match the rest of the file.

Lo que ganas con esto es brutal: dejas de pelear con el tono porque la etiqueta hace el trabajo. Un nit: ya te quita el aire de "te estoy regañando" antes de que escribas nada. Un issue (blocking): deja claro que no es opinable, sin que tengas que sonar enfadado.

Plantillas de frases por tipo de comentario

Esto es lo que copias mañana en tu próximo PR. Cuatro categorías, frases reales que funcionan en cualquier equipo internacional.

Sugerencias. Son la mayoría de tus comentarios. La estructura que casi nunca falla es: pregunta abierta + razón. Imagina que el PR contiene este handler:

// signup.controller.js
async function createUser(req, res) {
  if (!req.body.email) return res.status(400).send('Missing email');
  if (!req.body.password) return res.status(400).send('Missing password');
  if (req.body.password.length < 8) return res.status(400).send('Password too short');
  const user = await userService.create(req.body);
  res.json({ id: user.id });
}

Tu comentario sobre las tres validaciones inline:

Otras plantillas que puedes reciclar: "Would it be cleaner to pull this into its own class?", "I'd consider doing X here because Y", "One option would be to invert this conditional and return early".

Bugs y bloqueos. Aquí no hace falta endulzar tanto, pero sí ser específico sobre el caso que rompe. La fórmula es descripción del fallo + cuándo ocurre + cómo arreglarlo (opcional). Imagina este snippet:

function normalizeEmail(user) {
  return user.email.toLowerCase();
}

Tu comentario:

Variantes útiles: "Heads up: this breaks the contract with /api/v2 because that endpoint expects a string, not an array.", "I think we have a race condition here when two requests hit at the same time."

Si el bug merece su propio ticket en JIRA, deja en el PR el issue (blocking) y abre el ticket aparte enlazándolo: "Opened ENG-2143 for this — happy to fix it in this PR or punt it to the next sprint, whichever you prefer." El registro del ticket es el mismo: Steps to reproduce, Expected, Actual, sin envolver.

Preguntas genuinas. El error clásico es disfrazar una crítica de pregunta retórica ("are you sure that's correct?"). No hagas eso — o preguntas de verdad, o haces el comentario directamente como issue o suggestion.

Más opciones: "Help me understand why we're catching this exception at this layer instead of in the service.", "Quick question — does this need to be synchronous?"

Elogios sin sonar pelota. El truco es ser concreto. "Nice work" no aporta nada y suena a relleno. Apunta a algo específico que de verdad te haya llamado la atención.

Otras: "Much cleaner than the previous version, the rename helps a lot.", "praise: the way you isolated the retry logic makes this trivially testable now."

Cómo hacer un code review en inglés sin sonar tajante: el hedging técnico

El registro intermedio entre "haz esto ya" y "perdón por molestar, no estoy seguro pero quizá quizá..." es donde vive el code review profesional. Se construye con tres herramientas: modalizadores, hedges suaves, y saber cuándo no usar ninguno.

Los modalizadores son could, might y would. Cualquiera de ellos transforma una orden en una propuesta:

• "Move this to the service layer" → orden.
• "We could move this to the service layer" → propuesta abierta.
• "This might be cleaner in the service layer" → opinión moderada.
• "I would move this to the service layer" → recomendación personal.

Los hedges suaves son frases tipo I think, I'd consider, what if, wonder if. No son debilidad — son la forma de marcar "esto es mi opinión, abierto a discutir". Úsalos cuando de verdad ves alternativas: "I'd consider returning early here, but I'm curious what you think."

La regla práctica de cuatro niveles para calibrar:

1. "You must change this" — agresivo. Solo en seguridad o producción rota.
2. "You should change this" — correctivo. Funciona si tienes autoridad clara, suena a manual de estilo si no.
3. "Could we change this so it handles X?" — colaborativo. Tu nivel por defecto.
4. "I might be missing context, but should this be X?" — deferente. Cuando dudas o el autor lleva más tiempo que tú en el módulo.

Por defecto, vive en el nivel 3. Sube al 4 cuando no estás seguro o pisas terreno ajeno. El nivel 1 lo reservas para issue (blocking): this leaks the user's API key in logs y casos así, donde el peso del problema justifica el tono.

Cómo responder cuando el feedback te llega a ti

El otro lado del PR es igual de delicado. Sonar agresivo defendiendo tu código quema la review tan rápido como un comentario brusco. Sonar sumiso te acaba pasando factura cuando aceptas cambios que no compartes.

Aceptar el comentario cuando el reviewer tiene razón es lo más fácil, y conviene cerrarlo rápido y sin teatro. Frases que funcionan: "Good point, fixed in 3a4f1c2.", "Agreed, updated.", "You're right, that's cleaner — done."

Defender tu decisión es donde más metemos la pata. La estructura es: reconoce el punto, da tu razón, deja la puerta abierta.

Otras: "I'd actually push back on this — moving it would mean we lose the ability to mock the client in unit tests.", "Considered that, but went with the current approach because of X. Open to changing if you see a problem I'm missing."

Pedir contexto sin disculparte tres veces. Si no entiendes el comentario, pregunta directamente: "Can you elaborate on what you'd prefer here?", "Not sure I follow — could you show an example or link to a similar pattern in the repo?"

Cerrar el hilo cuando ya está resuelto: "Resolving this — happy to reopen if you disagree.", "Marking as done; ping me if I missed something."

Errores que te delatan como hispanohablante en un PR

Hay cinco o seis fallos que cualquier nativo detecta en dos líneas. Quitarlos te hace pasar por dev internacional con soltura.

Falsos amigos. Los dos que más caen en reviews:

• actually no significa "actualmente". Significa "en realidad", "de hecho". "Actually, this method is called from two places" = "De hecho, este método se llama desde dos sitios". Para "actualmente" usa currently.
• eventually no significa "eventualmente". Significa "al final", "tarde o temprano". "This will eventually time out" = "Esto acabará dando timeout". Para "eventualmente / a veces" usa occasionally.

Omitir el sujeto. En español decimos "está mal", "rompe en producción". En inglés el sujeto es obligatorio:

Tercera persona del singular. El clásico que te delata en cinco segundos. this method return null es un comentario que ningún nativo escribiría. Es returns. Igual con the test fail, the service handle, the controller call. Una s cambia la percepción entera.

Sobre-hedging. Lo opuesto al imperativo seco: encadenar tres modales seguidos por miedo a sonar duro. "I think that maybe this could be possibly improved" no es educado, es inseguro. Un modal por frase, opinión clara después.

Se nota especialmente en Slack. Mandas un DM al lead antes de pulsar enviar y te queda algo tipo "hey, sorry to bother, I think maybe there could possibly be an issue with the deploy script but I'm not 100% sure". Eso ya no es educado, es no opinar. La versión sana, mismo registro pero con criterio: "Hey — quick question on the deploy script. The retry block looks like it might swallow the timeout error. Want me to open a PR or check together first?"

Plurales raros. informations, feedbacks, softwares no existen en inglés. Son incontables: "thanks for the feedback", "more information would help".

Cuándo NO aplica este registro

El tono diplomático no es ley universal. Hay contextos donde aplicarlo te hace ruido o te hace perder tiempo.

En equipos pequeños y muy seniors donde todos llevan años trabajando juntos, el registro es más telegráfico. Verás comentarios tipo "wrong, fix" sin que nadie se ofenda, porque hay confianza acumulada y el contexto se da por sentado. Si entras en un equipo así, copia el registro del lead — no traigas tu Conventional Comments completito si nadie lo usa.

En bloqueos de seguridad o de producción, no envuelvas. issue (blocking): this leaks PII in the access log es exactamente lo que toca. Un would we maybe consider ahí suena a que no entiendes la gravedad.

En culturas distintas dentro del propio equipo. La diferencia entre un equipo US-East muy directo y un equipo UK u holandés más indirecto es real. Los americanos te dirán "this is wrong because X" y nadie pestañeará. Los británicos preferirán "I might be wrong, but isn't this slightly off?" para decir lo mismo. Calibra leyendo cómo escriben los demás antes de imponer tu estilo.

La regla final sobre cómo hacer un code review en inglés sin pasarte: empieza diplomático por defecto, baja el registro cuando el equipo lo pida. Subirlo después es más fácil que quitarte la fama de seco.

Preguntas frecuentes

¿Cómo digo 'esto está mal' sin sonar grosero? Cambia "está mal" por "describe el fallo concreto". En lugar de "this is wrong", escribe "this will break when the user has no email" o "I think this misses the case where the list is empty". El comentario sigue siendo una crítica, pero ahora se lee como técnica, no como ataque personal.

¿Qué significa 'nit' en un comentario de PR? nit viene de nitpick: comentario trivial, normalmente de estilo o formato, que el autor del PR puede ignorar sin consecuencias. "nit: missing trailing comma" o "nit: maybe rename data to payload". Usarlo te ahorra discusiones largas sobre cosas que no merecen frenar el merge.

¿Está mal usar 'you should'? No está mal, pero por defecto suena a profesor corrigiendo deberes. we could, could we, o we'd want to son más colaborativos y mantienen exactamente el mismo significado técnico. Reserva you should para cuando hay un patrón claro del equipo que el autor se está saltando, y aún así suaviza con you might want to.

¿Qué hago si no entiendo el feedback que me han dejado? Pide contexto sin disculparte tres veces. "Could you point me to an example in the codebase?" o "Not sure I follow — what would the ideal version look like?" funcionan perfectamente. Mostrar que quieres entender es siempre mejor que asumir e implementar mal.

¿Cómo elogio sin sonar pelota? Concreto y específico. "praise: the way you isolated the retry logic makes this much easier to test" tiene peso. "Nice work!" suena a relleno. Si te cuesta encontrar algo concreto, probablemente no toca elogio.

<ProductCTA variant="prominent">
¿Quieres practicar esto con un tutor IA? Empieza gratis en DevLingo.
</ProductCTA>