La micro consultora

En mi primer trabajo orientado a Tecnologías de la Información me la pasé reparando computadoras en un lugar muy tóxico y terrible para trabajar. Por lo que tuve que pensar en buscar otros horizontes y uno de los más prometedores era buscar algún empleo en programación. Si bien no tenía experiencia previa "real" de programadora, había estado trabajando como independiente haciendo pequeños sistemas a dos capas con java por lo que podía intentarlo.

Pasaron los meses y una oportunidad apareció y no dudé en tomarla. En ese momento cualquier oportunidad era buena, con tal de programar en java y de trabajar fuera de aquel infierno. Al llegar y para mi suerte, el software estaba desarrollado en Visual Basic .NET y lo había desarrollado una persona que según comentarios se había ido a trabajar a Microsoft. El código (ideologías y guerras de lenguaje aparte) debería de ser extraordinario por lo que tendría muchas cosas que aprender.

Para mi desgracia no fue así. El proyecto era un caos y tenía cero documentación. Estaba tan mal hecho y tan mal diseñado que pensé que el programador anterior había pasado el código por un proceso de ofuscado para que nadie pudiera mantenerlo más que él. El software tenía nombres de variables con un solo carácter y con nombres de funciones con dos caracteres por lo que leerlo se hacía imposible. A parte no había clases, ni capas, ni nadie que pudiera decirme de que trataba el proyecto. Con el tiempo me di cuenta de que la variable p era pedimento y que la función pp era pago de pedimento. El sistema, además, facturaba: gf.

Ante un proyecto de ese calibre, en el que prácticamente el flujo de trabajo era no tocar nada para no romper nada y la refactorización era sumamente difícil; llegamos a una conclusión bastante buena/mala. No tocaríamos el código base, pero escribiríamos sobre él. Aprovechamos que todo estaba escrito sobre .NET Framework y utilizamos C# en la misma solución teniendo en cuenta que los dos lenguajes compilan a un intermedio similar y que la experiencia del equipo era más cercana a Java.

Esta especie de fachada me permitió avanzar en nuevos requerimientos, pero me retrasaba en el mantenimiento del código anterior ya que sin pruebas unitarias o documentación: tenía que debuggear, refactorizar y documentar antes de realizar cualquier requerimiento para evitar romper cualquier funcionamiento correcto anterior. Estos retrasos en el mantenimiento fueron el caldo de cultivo de ciertas interacciones tóxicas que no voy a describir. Solo basta decir que la desesperación de los usuarios era tan grande que la educación y la ética profesional faltó.

A los meses, me volví a cansar de la toxicidad, de lo mal que estaba este proyecto y renuncié.

¿Qué podemos aprender de esta experiencia?

Esta historia está prácticamente protagonizada por el mal código. Recuerda que cuando eres freelancer necesitas usar un estándar de codificación común (en internet hay muchos y para muchos lenguajes) para todos. No vale con escribir pp y suponer que todos los entenderán. Es necesario que tengas en mente la importancia del código limpio en los proyectos de software y como éste afecta a todos (ya lo hablamos en el problema de la intangibilidad del software) Por lo que es probable que mucha gente esté frustrada y molesta con el desempeño de la herramienta o por no entregar algo que funcione al 100%. Sin importar que, tu siempre tienes que ser ético y educado. Se un artesano del software.

Si al final el ambiente se vuelve tóxico, trata de escalarlo (como ya lo vimos en Aprende a lidiar con ambientes tóxicos) y si no sirve y la falta de educación ha faltado a veces la única respuesta es renunciar como lo hizo nuestra protagonista.