Cuando trabajamos en repositorios compartidos, siempre llega ese momento obligatorio: revisar código ajeno antes de aprobar una pull request (PR).
En esos momentos se nota mucho cómo reaccionamos cada uno. Algunos revisan el código rápidamente, otros se detienen más. No suele haber alguien específico encargado de mejorar continuamente el código, así que cada persona decide cómo actuar.
Según mi experiencia, podemos distinguir cuatro tipos de personas según cómo gestionan esta situación:
Grupo 1 🙄
La mayoría revisa la PR superficialmente, aprueba el código si cumple con los requisitos más básicos y pasa a otra tarea, ignorando pequeños problemas o posibles mejoras. Es decir, cumplen sus objetivos pero dejan deuda técnica acumulada que en el futuro alguien tendrá que resolver.
Grupo 2 🫥
Revisan el código, aprueban la PR y de vez en cuando realizan pequeños ajustes o sugerencias para evitar que el código empeore. Van un paso más allá para garantizar que el sistema no quede peor de lo que lo encontraron.
Grupo 3 🙃
Un grupo más pequeño aprovecha la PR para arreglar problemas técnicos, pero solo cuando estos bloquean o afectan directamente su propio trabajo o futuras tareas inmediatas.
Grupo 4 🤩
Un reducido grupo de developers utiliza activamente cada PR para mejorar proactivamente la calidad global del código, refactorizando o sugiriendo mejoras incluso cuando no son estrictamente necesarias para su trabajo a corto plazo o cuando no les afectan directamente.
¿Qué impacto tienes como desarrollador?
La calidad de nuestro trabajo no solo se mide en el código que escribimos, sino en nuestra capacidad de ver más allá de las tareas inmediatas. La “métrica de la PR” es una herramienta útil para autoevaluar nuestro impacto real en el equipo y el proyecto:
¿En qué grupo estás?
-
Grupo 1: (por debajo de las expectativas): cumple únicamente con sus tareas inmediatas, dejando deuda técnica acumulada.
-
Grupo 2: (cumple expectativas): realiza sus tareas asegurándose de no empeorar el código existente.
-
Grupo 3: (cumple expectativas): mejora el código, pero solo cuando le afecta directamente.
-
Grupo 4: (supera expectativas): busca activamente mejorar el sistema para beneficio colectivo, incluso cuando no es directamente su responsabilidad o beneficio inmediato.
Ahora pregúntate con sinceridad:
¿En qué grupo encajo yo?
👇 Déjame un comentario y cuéntame con qué grupo te identificas.
