arthurolg Visita mi perfil en GitHub

La Rutina del Programador - Reflexión sobre Desarrollo de Software

| | 10 min de lectura
La Rutina del Programador - Reflexión sobre Desarrollo de Software

Lecciones de Saitama y la Rutina del Programador

Hay días en que programar se siente como entrenar para ser un héroe en un mundo que no cree en los héroes. Me pasa seguido. Abro el IDE, cargo el proyecto, y mientras los logs empiezan a desfilar, me acuerdo de One Punch Man. Ese tipo calvo, con capa, que con un solo golpe destruye monstruos del tamaño de edificios. Saitama. El héroe más fuerte del mundo y, paradójicamente, el más aburrido.

Desde que vi el anime y leí el manga, siempre me identifiqué con él, aunque no por la fuerza, sino por la rutina. En el mundo del desarrollo de software, sobre todo cuando vives en el ecosistema de Java, hay algo de ese vacío que Saitama siente después de derrotar a otro enemigo sin esfuerzo. No porque el trabajo no tenga mérito, sino porque a veces el entorno empresarial te quita la gloria del golpe. Lo que importa es el sprint, el deadline, el KPI. Te mides en JIRAs cerradas, commits aprobados, pipelines verdes. El héroe anónimo detrás del teclado.

Recuerdo una mañana en la oficina. Teníamos un bug en producción, un clásico: algo que nadie entendía y que solo pasaba "a veces". Lo típico que aparece cuando el sistema lleva semanas corriendo sin complicaciones. El tipo de problema que se ríe de tus pruebas unitarias y de tus mocks cuidadosamente diseñados. El equipo entero se reunió. Algunos lanzaban hipótesis: "Debe ser un thread que no libera recursos", "Tal vez un timeout de AWS". Yo escuchaba en silencio, con ese gesto cansado de quien ya ha peleado con monstruos así. Y entonces, casi por instinto, hice un grep en el log. Tres líneas más abajo, el error brillaba como una señal en la noche: NullPointerException.

Un golpe. Preciso. Mortal.

Ese fue mi "punch". Pero nadie aplaudió. No había música épica de fondo. Solo un silencio breve, un "ah, ya está", y de vuelta al trabajo. Y me reí solo. Porque Saitama, después de destruir un monstruo que amenazaba a toda la ciudad, siempre hacía lo mismo: bostezar y preguntar si había rebajas en el súper.

No por alardear, o porque necesite reconocimiento. Sino porque, al igual que Saitama, a veces el héroe más fuerte se siente vacío. La rutina, la repetición, el día a día del programador puede ser monótono. Los grandes desafíos se vuelven pequeños bugs, las épicas batallas se convierten en tareas rutinarias. Y ahí es donde radica la verdadera fortaleza: en seguir adelante, en encontrar sentido en lo cotidiano.

Ahí entendí algo. Ser programador en Java, en un entorno empresarial, es como ser Saitama en un mundo de héroes con trajes brillantes y nombres complicados. Tienes a los Java Champions, los certificados, los que hablan en conferencias y dominan cada nuevo framework como si fuera un arma secreta. Y luego estamos nosotros, los que día a día mantenemos los sistemas corriendo, no tenemos tiempo para conferencias, estamos: arreglando bugs, limpiando código, refactorizando clases que alguien más escribió hace años y que siguen ahí, como fósiles digitales.

Saitama entrena hasta perder el cabello. Nosotros perdemos la paciencia, la vista o la fe en los naming conventions. Pero seguimos. Porque hay algo adictivo en la rutina del héroe: la posibilidad de que, detrás de un bug o de una refactorización, se esconda una pequeña victoria invisible.

La historia de Saitama sigue el Viaje del Héroe, aunque él mismo se burle del concepto. Empieza siendo un tipo normal, sin rumbo, sin propósito. Luego decide entrenar todos los días hasta convertirse en algo más (es la esencia de la práctica deliberada, como dice el libro haz las cosas tan bien que no puedan ignorarte). Pero ese "algo más" lo aísla. Nadie puede entenderlo. No hay rival digno.

