Conoces la escena: entras a un proyecto nuevo, abres el repo y te encuentras con un monstruo. Miles de líneas sin tests, sin documentación y sin una sola persona que recuerde por qué algo está ahí. Respira. Tomas Vukasovic armó un manual de supervivencia justo para ese momento.
Las primeras semanas: observar antes de tocar
El instinto dice “arreglemos todo ya”. Mala idea. Como en esa escena de Indiana Jones donde mover la piedra equivocada activa todas las trampas, tocar un código que no entiendes puede desatar el caos. Tom propone lo contrario: las primeras semanas son para leer, mapear y entender, no para refactorizar a lo loco.
Cómo aportar valor sin volverte loco
La clave es ganarse confianza con pequeñas victorias. En vez de prometer una reescritura épica, resuelve cosas concretas que el cliente note. Cada cambio pequeño y seguro suma credibilidad y te da el contexto que necesitas para los cambios grandes. Es la diferencia entre el héroe que se quema en una semana y el que de verdad rescata el proyecto.
Cambios progresivos que sanan el proyecto
Una vez que entiendes el terreno, llega lo bueno: introducir mejoras de a poco, sin frenar al negocio. Tests donde más duele, refactors quirúrgicos, documentación mínima pero útil. No es glamoroso, pero es lo que convierte un código monstruoso en uno con el que se puede vivir. Y esa paciencia, en Howdy, la valoramos muchísimo.
Mira la charla completa
Dale play para el manual completo de Tom, con ejemplos de la trinchera. Y si eres developer al que no le asustan los desafíos reales, conoce las oportunidades en Howdy.
