En un mundo ideal, cuando programamos todos seguimos los principios SOLID. Evitamos siempre repetir código. Además siempre hacemos test unitarios, de integración e incluso algún otro test de la pirámide de testing. Intentamos usar patrones de diseño. Nuestros compañeros son verdaderos cracks. Todos los días aprendemos de ellos porque en el lugar en el que trabajas se lleva eso del aprendizaje continuo. Incluso es posible que tu empresa te proporcione formación de calidad. En ese mundo ideal, programamos como los cánones mandan. Hasta hacemos TDD. En definitiva:
El problema es que es un mundo ficticio y no existe. En su lugar existe el mundo real.
El mundo real
Hace un tiempo leía en una entrada de Javier Garzás, que lo más probable es que nunca trabajes en una compañía que desarrolle sofware muy bien. Básicamente se trata de estadística. Las empresas que desarrollan código muy bien (y por tanto aplicando buenas prácticas) son escasas. Lo más normal es que existan empresas que lo hacen mal o muy mal (o regular en el mejor de los casos). Eso quiere decir, que un programador random lo más probable es que nunca vea como se aplican buenas prácticas o procedimientos que mejoren la productividad y calidad del software desarrollado. Creo que es una apreciación muy cierta, a la par que espeluznante. Al menos para mí.
Lo cierto es que el mundo real no es Twitter, y aunque es es fácil encontrar artículos en Medium de alguien que ha aplicado un stack super molón, de como hace integración continua o de lo larga que tiene su cobertura de test, eso es, desgraciadamente, una excepción.
Y es que en el mundo real, la mayoría de las veces, los programadores rasos no tenemos la capacidad de aplicar buenas prácticas. Dependemos también de otras personas, ya sean jefes, compañeros o incluso la propia empresa como organización.
Si eres un programador de 9 a 6, que solo se preocupa de sus 8 horas de trabajo, no tendrás problemas. Serás feliz, al menos mientras no tengas que hacer horas extra, pero si eres un programador en estado de incompetencia consciente o competencia consciente seguramente acabes desmotivado por trabajar así.
Y es que, lo más normal desgraciamente, es que te toque trabajar con código heredado. ¿Y si el código no tiene tests unitarios? ¿Qué haces? Hacer test es algo que implica a todo el departamento de desarrollo, y muchas veces es un coste que no se quiere asumir (aunque parezca mentira se siguen viendo como un gasto).
Sin entrar en el tema del testing podemos ir a cosas más básicas como las políticas del equipo a la hora de codificar. Nombres de variables, nombres de clases, dónde y como llamar los archivos con el código etc. Si nadie sigue una guía de estilo, al final el código se ensucia, ya que cada desarrollador del equipo lo hace a su manera. Y si es el típico proyecto de cárnica, por el que pasan varias personas distintas al año, acabas con una guarrería muy difícil de manejar.
Lo mismo pasa con la formación. Algunas empresas lo ven solo como un gasto y piensan que sus empleados deben venir aprendidos de casa. No dejan espacio para la investigación, porque para todo hay un plazo. Muchas veces se hacen las cosas mal de forma cíclica, por no pararse una semana a buscar una mejor solución.
Vamos, que si no hay alguien con capacidad de decisión que se preocupe por estás cosas acabarás programando guarrerías. Y esto nos lleva a la desmotivación.
La desmotivación
En el libro The Pragmatic Programmer, se cuenta una metáfora que a mi siempre me ha gustado mucho. Viene a decir que está demostrado que un edificio abandonado puede aguantar el paso del tiempo bastante bien, al menos hasta que se rompe una de sus ventanas. A partir de ahí el edificio se deteriorará mucho más rápido, ya que la sensación de dejadez hará que los vándalos acaben por destrozarlo. Total, si nadie cuida el edificio, ¿por qué iba a hacerlo yo?.
La metáfora está en que con el código fuente pasa lo mismo. Si nadie se preocupa por él, al final todo el mundo acaba por hacer las cosas sin ganas. El proyecto se irá deteriorando poco a poco, hasta que al final no tenga arreglo.
A mí eso me ha pasado en varias ocasiones. Me ha tocado cambiar una parte del código, y al verlo, llevarme las manos a la cabeza. El primer pensamiento es el de tirarlo todo abajo y hacerlo bien. Pero entonces te paras a pensarlo. No hay tests unitarios. El código es una maraña de dependencias y acoplamientos. Sabes que si tocas esa parte, es probable que rompas otras tantas. Y eso te va a provocar sufrimiento. Y encima, nadie te va a reconocer el trabajo, si no que te van a decir qué por qué has tardado tanto en arreglar el bug o incluir la nueva funcionalidad. Así que al final, añades otro if al código y miras para otro lado. La metáfora de las ventanas rotas en todo su esplendor.
Serás feliz un tiempo, pero aunque no creas en el karma, Earl Hickey sí cree, y todas esas deficiencias que no arreglas, acaban explotándote en la cara. A todos nos ha pasado.
Al final, trabajando así, cualquier cosa que tocas rompe otras. Eso te hace sentir mal desarrollador, porque los fallos al fin y al cabo los has introducido tú. En serio, ese error no sucedía hasta que tú tocaste. Si vas de gazapo en gazapo, al final te sientes responsable, aunque sepas que no toda la culpa es tuya. De hecho tú solo eres el eslabón final de la cadena de fallos.
Eso es algo que a mí me desmotiva mucho.
¿Cómo des-desmotivarse?
El otro día leí un artículo de @xurxodev en DevExperto hablando sobre lo que es un desarrollador senior. En el se refleja como en un momento dado se dio cuenta de que como Jon Nieve, no sabía nada. Tuvo que reciclarse. Yo me siento totalmente identificado.
Hasta hace unos años, yo era programador de cárnica mala. Lo importante era cumplir con el cliente, y yo eso lo hacía bien. Soy un tío discreto, que no da guerra, y que hace las cosas razonablemente bien (dentro del caos) y sin quejarse. Pero un día me di cuenta que no estaba contento con eso. Empecé a investigar y vi que había un mundo mejor. Empecé a leer libros sobre buenas prácticas (Clean Code, The Pragmatic Programmer etc.). Leí (y sigo leyendo) libros técnicos para ampliar mi formación. Incluso abrí un blog para comentar lo que aprendía, y una cuenta de Twitter para seguir a los buenos y aprender de ellos.
Si echo la vista atrás, me doy cuenta de que en unos cuantos años, he mejorado mucho. Pero aun así, siempre tengo la sensación de que no es suficiente. Siempre hay un proyecto malo, en el que las cosas no se hacen bien, y eso como digo, te hace cometer errores. Eso me desmotiva mucho. De momento no he encontrado la manera de motivarme en este tipo de proyectos. Cada vez me queman más. Mi válvula de escape son mis proyectos personales. Al final yo soy el que toma las decisiones, sean buenas o malas. Pero en el trabajo, cuando tengo entre manos un proyecto feo (en mi caso casi siempre), no me veo con fuerzas de pelear con todos para mejorarlo.
En fin, ¿os ha pasado? ¿Soy el único? ¿Qué recomendáis?
¿Quiéres que te avisemos cuando se publiquen nuevas entradas en el blog?
Suscríbete por correo electrónico o por RSS