Hace un tiempo, en uno de mis primeros proyectos serios como desarrollador por cuenta ajena (es decir, trabajando en una consultora), me encontré con algo que seguramente te suene:
Un proyecto con bastantes horas de desarrollo ya detrás.
Con código difícil de leer, funciones enormes, duplicidad por todos lados y… una sensación constante de que todo estaba hecho un desastre.
Mi reacción fue inmediata.
No pasa nada. Esto lo arreglo yo en un par de días.
Spoiler: no lo arreglé. Lo rompí.
El impulso de querer rehacerlo todo
Cuando empiezas en programación, hay un momento en el que empiezas a ver lo que está mal.
Y eso es buena señal, ya que significa que estás creciendo.
El problema es lo que haces con esa información, porque lo más habitual es caer en la trampa de que la solución es rehacerlo todo desde cero.
Es un error muy de junior, vemos el código, vemos un desastre y empezamos a pensar en cambiar nombres, mover archivos, reestructurar carpetas, aplicar patrones de diseño..
Y ya que estás… “dejarlo bien de una vez”.
El famoso big bang.
Un cambio enorme que, en tu cabeza, va a solucionar todos los problemas.
Lo que no ves cuando haces un “big bang”
El problema de estos cambios no es la intención, es el impacto.
Cuando cambias demasiadas cosas a la vez:
No sabes qué ha roto qué.
No puedes probar bien cada parte.
El código se vuelve difícil de revisar.
Y el equipo pierde confianza en ese cambio.
Y aquí hay algo importante que muchos juniors no entienden al principio:
El problema no es solo que el código funcione, es que otros puedan confiar en él Porque en un entorno profesional, si tu cambio genera dudas… es un mal cambio.
La primera vez que entendí esto
Recuerdo perfectamente la primera vez que alguien me paró los pies con esto.
Abrí un Pull Request enorme.
De esos que te hacen sentir orgulloso ya que había “arreglado” medio módulo.
Al rato, un compañero más senior comentó algo que se me quedó grabado:
Esto no se puede revisar.
Ni siquiera entró a discutir si estaba bien o mal. Simplemente no era viable ya que era demasiado grande, demasiado arriesgado y demasiado difícil de entender.
Y ahí entendí algo que no te enseñan en cursos:
No todo lo que mejora el código… mejora el proyecto.
Cómo trabajan los seniors de verdad
Con el tiempo, empecé a fijarme en cómo trabajaban desarrolladores con experiencia.
Y me di cuenta de algo que al principio parecía contraintuitivo:
No hacían grandes cambios.
Hacían cambios pequeños, muy pequeños.
Igual parece que te lo estoy exagerando pero veía cambios de simplemente un nombre de variable, na función extraída.
De eliminar una duplicidad concreta o simplemente añadir un test unitario.
Nada espectacular.
Pero cada cambio tenía algo en común:
Era fácil de entender, era fácil de probar y era fácil de revertir.
Y eso lo cambiaba todo.
El poder de los pequeños pasos
Aquí está la clave:
Los sistemas complejos no se arreglan con grandes revoluciones Se arreglan con pequeñas mejoras constantes.
Cada pequeño cambio reduce un poco la complejidad y cada mejora deja el código un poco más limpio.
Cada refactor pequeño prepara el siguiente.
Y lo más importante:
No rompes todo en el proceso.
Refactorizar no es rehacer
Hay una diferencia enorme que me hubiera gustado entender antes:
Rehacer es destruir y volver a construir.
Refactorizar es mejorar sin cambiar el comportamiento.
Y eso, en la práctica, se hace así:
-
Tocas una parte del código.
-
La mejoras un poco.
-
Validas que todo sigue funcionando igual.
No hace falta más, no necesitas arreglar todo el sistema.
Sólo necesitas dejar mejor lo que has tocado.
Por qué los seniors no hacen “big bangs”
Porque entienden algo clave:
En programación, el riesgo importa más que la intención.
Los seniors no buscan hacerlo perfecto a la primera, sino que buscan avanzar sin romper.
Por eso trabajan en pasos pequeños.
Porque así pueden equivocarse sin consecuencias graves y eso les permite avanzar más rápido a largo plazo.
Si estás empezando, quédate con esto:
No necesitas rehacer proyectos enteros para crecer como programador.
De hecho, muchas veces eso es lo que más te frena.
Aprende a mejorar poco a poco. A hacer cambios pequeños. A dejar el código un poco mejor de lo que lo encontraste.
Porque la diferencia entre un junior y un senior no está en hacer grandes cambios.
Está en saber dar el siguiente paso correcto.
Nos vemos en la próxima.
Julián.
Publicado originalmente en CERO a SENIOR.