Lo abres y se te cae el estómago. Cuarenta y siete archivos cambiados. Dos mil líneas agregadas. La descripción dice "arregla lo que hablamos". Sin contexto de qué se probó y se descartó, sin mención de qué mirar primero, solo una pared de diffs y la expectativa implícita de que lo apruebes porque revisarlo en serio te va a comer la tarde entera.
Ese pull request te dice todo sobre la persona que lo abrió, y nada de eso tiene que ver con su capacidad para escribir código. Tiene que ver con si entiende que un pull request no es un depósito de trabajo terminado. Es un pedido de atención y de criterio ajeno, y tratarlo como un trámite después del "trabajo de verdad" es una de las señales más claras de en qué punto de su carrera está alguien realmente, sin importar cuántos años figuren en su currículum.
El código nunca fue la parte difícil
Acá va una verdad incómoda para quien cree que escribir código correcto es el techo de la seniority: el código adentro de la mayoría de los pull requests está bien. Compila, pasa los tests, probablemente hace lo que tiene que hacer. Lo que separa el pull request de un ingeniero senior del resto no es la corrección. Es si le hizo posible el trabajo a quien lo revisa.
Un ingeniero junior optimiza para terminar la tarea. Un ingeniero senior optimiza para el costo total del cambio, y ese costo incluye cada minuto que otra persona gasta tratando de entender qué pasó y por qué. Ese cambio, de "esto ya está" a "alguien más puede aprobar esto de forma segura en un tiempo razonable", es uno de los marcadores reales de seniority, y casi nunca se nombra directamente porque no es una habilidad que nadie pone en un currículum.
El scope es la primera señal
La señal más grande en cualquier pull request es si hace una sola cosa. No un solo commit, una sola cosa. Un ingeniero senior que se da cuenta a mitad de un fix de que el código alrededor necesita limpieza casi siempre va a abrir un segundo pull request para esa limpieza, aunque sea más trámite, porque mezclar un cambio de comportamiento real con refactoring no relacionado hace que ambos sean más difíciles de revisar e imposibles de revertir de forma independiente si algo se rompe.
El instinto de meter todo en un solo pull request porque "ya estaba ahí adentro" es entendible y casi siempre equivocado. Optimiza para quien escribe el código, que tiene todo el contexto en la cabeza en este momento, a costa directa de quien lo revisa, que tiene que reconstruir ese contexto desde cero y ahora tiene que sostener dos cambios no relacionados en la cabeza al mismo tiempo para evaluar cualquiera de los dos correctamente.
La descripción hace trabajo real, o no lo hace
La mayoría de las descripciones de pull requests repiten el diff en prosa. "Este PR agrega una capa de cache al servicio de usuarios." El reviewer ya sabe eso, está mirando el código. Una descripción que realmente sirve responde preguntas que el diff no puede responder: por qué ahora, qué alternativa se consideró y se descartó, qué es riesgoso de este cambio en particular, y en qué debería enfocar el reviewer su atención limitada.
Ese último punto importa más de lo que la gente reconoce. Decirle a un reviewer "la lógica de reintentos en el tercer archivo es la parte de la que estoy menos seguro" no es admitir debilidad. Es respetar su tiempo, apuntándolo hacia donde más se necesita, en vez de obligarlo a aplicar el mismo nivel de escrutinio a trescientas líneas cuando doscientas ochenta son mecánicas.
El historial de commits es una herramienta de comunicación, no un diario
Un historial de commits que dice "wip", "fix", "fix de verdad", "saco el console.log" es un diario privado de cómo pasó el trabajo, y debería quedarse privado, aplastado o limpio antes de llegar a un reviewer. Borrar ese historial no es deshonesto. Nunca fue pensado para nadie más que quien lo escribió.
Un historial de commits que se lee como una secuencia de pasos intencionales y revisables (extraer la interfaz, implementar el proveedor nuevo, conectarlo a los puntos de llamada existentes, sacar el proveedor viejo) hace algo que un diff solo no puede: le permite a un reviewer aprobar el cambio en el orden en que tiene sentido lógico, y encontrar un problema en el paso dos sin necesitar entender todavía el paso cuatro. Esa estructura requiere esfuerzo deliberado después de hecho el trabajo, y saltearse ese esfuerzo es una de las formas más comunes en que trabajo de nivel senior se lee como junior en la revisión.
Lo que realmente cuesta una buena cultura de revisión
Nada de esto funciona a menos que el equipo trate el tiempo de revisión como trabajo real, no como algo que se aprieta entre reuniones. Si se espera que los reviewers aprueben cosas en minutos entre otras obligaciones, los ingenieros van a aprender, correctamente, que un pull request más chico y más prolijo no se revisa más rápido que uno enorme y desordenado, porque nadie tiene tiempo de leer ninguno de los dos con cuidado. En ese entorno, el incentivo para armar un pull request limpio, acotado y bien descrito desaparece en silencio, sin importar cuántos posts haya leído el equipo sobre el tema.
Arreglar esto no pasa por escribir una mejor plantilla de pull request. Pasa por que el equipo acuerde explícitamente que la revisión es trabajo agendado con tiempo real asignado, no algo que se mete en los huecos de un calendario ya lleno de reuniones. Los equipos que protegen ese tiempo de revisión ven mejorar la calidad de los pull requests por sí sola, porque los ingenieros dejan de asumir que armar bien el contexto es esfuerzo perdido que nadie va a leer.
El argumento de tamaño que nadie quiere tener en voz alta
Todo equipo tiene una tolerancia no oficial al tamaño de un pull request que todos aceptan en silencio y nadie escribe en ningún lado. Esa tolerancia normalmente la fija el pull request más grande que se aprobó sin objeciones últimamente, y solo se mueve en una dirección: hacia arriba. Una vez que un pull request de quinientas líneas pasa sin objeciones porque esa semana todos estaban ocupados, uno de trescientas líneas deja de verse grande en comparación, y la base de referencia de todo el equipo se corre sin que nadie lo haya decidido.
La solución no es un límite de líneas fijo en un linter, porque el tamaño correcto depende por completo de qué hace el cambio. Un pull request de trescientas líneas que agrega una sola función bien testeada con código repetitivo alrededor puede ser trivial de revisar. Uno de cuarenta líneas que toca supuestos compartidos de cinco módulos distintos puede llevar una hora revisarlo bien. El tamaño en líneas es, en el mejor de los casos, una aproximación burda. La pregunta real es cuántas cosas independientes tiene que sostener un reviewer en la cabeza al mismo tiempo, y ese número casi siempre debería ser uno.
El lado del reviewer en este trato
Nada de esto es una obligación de un solo lado. Un reviewer que deja un "se ve bien" en un pull request de cuarenta archivos sin haberlo leído no está siendo eficiente, está pasando el riesgo río abajo a quien encuentre el bug en producción tres semanas después. Y un reviewer que se pone a corregir nombres de variables en un pull request que nunca debió tener este tamaño está resolviendo el problema equivocado: el problema era el scope, no los nombres, y ningún comentario sobre nombres arregla eso.
Un buen reviewer pide dividir el pull request antes de meterse en comentarios de línea cuando está tratando de hacer demasiado a la vez. Ese hábito, cuestionar el scope antes de revisar el contenido, hace más por la calidad del código de un equipo a lo largo de un año que cualquier cantidad de comentarios cuidadosos línea por línea sobre pull requests que nunca debieron existir con esa forma.
La postura
Nadie asciende a senior por escribir un pull request que otro puede revisar en cinco minutos en vez de cincuenta. Pero esa habilidad, tratar un pull request como una pieza de comunicación dirigida a la atención limitada de otra persona en vez de un depósito de trabajo terminado, es una de las señales más confiables de en qué punto de su carrera está alguien realmente. No aparece en un título. Aparece cada vez que abres su diff.
