Un ingeniero junior hace code review para encontrar bugs. Un ingeniero pleno hace code review para garantizar que el código funciona, es legible y sigue patrones. Un Staff Engineer hace code review para desarrollar al equipo.

La diferencia es de objetivo, no de rigor. Ese objetivo cambia lo que priorizas en los comentarios, cómo escribes y qué dejas pasar.

Lo que el review de un Staff Engineer no debe ser

Los anti-patterns que debilitan los reviews de seniors:

Nitpicking de estilo: si tienes un linter, deja que el linter se queje. Comentarios como "espaciado aquí" o "prefiero punto y coma" son ruido. Automatiza lo que se puede automatizar, y usa tu tiempo para lo que no.

Reescribir el código en el review: comentarios como "yo lo haría así: [20 líneas de código]" raramente enseñan. Imponen. La persona aprende a convertirse en ti, no a pensar por sí misma.

Aprobar sin leer: el "LGTM" automático no sirve al equipo. Si no tienes tiempo para revisar, dilo. No finjas revisar.

Bloquear por preferencias, no por principios: hay diferencia entre "esto viola nuestro patrón de manejo de errores" (principio con razón documentada) y "prefiero Promises a async/await" (preferencia personal). Los reviews que bloquean por preferencias crean fricción sin valor.

Lo que transfiere conocimiento de verdad

El formato de comentario más eficaz es una pregunta o una explicación con contexto:

// Débil:
// "Usa memoización aquí"

// Fuerte:
// "Este componente se re-renderiza en cada cambio de estado del padre, incluso cuando
// la prop `items` no cambia. useMemo en ese cálculo o React.memo en el componente
// evitaría re-renders innecesarios en listas grandes.
// Referencia interna: lo discutimos cuando teníamos problemas de performance
// en la pantalla de pedidos: issue #847."

La versión fuerte explica por qué, conecta con el impacto y enlaza a contexto histórico. La persona no solo aprende a corregir. Aprende a razonar.

Cómo categorizar los comentarios

Una práctica que reduce malentendidos: dejar explícito el peso de cada comentario.

  • Bloqueante: debe corregirse antes del merge. Seguridad, corrección, violación de contrato de API. Sé específico sobre el riesgo.
  • Sugerencia: recomiendas pero no bloqueas. "Sugiero extraer esto a un helper, sería más testeable, pero entiendo si prefieres dejarlo inline por ahora."
  • Nitpick: opinión sin peso. "Nit: prefiero el nombre `fetchUser` a `getUser` por consistencia, pero no hace falta cambiarlo." El autor sabe que puede ignorarlo.
  • Curiosidad/pregunta: estás aprendiendo, no criticando. "Por qué elegiste Map aquí en lugar de objeto literal? Me da curiosidad entender el razonamiento."

El comentario que pocos escriben: el elogio específico

El code review no es solo sobre problemas. Cuando ves código particularmente bien hecho (una abstracción elegante, un test cuidadoso, una solución simple para un problema complejo), dilo explícitamente:

// "Me gustó mucho este enfoque: usar un discriminated union aquí hace
// imposible representar estado inválido. Voy a usar esta misma idea en el
// módulo de pagos que estoy desarrollando."

Los elogios específicos hacen dos cosas: refuerzan el comportamiento que quieres ver más, y crean un entorno donde el review no es solo un obstáculo para superar.

Reviews asíncronos vs. síncronos

Los comentarios de review escalan mal para discusiones complejas. Si un hilo de comentarios llegó a 4+ respuestas, debería ser una conversación, síncrona o por voice note. Documenta las decisiones de esas conversaciones en el PR.

Para cambios arquitectónicos grandes, haz la revisión antes de que el código sea escrito. Un RFC o design doc que se pueda comentar mientras cambiar es barato.

Lo que un Staff Engineer deja pasar (a propósito)

Parte de la madurez en reviews es saber qué no comentar. Código que no es ideal pero funciona, es mantenible y no viola principios. Déjalo pasar. Tienes contexto que el autor no tiene, pero el autor también tiene contexto que tú no tienes.

No todo PR tiene que resultar en el código que tú habrías escrito. A veces el objetivo es que el equipo entregue, aprenda del proceso y mejore en el próximo. Bloquear PRs con un estándar más alto del necesario es un costo de velocidad que no siempre vale.