Antes de que sigas leyendo te hago 3 avisos fundamentales para entender este post.

  1. Este post no lo ha escrito Sergio, autor de este blog. Lo ha escrito un programador anónimo que por motivos laborales no puede publicar este contenido en su propio blog puesto que le gustaría conservar su empleo. Sergio sólo me presta su blog para que vosotros podáis leer mis reflexiones y yo le estoy enormemente agradecido por ello.

  2. Las reflexiones que aquí vais a encontrar no pretenden ni encontrar soluciones ni encontrar la raíz de problema alguno. Son sólo eso, reflexiones. Si cuando leas el post te sientes identificado, al menos verás que no estás sólo. Pero no busques soluciones aquí porque no las tengo.

  3. La historia no acaba bien…pero podría ser peor.



En medio de una pandemia mundial que las futuras generaciones estudiarán en sus clases de historia llevo más de un año y medio trabajando en un proyecto de software que no vale pa’ na’. Y no es que el proyecto en sí no tenga valor. Es que las líneas de código que escribimos no las ejecuta ya ni el equipo de QA. Es por eso que he llegado a la conclusión de que programo pa’ na’ y programo pa’ nadie. Es así de sencillo. Quizás no te parezca nada dramático, pero el último año y medio de mi vida se ha basado en escribir programas que nunca se ejecutan…y eso me frustra hasta la saciedad.

Durante años de profesión y estudio del afamado mundo del desarrollo de software me han enseñado a resolver problemas que otras personas tenían usando el código como principal herramienta. Aprendí a crear software que ayudara de una forma u otra a alguien. Al principio me ayudaban a mi mismo en mi proceso de aprendizaje. Luego pasé a crear programas que ayudaban a personas pequeñas con una web para su tienda o un e-commerce y en algún momento de mi vida profesional programas más grandes que ayudaban a miles de usuarios a realizar tareas complejas en sus entornos laborales. Pero ahora no podría estar más lejos de ese punto. Al principio lo que hacía ayudaba a alguien…ahora soy sólo un recurso que una empresa pone en un proyecto porque hay que llenar el hueco con algún programador.

Todo comenzó hace ya muchísimo tiempo, con un equipo lleno de ilusiones y una idea más de producto de las tantas ideas que hay en el mundo. Comenzamos a trabajar con un equipo pequeño, una idea cerrada, un diseño fijado, un plan claro y un montón de tickets de Jira por resolver. Sin embargo todo comenzó a torcerse cuando después de 8 meses no teníamos nada funcionando y el equipo aún seguía hablando del fabuloso MVP. Minimum Viable Product. Un MVP que en 8 meses no conseguimos poner en la calle. Y que spoiler….más de un año y medio después de la fecha de comienzo sigue sin estar publicado. Quizás estés pensando que el problema es que no fuimos capaces de terminar el código a tiempo, pero no podrías estar más lejos de la realidad. El producto estaba hecho, pero cada vez que dábamos un paso….teníamos que dar dos en la dirección contraria. Añadimos y quitamos funcionalidades extendiendo los tiempos de desarrollo hasta el infinito y la cosa no parecía mejorar. Cada día que pasaba, la publicación del proyecto estaba más lejos.

Por supuesto propusimos soluciones. La primera, la más obvia. Poner una deadline a todo esto y recortar la cantidad de producto a implementar de forma que nos comprometimos como equipo a entregar algo. ¿Y sabes qué ocurrió? Que fecha de entrega tras fecha de entrega nos fuimos retrasando por diferentes motivos relacionados con el diseño del producto o el desarrollo de elementos externos y a nadie le importó. No llegar a la deadline se ha transformado en el deporte olímpico de mi entorno laboral. Ahora somos campeones del mundo de no entregar en la fecha y que a nadie le importe. Al no haber consecuencias, a nadie le importa y lo único que pasa es el tiempo.

¿La situación no es tan compleja no? Un proyecto más de consultora que no se termina, que se encierra en un cajón y será un eterno repositorio privado en GitHub. Pero el drama no está en el proyecto en sí o en el tiempo y dinero que se ha invertido durante más de año y medio en hacer código que no se ejecuta…El problema está en las personas que están trabajando pa’ na’. El problema lo tengo yo.