Eso también pasa en el software. Empiezas emocionado: el primer Hello World, el primer Spring Boot Application, la primera API que responde en Postman. Luego viene la curva de aprendizaje, el entrenamiento constante: patrones de diseño, microservicios, Docker, Kubernetes. Y cuando por fin dominas el flujo completo del backend al despliegue, algo cambia. La emoción inicial se convierte en una calma rara. Ya no te asusta el código, pero tampoco te sorprende.

Te vuelves un héroe sin villanos.

En ese punto, la vida laboral se convierte en una especie de saga de relleno. Reuniones, tickets, regresiones. Monstruos burocráticos. A veces el enemigo no es un bug, sino la falta de propósito. El tedio es un boss silencioso, pero muy real. Algo que muchos programadores enfrentan en su día a día y que muchas veces pasa desapercibido o se disfraza de estrés, burnout o síndrome del impostor.

Ahí es donde la metáfora de Saitama golpea fuerte. Él no busca pelear; busca sentir algo. Lo mismo pasa con nosotros cuando el proyecto se vuelve tan mecánico que ni siquiera un bug raro logra encender la chispa. Lo que salva esos momentos no es un nuevo framework, ni un aumento, sino encontrar un sentido más profundo. Crear algo que importe, aunque sea una pequeña función que mejore la vida de alguien. Poder recordar el impacto real del nuestro trabajo, en el producto final y en las personas que lo usan.

Recuerdo otra tarde, una de esas en que el sol pega en la ventana y uno quisiera estar en cualquier lugar menos frente a un monitor. Estaba trabajando en una refactorización del módulo de promociones. Nadie lo había tocado en años. Tenía comentarios como "TODO: mejorar esta función algún día" o "esto no debería funcionar, pero funciona". Empecé a limpiar, clase por clase. No era heroico. Era tedioso. Pero había una satisfacción silenciosa, casi meditativa. Como si cada línea de código limpia fuera un golpe certero. Como si cada bug eliminado fuera un monstruo menos en la ciudad.

A mitad del proceso, el sistema dejó de compilar. Pasé muchas horas revisando. Me sentí como Saitama enfrentando a Boros, ese jefe que por fin aguantó más de un golpe. Era frustrante, pero también emocionante. Porque en ese pequeño caos, el oficio volvía a tener vida.

Cuando por fin compiló y pasó las pruebas, sentí: orgullo. No el que se muestra, sino el que se guarda, ese que te permite cerrar el IDE y dormir tranquilo.

Héroes y lenguajes de programación

Los lenguajes de programación, en este universo paralelo, serían como los demás héroes de la Asociación:

  • Python sería Genos: el aprendiz entusiasta, moderno, lleno de energía y con la necesidad de impresionar. Un lenguaje que todos admiran, pero que todavía busca su lugar entre la tradición y la innovación.
  • JavaScript sería King: poderoso en apariencia, con fama de invencible, pero con un caos interno difícil de dominar. Nunca sabes si va a salvar el día o romper producción.
  • Go sería Bang: rápido, preciso, minimalista, con ese aire de "no necesito florituras para ser letal".
  • Rust, por supuesto, sería Tatsumaki: arrogante, impenetrable, pero con razón.
  • TypeScript sería Fubuki: elegante, con estilo, pero a veces un poco fría.
  • Php sería Mumen Rider: subestimado, ridiculizado por muchos, pero con un corazón enorme y una determinación inquebrantable.
  • Y Java... bueno, Java sería Saitama. Viejo conocido. Subestimado por muchos. Sin trucos, sin moda, pero con una fuerza constante.

