Tu siguiente PR puede esperar. Las de tus compañeros no.

Hay mañanas en las que abro el editor con una idea muy clara: quiero avanzar con mi tarea. Tengo el contexto fresco, sé qué pantalla tengo que tocar, qué bug quiero cerrar o qué parte de la feature me toca terminar. Y justo antes de ponerme, miro Slack, GitHub o el canal de reviews y veo dos o tres pull requests esperando.

Mi primer impulso suele ser seguir con lo mío.

No porque no quiera ayudar. Simplemente porque escribir código se siente como progreso. Es visible. Al final del día puedes decir: he avanzado en esta feature, he abierto esta PR, he cerrado esta tarea. Revisar una PR es diferente. Parece una interrupción, algo que haces entre bloques de trabajo, casi como si fuera una tarea secundaria.

Por día que pasa estoy más convencido de que esa intuición es peligrosa.

Una PR esperando review es trabajo parado

Una pull request abierta no es trabajo terminado. Es trabajo pausado.

Puede que el código esté escrito, los tests pasen y la descripción esté clara, pero mientras nadie la revise, esa pieza sigue sin entrar en el producto. Y, en muchos casos, la persona que la abrió no está completamente desbloqueada.

A veces está esperando feedback para continuar con la siguiente parte. A veces necesita que esa PR se mergee para no seguir trabajando encima de una rama que cambia cada día. A veces tiene dudas reales sobre una decisión técnica y necesita que otra persona mire el contexto.

Desde fuera parece una PR más en la lista. Para quien la abrió, puede ser el punto exacto donde su trabajo se ha quedado parado.

Y aquí está el problema: si yo ignoro esa PR y abro otra, quizá mi sensación individual de productividad sube, pero el sistema se atasca un poco más.

Crear otra PR no siempre ayuda al equipo

Durante mucho tiempo asocié productividad con crear trabajo nuevo. Si avanzaba en mi tarea, bien. Si abría una PR, mejor. Si tenía varias cosas en paralelo, mejor todavía.

Pero un equipo no entrega software por el número de ramas abiertas. Entrega software cuando el trabajo se revisa, se integra, se prueba y llega a producción.

Si ya hay cinco PRs esperando review y yo abro la sexta, he añadido más trabajo al flujo, pero no necesariamente he ayudado a que el equipo entregue antes. Puede que haya hecho justo lo contrario: aumentar la cola.

Esto hoy es más importante si cabe.

Con el uso intensivo de IA, el ritmo al que podemos generar código ha aumentado muchísimo. Es más fácil explorar una solución, montar una primera versión, refactorizar una parte del sistema o abrir una PR con cambios que antes habrían tardado bastante más. Eso tiene cosas muy positivas, pero también cambia el cuello de botella.

Si antes el límite estaba muchas veces en escribir el código, ahora puede estar en revisarlo bien. La IA puede ayudar a producir más rápido, pero no elimina la responsabilidad de entender qué estamos metiendo en el producto. Al contrario: si el volumen de PRs sube, la calidad y la velocidad de las reviews importan todavía más.

Porque una cosa es generar cambios y otra muy distinta es integrarlos con criterio.

Esto se ve mucho en equipos donde todo el mundo está ocupado, pero las cosas tardan demasiado en cerrarse. Hay muchas ramas activas, muchas tareas casi terminadas, muchas PRs “a falta de review”. El tablero parece lleno de progreso, pero el producto no avanza al mismo ritmo.

Ahí es donde revisar deja de ser un favor y empieza a ser una responsabilidad de equipo.

Revisar también es trabajo de ingeniería

Una buena review no es mirar por encima y poner un approve para quitarse algo de encima. Tampoco es buscar detalles pequeños para demostrar que has leído el código.

Revisar bien es trabajo técnico.

Es comprobar que la solución encaja con el problema. Que el código se entiende. Que no estamos metiendo deuda técnica innecesaria. Que los tests cubren el nuevo código. Que no hay un edge-cases evidentes. Que la persona que ha escrito la PR no se ha quedado sola tomando una decisión que afecta al resto.

También es una forma de compartir contexto. Muchas veces he entendido mejor una parte del producto revisando la PR de otra persona que leyendo documentación. Y también he detectado decisiones que yo habría tomado igual de mal si estuviera trabajando en esa tarea.

Eso tiene valor. Aunque no genere una nueva rama con mi nombre.

El coste de llegar tarde

Lo peor de una review lenta no es solo que se retrase el merge. Es que se pierde contexto.

Si revisas una PR diez minutos después de que alguien la abra, la conversación está viva. La persona recuerda por qué tomó cada decisión. Puede responder rápido. Si hay que cambiar algo, el coste mental es pequeño.

Si la revisas tres días después, todo pesa más. La rama puede estar desactualizada. La persona ya ha cambiado de tarea. El feedback llega tarde. Un comentario que habría sido útil al principio ahora obliga a reabrir contexto, rehacer partes o negociar con el calendario.

El mismo comentario técnico puede ser barato o caro dependiendo de cuándo llega.

Por eso creo que el tiempo de review importa más de lo que solemos admitir. No como métrica para presionar a nadie, sino como señal de salud del equipo. Si las PRs se quedan esperando constantemente, algo en el flujo está roto.

Lo que intento hacer ahora

No siempre lo consigo, pero intento tener una regla simple: antes de empezar un bloque largo de trabajo, miro si hay PRs esperando review.

Si hay una PR pequeña que puedo revisar en diez o quince minutos, la reviso. Si hay una PR que bloquea a alguien, le doy prioridad. Si no puedo revisarla porque no tengo contexto o estoy metido en algo urgente, lo digo. Un “no puedo hasta mañana” ayuda más que el silencio.

También intento no usar mi propia carga de trabajo como excusa automática. Todos tenemos trabajo. Precisamente por eso necesitamos que el flujo no se atasque. Hoy reviso yo tu PR. Mañana tú revisas la mía. No como intercambio de favores, sino porque el equipo necesita cerrar trabajo, no acumularlo.

Hay una diferencia importante entre estar ocupado y estar ayudando a que el equipo avance.

Un criterio práctico

Cuando tengo dudas, me hago una pregunta muy simple:

¿Qué desbloquea más al equipo ahora mismo: una hora más de mi tarea o revisar esta PR?

A veces la respuesta será seguir con mi tarea. Si hay una entrega crítica, si la PR no es urgente o si realmente no soy la persona adecuada para revisarla, tiene sentido priorizar mi trabajo.

Pero muchas veces la respuesta es revisar.

Porque una review de treinta minutos puede desbloquear varias horas de trabajo de otra persona. Porque puede evitar que una rama se pudra. Porque puede cerrar una conversación técnica antes de que se convierta en problema. Porque puede hacer que el equipo entregue hoy algo que, de otra forma, se quedaría esperando hasta mañana.

No se trata de dejar de hacer tu trabajo para hacer el de los demás. Se trata de entender que, en un equipo, desbloquear también es avanzar.

Y a veces, la mejor forma de avanzar no es abrir otra PR.

Es revisar la que ya está esperando.