Un día tras otro me levanto a trabajar como si nada pasara, buscando el siguiente sprint o el siguiente ticket para desarrollar pensando en que dar pasitos cortos nos llevará a publicar en algún momento. Total, qué vamos a hacer si sólo somos una consultora trabajando para un cliente. ¿Qué le vamos a hacer si el cliente no quiere cerrar el famoso MVP y publicarlo? Pues frustrarme, es lo único que puedo hacer. Eso o dejar mi trabajo por supuesto…pero las facturas hay que pagarlas de todos modos y no me gustaría dejar mi empresa porque el último proyecto no hay cojones a terminarlo. Y no te creas que no he comentado con mi manager esta situación eh! Si estás pensando que no he comentado lo que está pasando con mi jefe y el jefe de mi jefe te equivocas. Pero sabes qué…a nadie le importa porque el cliente paga y el que programa pa’ na’ soy yo. La respuesta siempre es la misma: “hemos propuesto soluciones y no las aceptan, lo único que nos queda es seguir trabajando”.

La frustración me come por dentro. Pasamos 8 horas al día escribiendo código que no prueba ni usa ninguna de las personas que están asociadas al proyecto. Ninguno de los implicados sabe cómo funciona el software que estamos creando más allá de la descripción de tickets de jira. He escrito cientos de miles de líneas de código para nada. Simplemente porque hay algún punto en la cadena de decisiones sobre qué hacer con el proyecto que no elige la decisión de publicar. Y esta frustración genera comportamientos derivados que son preocupantes. La falta de profesionalidad comienza a generar actitudes egoístas que hacen que cada uno, incluido yo, sólo nos miremos el ombligo. Ya no revisamos las pull requests en condiciones. Ahora ponemos un +1 rápido tras hacer scroll en la PR lo más rápido que podemos y listo. No nos preocupamos por los detalles de las historias de usuario, nos da igual que la build no pase en CI, no contestamos a mensajes o menciones y hacemos como que se nos ha pasado y sólo nos preocupamos de mover los tickets de Jira de columna en columna. Hasta tengo un compañero que programa con YouTube de fondo y programas deportivos varios en bucle! La frustración nos ha matado profesionalmente en menos de dos años de proyecto.

¡Y lo mejor de todo es que hasta hace poco pensaba que estaba sólo! No podía estar más lejos de la realidad. No te haces a la idea de la cantidad de colegas de profesión que programan pa’ na’, que programan pa’ naide. A día de hoy no me cabe en la cabeza que tantos desarrolladores están trabajando en proyectos que no se publican. No porque no funcionan en el mercado, ¡sino porque no se terminan! Somos piezas de un engranaje que giran porque hay que girar para pagar las facturas. Y el impacto que tiene esto es mucho más grande de lo que parece a primera vista. Estamos quemando personas y generando profesionales que acaban hundidos en el “qué más da si esto no vale pa’ na” constante.

¡Pero ojo! Hay un momento en el que hablar con compañeros de profesión te hunde más que te reconforta…cuando te exigen que tu trabajo sea excelente. Tengo que tener un código perfecto y autoexplicativo, unos tests unitarios que se ejecuten en nanosegundos y tengo que saber todas las buzzwords de programación funcional que los gurús de la comunidad usan. Si no uso microservicios con arquitectura hexagonal y TDD, no doy la talla como programador. ¿Pues sabes qué? El código que no se ejecuta porque no lo usa nadie da igual que esté escrito por el mismo Martin Fowler…porque no vale para nada.

Gracias a Dios no todo es tan malo, cuando salgo de trabajar tengo a mi familia y hobbies que me hacen olvidar la mierda de trabajo que tengo que hacer. Me queda el consuelo de que a medio plazo alguien cerrara el proyecto porque se quede sin fondos y volveremos a trabajar en un programa que espero que alguien ejecute al menos una vez para hacer algo útil. Porque si hay algo que me frustra de verdad, es programar pa’ na, programar pa’ nadie.