En el entorno empresarial, Java ha resistido como Saitama: estable, confiable, silencioso. No necesita presumir. Solo aparece cuando el mundo se está cayendo y alguien dice: "Necesitamos algo robusto." Entonces entra Java, sin capa ni carisma, pero con la garantía de que el trabajo se hará.

El viaje del héroe no termina con la victoria. Termina cuando el héroe regresa al mundo ordinario, cambiado por dentro. En nuestra versión, ese regreso ocurre cuando cerramos un sprint, entregamos el release y todo funciona. Por un momento, la ciudad está a salvo. Luego el ciclo empieza otra vez.

Pero hay algo que la serie enseña: no todo héroe pelea por fama o medallas. Algunos lo hacen solo porque pueden. Porque sienten que es su deber. En el desarrollo, esa filosofía importa. No siempre serás reconocido. No siempre tu código será celebrado. Pero cada pequeño arreglo, cada línea que haces más legible, cuenta. Son golpes invisibles que mantienen vivo al sistema.

A veces, cuando practicas tanto tiempo, pierdes el sentido de por qué empezaste. Saitama lo vive. Nosotros también. La diferencia es que en nuestro mundo no hay créditos de cierre ni un ending melancólico con piano y guitarra eléctrica. Hay solo la próxima feature, la próxima reunión, el siguiente deploy. Ese ciclo interminable.

El giro inesperado fue darme cuenta de algo que no esperaba, la experiencia me ha dado una nueva perspectiva. Siempre quise ser un programador fuerte, capaz de resolver cualquier problema. Pero la fuerza, en este oficio, no está en saber más que los demás, sino en resistir más. En mantener la calma cuando todos corren, en sostener al equipo cuando el sistema cae, en enseñar sin prepotencia, en tratar de ser un líder como el que yo mismo hubiera necesitado al empezar. La fuerza de Saitama no es su puño, es su serenidad y su constancia.

La rutina del héroe cotidiano

Una vez, un compañero nuevo me preguntó por qué seguía programando en Java cuando podía moverme a algo "más moderno". Me reí. Le dije que, al final, todos los lenguajes son solo herramientas. Lo que cuenta es la filosofía que llevas al escribir. La disciplina. El respeto por el código. Como el entrenamiento diario de Saitama: cien flexiones, cien abdominales, correr diez kilómetros. Todos los días, sin falta.

No espero que mis contribuciones sean épicas o revolucionarias. Solo espero que, al final del día, cuando cierre el IDE, pueda sentir que he hecho mi parte. Mi camino del héroe es personal, y eso es suficiente.

No busco el reconocimiento ni la gloria. Hago lo que hago porque sé que es lo correcto, porque amo este oficio, me encantan las personas y la tecnología, pero busco ayudar a otros a crecer conmigo.

Mi legado no será un código famoso o un framework revolucionario. Ese legado son mis hijos, mi esposa, las personas que dependen de mí. El tiempo que paso con ellos es mi verdadera victoria.

Pienso que eso es escribir buen software: hacer lo mismo una y otra vez, pero con atención, con propósito. Refactorizar no es glamuroso, pero es heroico. Documentar no da fama, pero salva a otros. Y cuando llega el bug imposible, el boss final, tu entrenamiento silencioso es lo que te salva.

Los entornos productivos, o el sistema, sigue en pie gracias a esos héroes invisibles que no buscan gloria. Los que escriben unit tests a medianoche, los que arreglan bugs que nadie vio, los que enseñan sin esperar reconocimiento.

Quizá nunca tengamos un enemigo digno, ni un público que entienda lo que cuesta mantener vivo un servicio entre microservicios, dependencias y latencias. Pero eso no importa. Como Saitama, seguimos porque sí. Porque amamos la pelea, aunque ya no nos asuste. Porque, al final, lo único que de verdad importa no es el golpe, sino el propósito.

Y si mañana aparece un nuevo monstruo, un nuevo bug, una nueva crisis... bueno, ya sabemos qué hacer.

Golpe limpio. Sin drama.

Y luego, una taza de café.