“Arreglar pequeños bugs se siente como reorganizar sillas en el Titanic”

Arreglas el bug, pero el sistema aún se siente rotoEncuentras una inconsistencia en nombres, un caso de error faltante, un bucle que podría ser más eficiente. Lo arreglas en cuarenta minutos y abres un PR. Pero mientras esperas revisión, algo susurra que este parche casi no cambia nada. La arquitectura aún cruje. La base de datos aún no tiene índices en las columnas más consultadas. La capa de autenticación aún copia secretos en los registros. Estás reorganizando sillas mientras el barco se hunde. Así que cierras el PR, y esos cuarenta minutos quedan en tu cabeza como movimiento desperdiciado.

Las mejoras pequeñas se sienten como complicidad con el naufragioEl sistema heredado tiene problemas visibles y sistémicos. Y cuando solo arreglas bugs pequeños, parece que aceptas el desastre. Otros ingenieros señalan la arquitectura y preguntan por qué no la arreglas. Defiendes el diseño actual porque admitir que está roto se siente como admitir que debería haberlo reescrito hace semanas. El arreglo pequeño se convierte en evidencia de que no haces lo suficiente, y hacer cualquier cosa más pequeña que una reconstrucción completa empieza a sentirse como permitir la degradación. Así que apuntas a la gran reescritura en cambio—y los pequeños bugs nunca se arreglan.

Una corrección quirúrgica prueba que entiendes la diferenciaElige un pequeño bug que no tenga dependencias arquitectónicas. Arréglalo completamente. Escribe una prueba. Envía el PR sin mencionar el estado más amplio del sistema. El punto no es que este arreglo sea suficiente; es establecer en código y en tu propio pensamiento que puedes distinguir entre una mejora quirúrgica y una fantasía de reescritura. Durante tres meses, diez arreglos así se acumulan. No es el barco siendo salvado; es evidencia de que entiendes qué es tuyo y qué no.