La jornada laboral empieza: enciendes tu computador, revisas tus pendientes. ¡Oh, vaya! Un bug… en producción. Pero si ayer funcionaba. Te apresuras a corregir, analizas, pruebas, git push… pasa testings, todo correcto. Sigues con tu día como si nada.
Un nuevo día empieza y tú enciendes tu computador, revisas tus pendientes y ¡Oh, vaya! Un bug… en producción… pero si ayer funcionaba…
¿Conoces el mito de Sísifo? Él, por un castigo impuesto por Zeus, tenía que empujar una piedra por la ladera de una montaña y, justo cuando estaba a punto de llegar, algo pasaba: la piedra resbalaba y debía volver a empezar.
Literalmente es el día a día de todo desarrollador, lo que me lleva a preguntarme: ¿cuál es el sentido de programar si es un acto donde constantemente somos Sísifo?
Albert Camus tomó este mito como metáfora de la condición humana absurda: nuestra búsqueda de sentido choca con un mundo caótico e indiferente, pero nosotros seguimos aceptando esa repetición sin esperanza de conclusión.
Y es que escribir código es, en muchos sentidos, intentar ponerle lógica a un caos donde nada garantiza que las cosas tengan sentido. Y el mejor ejemplo son los bugs: no importa cuántos logres arreglar, siempre aparecerá uno nuevo.
Programar cae en ese acto donde, por más que nos esforcemos, nunca terminamos realmente un proyecto; al igual que con Sísifo, la roca siempre vuelve a rodar.
Un ejemplo claro es el ciclo de mantenimiento y despliegue: subes código a producción con gran esfuerzo y, tarde o temprano, algo falla y hay que corregirlo; mejoras la infraestructura y entonces un pico de tráfico la quiebra de otro lado; arreglas un cuello de botella y aparece el siguiente. Todo esto es constante. Incluso rituales cotidianos como la reunión diaria ilustran esta repetición: todos los días se reporta qué hiciste ayer y qué harás hoy; solo cambian los detalles, pero nunca el hecho de que mañana habrá otra reunión igual. Por mucho que se avance, siempre habrá algo por hacer: si terminas un proyecto, vendrán correcciones de bugs, parches, nuevos requisitos o el siguiente proyecto en la fila.
Como bromea el autor Rick Cook (The Wizardry Compiled):
“Hoy en día la programación es una carrera entre los ingenieros de software, que se esfuerzan por crear programas a prueba de idiotas, y el Universo, que intenta producir idiotas más grandes y mejores. Hasta ahora, va ganando el Universo.”
Estudios indican que los desarrolladores pasan entre un 35 % y 50 % de su tiempo depurando y corrigiendo problemas en el software, comparado con el tiempo que dedican a escribir nuevas funcionalidades (Devon H. O’Dell, “The Debugging Mindset”). De hecho, solventar bugs suele consumir muchísimo más esfuerzo que introducir el código originalmente: se estima que arreglar un error puede tomar 30 veces más tiempo que escribir una línea de código (“This Is What Your Developers Are Doing 75 % of the Time”).
En promedio, según el mismo artículo, un desarrollador genera inevitablemente errores (¡70 bugs por cada 1 000 líneas codificadas, en promedio!) y gran parte de su labor es encontrarlos y corregirlos. No es de extrañar entonces que algunas estimaciones afirmen que cerca del 75 % del tiempo (unas 1 500 horas al año) de un programador se va en depuración y debugging.
Irónicamente, “si pensabas que tus desarrolladores dedican su tiempo a construir tu sueño, piénsalo de nuevo: la mayor parte del presupuesto se gasta detectando y corrigiendo defectos.”
Existe incluso un término jocoso en la jerga, Heisenbug, para referirse a esos bugs que desaparecen o cambian de comportamiento justo cuando intentas examinarlos.
Cual efecto cuántico, a veces el mero hecho de loggear o ejecutar en modo depuración altera la sincronización del sistema y el error deja de manifestarse, frustrando al ingeniero.
Pocas cosas encarnan mejor lo extraño de programar que perseguir un error esquivo que parece burlarse de tu observación. Todos estos esfuerzos invertidos en mitigar el caos refuerzan la sensación de estar atrapado en un ciclo absurdo, aplazando incendios en lugar de construir algo completamente nuevo.
Otra dimensión del absurdo en desarrollo de software es lo cambiante que es todo: requisitos, herramientas y tecnologías.
Los programadores a menudo avanzan a toda marcha en una solución, solo para descubrir de golpe que las especificaciones del proyecto han cambiado o que hubo un malentendido en lo que se debía lograr.
¿Te ha pasado dedicar días a implementar una funcionalidad y luego enterarte de que el cliente decidió un enfoque diferente o que había un caso de uso no considerado? Cuando esto ocurre, toca replantear, empezar de nuevo y desechar o reescribir gran parte del trabajo previo, a veces quemando horas o días de esfuerzo (“The Myth of Sisyphus, Failure, & the Meaning of Imperfect Code”).
A todo esto agregamos el absurdo de que la industria tecnológica evoluciona a una velocidad alucinante, lo que provoca que todos los días se cree una nueva necesidad por aprender esa tecnología novedosa o ese framework que te cambiará la vida, volviendo a ver rodar la piedra como Sísifo.
Es más, existe incluso un término popular: “fatiga de JavaScript”, acuñado en 2016 para describir el agotamiento que sufrían muchos desarrolladores ante el ciclo rapidísimo de nuevos frameworks de JavaScript, herramientas de build y tendencias cambiantes que vuelven muchas veces imposible mantener el ritmo (“Dealing with JavaScript Fatigue”).
Esto solo lleva a reconocer que mucho del conocimiento que dominamos actualmente quedará desactualizado en menos de dos años. He ahí lo absurdo de la programación, paradójicamente siendo también lo único que podemos garantizar: el cambio.
El sentido del absurdo
Podemos preguntarnos: ¿por qué seguir programando?
Y es aquí cuando me remito a Camus y su idea de rebelarse ante lo absurdo: no hay que buscar un sentido, hay que dárselo.
A pesar de que esto pueda parecer agobiante, no cambiaría mi profesión por nada del mundo. Desarrollar software, si bien nos convierte en Sísifo, también nos invita a no quedarnos quietos. La innovación, el aprendizaje constante y las ansias de conocimiento son lo que impera a la hora de practicar esta increíble profesión.
En lo personal, el poder cambiar constantemente y salir de mi zona de confort es algo que disfruto; abrazo la idea de no parar, de sorprenderme a mí mismo usando tecnologías que en un principio no entendía por completo, notar mi cambio como profesional y poder entender aquello que, hace apenas unos años, eran lenguas extrañas.
Puedo decir con certeza que no soy el único, ya que muchos programadores aprenden a disfrutar del proceso.
Cada bug resuelto, cada función optimizada, cada nueva habilidad dominada proporciona una chispa de satisfacción que justifica el esfuerzo.
Como señala un autor, los desafíos en el desarrollo de software “no son diferentes a Sísifo empujando la roca colina arriba. Hay obstáculos, errores y fallas (la roca rodando cuesta abajo), pero siempre vuelvo a programar. Siempre encuentro alegría en los desafíos y la lucha.”
Sorprendentemente, la frustración constante se convierte en fuente de significado: al atravesar el trabajo pesado, los detalles minuciosos y las soluciones imperfectas, el programador puede hallar satisfacción y consuelo en que está aprendiendo algo nuevo o haciendo una diferencia en el mundo con su software.
Un comentarista resumió muy bien esta filosofía refiriéndose nuevamente al mito: “A lo largo de los años nos encontramos resolviendo problemas similares una y otra vez, pero con suerte mejor cada vez; y con el tiempo, aprendemos a disfrutar el proceso… No hay que avergonzarse de nuestro trabajo pasado, solo intentar disfrutar el proceso de aprender a ser mejores. La roca puede que esté de nuevo abajo mañana, pero nosotros no somos los mismos de ayer.”
Conclusión — El camino es lo que importa
Como diría una One Piece Reference: “Programar son los amigos que hacemos en el camino.”
Pero, en serio, programar es disfrutar de ese camino: disfrutar esos pequeños logros, esas rabietas de cuando algo no sale como esperas y la satisfacción de luego encontrar la respuesta.
Camus nos invita a darle el sentido a lo absurdo, a la rutina; no a esperar encontrarlo, no a preguntarnos dónde está el final, sino más bien a relajarnos y disfrutar del recorrido. En general, no importa el fin, porque siempre puede haber más allá: importa más lo que aprendemos y cuánto disfrutamos de ello.
La roca siempre vuelve a caer, sí. Pero cada vez la empujamos con un poco más de elegancia.
Hasta el próximo blog.