Ese sudor frío que solo un desarrollador conoce
Eran las cinco de la tarde de un jueves cualquiera. Tenía una tarea pendiente que parecía, sobre el papel, una tontería: actualizar un pequeño script de limpieza de base de datos. Nada del otro mundo, ¿verdad? Lo había probado en local, funcionaba. Lo subí a 'staging', funcionaba. Con la confianza por las nubes y las ganas de cerrar el día pronto, lancé el despliegue a producción. A los dos minutos, el canal de Slack de alertas empezó a echar humo.
Ese es el momento exacto en el que el corazón se te sube a la garganta. Entré en la web y ahí estaba: un precioso error 500 saludándome. No era solo que una función fallara; me había cargado el acceso de todos los usuarios activos. En ese instante, mi mente solo podía pensar en una cosa: "Hasta aquí hemos llegado, Roberto. Mañana estás en la calle". El pánico es una reacción visceral, casi animal, que te nubla el juicio por completo.
Mi experiencia con el desastre: Lo que pasó después
Lo primero que hice fue quedarme paralizado mirando la pantalla. Después, empecé a teclear como un loco intentando buscar el fallo, pero con los dedos temblando es difícil no cometer más errores. Por suerte, mi responsable de entonces se dio cuenta de lo que pasaba. Se acercó a mi mesa, vio mi cara de color blanco papel y me dijo: "Roberto, respira. Primero vamos a revertir el cambio y luego buscamos el porqué. Lo importante es que la web vuelva a estar arriba".
Esa frase cambió mi perspectiva para siempre. Hicimos el rollback y, en menos de cinco minutos, todo volvió a la normalidad. Nadie me gritó. Nadie me llamó inútil. Nadie me pidió que recogiera mis cosas. Al contrario, nos sentamos juntos a analizar qué había fallado. Resulta que en producción había un volumen de datos diez veces mayor que en staging y mi script, que no estaba optimizado, bloqueó las tablas por completo por un exceso de tiempo de ejecución. Fue una lección de humildad brutal.
¿Por qué me parece importante compartir esto?
A menudo, en este mundillo del desarrollo web, parece que solo podemos hablar de nuestros éxitos, de lo rápido que aprendemos un nuevo framework o de lo limpio que es nuestro código. Pero la realidad es que equivocarse es una parte intrínseca de nuestro trabajo. Si no te has cargado nada nunca, es que probablemente no has tocado suficiente código real.
Me parece vital hablar de los fallos porque humaniza nuestra profesión. El miedo al error es lo que frena a muchos desarrolladores junior (y no tan junior) a la hora de proponer ideas o de tomar responsabilidades. Cuando normalizamos que romper cosas es una posibilidad, empezamos a construir sistemas que son más robustos. Aprendemos que no somos cirujanos operando a corazón abierto (aunque a veces el cliente lo crea), y que casi todo en el software tiene arreglo si hay un buen proceso detrás.
Lo que he aprendido (a base de golpes)
De aquel día me llevé tres lecciones que hoy son dogmas para mí. La primera es que los tests automáticos no son un capricho del equipo de QA, sino tu red de seguridad. Si hubiera tenido un test de integración que simulara una carga de datos real, mi script nunca habría pasado de mi máquina. La segunda lección es la importancia de la observabilidad. No puedes arreglar lo que no ves, y tener logs claros fue lo que nos permitió identificar el bloqueo de tablas en segundos.
Pero la lección más importante no fue técnica, fue sobre la cultura de equipo. Aprendí lo que es el "Blameless Post-mortem" (aunque entonces no sabía que se llamaba así). Consiste en analizar el fallo buscando el fallo en el proceso, no en la persona. Si yo pude romper producción tan fácilmente, el problema no era yo, sino que el sistema permitía que una sola persona, sin una revisión cruzada o sin pruebas de carga, pudiera tumbarlo todo. El error es del sistema, no del individuo.
Desde aquel día, cuando veo a un compañero nuevo cometer un error parecido, lo primero que hago es invitarle a un café y contarle mi historia. Ayuda mucho a bajar las pulsaciones y a enfocar la energía en la solución.
Reflexiones finales
Irónicamente, ese día en el que "rompí" la web fue el día que más crecí como desarrollador. Perdí el miedo irracional a la consola de producción y gané un respeto profundo por los procesos de despliegue y el testing. Hoy, cuando diseño una arquitectura, siempre me pregunto: "¿Cómo podría alguien romper esto sin querer?" y diseño salvaguardas para ello.
Si estás leyendo esto y acabas de cometer un error gordo, respira. No es el fin del mundo. Es, simplemente, el inicio de tu siguiente nivel de experiencia. En el futuro, te reirás de esto mientras se lo cuentas a alguien que esté pasando por lo mismo. Al final, un buen desarrollador no es el que nunca se equivoca, sino el que sabe qué hacer cuando las cosas salen mal y, sobre todo, el que no permite que el mismo error ocurra dos veces.