"El lado humano del software"

Lo que vive un programador. Así nos exprimen

La esclavitud tiene muchas formas

¡Cuántas veces nos hemos quejado de nuestras condiciones laborales! De los interminables días de trabajo. ¡Y cuantas veces nos hemos sentido poco reconocidos y mal pagados! “Esclavos”.

Minimizan el tiempo que se tarda en realizar cualquier tarea para que te sientas avergonzado de que no hayas completado tú trabajo y tengas que hacer horas extra, toda una estrategia de acoso psicológico.

¡Esto es una locura!

Y mientras, los lenguajes de programación cada vez más complicados… antes bastaba con pocos años de estudios/prácticas, ahora hay que aprender a fondo varios lenguajes, unos cuantos ecosistemas, mil malditas librerías ¡y un montón de dispositivos distintos! Windows, Linux, MAC, IOS, Android, Navegadores Web, etc.

Para que seamos uno del grupito de los “iluminados” requerimos de una vida dedicada. ¿Tendremos que acabar estudiando más que ninguna otra profesión?

Encima, la mayoría de nosotros de externos, en las cárnicas, encontrándonos cosas increíbles para los tiempos en que vivimos:

  • Llegar a un puesto, y que la silla sea pésima o de tipo auxiliar. ¡Para rompernos la espada!

    … a veces dan ganas de llorar, y dices ¡no puede ser que esto me esté sucediendo a mí!
  • Que nos pongan un PC de la reliquia con un asqueroso monitor, y que nos exijan producir deprisa, teniendo que dejarnos la vista o esperar un minuto a cada click del ratón.
  • Que no seamos administradores de la máquina en la que trabajamos.
  • Que nos den a saco una mínima explicación sin entrar en lo funcional. Obligándonos a ser adivinos bajo el pretexto que sino “somos poco profesionales”.

 

  • Ojalá que la “porquería” se quedara limitada sólo al teclado… lo peor no se encuentra en este…

    Oír expresiones que rozan el insulto, bien estudiadas para que nadie pueda expresar queja alguna “esto tiene que estar en 2 semanas, no me digas que no eres capaz”, ese “no eres capaz” tiene connotaciones terribles de insulto personal por muy buen tono que se use.

  • Que las horas extras siempre vayan en un solo sentido (evidentemente a tú contra) y que no se admita que te puedas encontrar medio enfermo y tengas que bajar tu ritmo de producción. Vas a tener que decir que estás muriéndote o pensando en ir al hospital, a la unidad de cuidados intensivos.

La lista puede crecer hasta casi el infinito… ¿qué sentido tiene extenderla? Sabéis muy bien de lo que hablo.

La cárnica puede no ser lo peor, hay que tener en cuenta que para ellos somos productos, y los productos tienen cierto valor por el interés que les conviene, sobre todo si tienes un perfil interesante. Me refiero al típico cliente tóxico.

En el cliente final, suele existir la figura de los analistas funcionales en nómina, tú como externo o como técnico, sueles estar excluido del grosso de lo funcional, de manera más o menos refinada, eres el sirviente. Sirviente no tiene por qué tener una connotación necesariamente despectiva o terrible, la gran mayoría de la sociedad nos servimos los unos a los otros. Es cierto que muchas veces hay externos de funcionales, pero en este caso suelen ser de las capas bajas de lo funcional, se sienten exprimidos como nosotros.

Una imagen clásica que no por tradicional deja de reflejar muy bien la única forma que un externo tiene para lograr hacerse interno

Los altos cargos del cliente final no son profesionales de nuestro sector y como es lógico toman decisiones puramente empresariales. Encima te encuentras con los cargos medios que conocen sus productos a nivel de negocio, se han tirado años aguantado para llegar a donde están, y no están dispuestos a que un externo recién llegado les ocupe el puesto: bloqueando la integración y la armonía, en resumen, haciendo de muro.

La única forma de atravesar es que el propio externo se vuelva parte integrante del mundo de los cargos medios, cosa harto difícil por el punto de partida de marginalidad del que se parte. Los pocos que lo logran, no van publicándolo en blogs, han luchado mucho para perder todo en un momento de arrebato comunicativo. Por supuesto, no hay que criminalizar a todos los cargos medios, sienten una presión terrible en todas direcciones y también hay que entenderlos.

 

El resultado es un sector corporativista, cerrado. Los altos cargos desde su visión parcial se centran en la cuenta de resultados. Los trabajadores para ellos son recursos, sin más, así de aséptico. Los empleados en el cliente final por miedo tienen las bocas cosidas para que la gente no exprese lo que realmente piensa. Las personas se pudren en el día a día, una especie de “zombis”, tétrico. La falta de comunicación humana es real. De vez en cuando se oyen quejas de extremistas que, por radicales, rápidamente son apartados del circulo de los “cuerdos”. Quien piense lo contrario que lo diga bien alto, porque esta es la realidad que pensamos la mayoría, con independencia de ideologías políticas.

Sí, estoy traspasando gran parte de la responsabilidad del estado del sector a los clientes finales, manejados por los fondos de inversión. Los fondos de inversión compiten entre ellos en una macro-economía que tiene tanto sus aspectos positivos como negativos. Por desgracia, nos toca lidiar precisamente con uno de esos lados negativos ☹

En el cliente, también suelen existir la figura de los empleados fijos que son usuarios finales de la herramienta que has programado. Los podemos denominar por llamarlo de algún modo “Usuarios Preferentes”. Los usuarios preferentes suelen mover la responsabilidad de su trabajo al analista programador, su desfase tecnológico nos los comemos nosotros.

El usuario final preferente, habitualmente o no entiende, o no quiere entender. Aparentemente es porque no es su función y no deben entrar en “estas cosas que les ocupa tiempo”.  Para el usuario preferente, la digitalización sólo es un marrón más con los que le toca lidiar en su día a día. A partir de esta simple aparente verdad, se esconcen muchos vicios ocultos y una de las formas más improductivas.

Típica reacción de los internos cuando les hablas de cualquier asunto técnico, cualquier excusa es buena para eludir la responsabilidad

El usuario final preferente, que entiende poco de conceptos básicos dificulta enormemente el avance del proyecto, pues va expresando necesidades inconexas de lo que tiene que tener el producto, que luego el funcional interno no recoge convenientemente (al estar en nómina), porque total, él no está a un paso del despido como los externos. Además, tiene que satisfacer políticamente a todos, con lo que pierde eficacia (y si es externo, suele ser porque el pobre se encuentra tan sobresaturado de trabajo como tú).

Las inexactitudes se van sumando, formando una bola de nieve hasta que el producto se llene de retrasos y quejas. El principal responsable es el externo ¡por supuesto! para eso es el último de la cuadrilla.

La clásica defensa es hacer un escudo protector: para lograr que definan el proyecto, tendemos a ir a casi todo por email. Lo siento, no sirve, la burocracia de una gestión así es infernal, perderás un mínimo de un cuarto de tú día laboral respondiendo y gestionando emails. Si a eso sumas otro cuarto del día de preguntas, reuniones improductivas, etc., te va a quedar medio día para tirar código y solventar incidencias ¡a trabajar horas extra y fines de semana!

El paso del tiempo no ayuda, es cierto que conocerte mejor las herramientas con las que produces te permite optimizar tu tiempo, pero por desgracia a la vez que vas dominando mejor todas las casuísticas tecnológicas del proyecto, van aumentando toda una avalancha de bugs o de incidencias. Siempre de una forma u otra son responsabilidad culpa del externo.

 

Estas sólo, eres el culpable

 

Por no querer, no suelen ni querer aprender realmente qué es un evolutivo, una mejora funcional, una incidencia de datos, otra de código, etc., lo dicho: todas son incidencias y, por tanto, todas son responsabilidad culpa tuya, es lo que subyace, punto.

Si intentas dar explicaciones, te dirán que hablas en un lenguaje muy técnico, que no realizas el “suficiente esfuerzo pedagógico”.

La peor parte llega cuando una vez puesta tu aplicación en el entorno de preproducción o producción, te llegan diciendo que se habían olvidado añadir no sé qué “pequeña tontería”, y que “eso estaba de cajón”, “era algo obvio que tú tenías que haberte dado cuenta cuando hicieron la solicitud”. Sí, por supuesto debes adivinar los aspectos funcionales cuando programas, de lo contrario según ellos eres torpe.

Los cambios de última hora según ellos son un “Child’s play” (juego de niños) y por supuesto lo vas a pasar genial porque eres un “friki”

Dado que la aplicación no estaba pensada para nada en ese funcionamiento de última hora, el “pequeño cambio” puede ser terrible. El resultado es algo similar a esto:

 

“esta petición es muy fácil, sólo has de mover el edificio un metro a la derecha, total, ¡un metro es muy poco! ¡Tú eres “capaz de eso y más!”

Te quedas impactado…

… y lo peor sin saber qué contestar…

…y piensas, “el que te lo dice no tiene ni idea”

Un momento. ¿seguro que lo dice porque no sabe?

 

 

La presión sigue y sigue, y al final acabas “estando quemado”, es decir, hasta las narices de todo…

Yo suelo intentar explicar que el código de programación, la lógica, tiene un comportamiento rígido similar a las vías del tren, es algo muy poco flexible y cuando lo es, es porque se ha diseñado para que lo sea.

Cuando me vienen con cambios de última hora, lo que intento es no modificar las vías, más bien es enganchar las nuevas vías en algún punto antes o después, modificando lo menos posible el código o la estructura de datos. Con los parches se produce un código menos eficiente, pero es la única solución cuando te obligan a terminar cuanto antes.

Por más que expliques la historia es un ciclo sin fin, al final terminamos aceptando que nos “metamos el dedo por la nariz” por no decir otra cosa que a buen entendedor pocas palabras bastan…

Aunque expliques mil veces el concepto de las vías del tren, es un mal endémico sin solución, pues la gente le cuesta entender que algunas peticiones las puedas realizar en un “momento” y otras sin embargo cuesten cien veces más, para ellos es como si los tiempos de realización de la producción fuesen por causas aleatorias.

Esta es una de las formas más odiosas de las metodologías ágiles puras llevadas a extremo, de nula planificación.

Y la historia se repite una y otra vez, en diferentes estilos, en diferentes contextos, con diferentes actores (llamémoslos usuarios preferentes o como queramos) pero siempre en el fondo es lo mismo.

Algunas veces te llegaran peticiones al estilo “Y vas al planeta Marte y vuelves en un fin de semana, total, ya se han construido otras naves espaciales, sólo es un viaje un poquito más largo”. Otra aún más típica: “lo nuevo a implementar es muy parecido a lo otro que ya has terminado, sólo es copiar y pegar”, ¡como si acaso una nueva funcionalidad parecida a otra no tuviera implicaciones de tener que hacer un nuevo estudio de casos de uso u otras refactorizaciones!

Se trata del “Time is trash” (Tiempo es basura), van a minimizar lo que se tarda en realizar cualquier tarea, e intencionadamente no se consideran la montaña de pequeñas tareas que surgen durante el día: consultas de usuarios, reuniones, etc., para que te sientas avergonzado de que no hayas realizado tú trabajo y tengas que hacer horas extra sin pedírtelas directamente, es toda una estrategia de acoso psicológico.

Si a esto sumamos, la habitual falta de presupuesto, en el que te tienen trabajando a destajo de petición tras repetición: recuerda, eres sirviente y por tanto una especie de robot, tu agotamiento mental, físico y psicológico serán lo habitual en tu vida.

Tu mente, no brillará todos los días, por ejemplo ¿quién no ha tenido una mala noche de sueño. Pero las exigencias de mover el edificio un metro a la derecha seguirán constantemente, por lo que los atrasos se sumarán…

En muchas empresas te habilitan la VPN para que puedas trabajar remotamente, de forma “bien intencionada”… la VPN no es para hacer tele-trabajo en tu horario laboral oficial, no, sino para que hagas tele-trabajo en tus horas libres no remuneradas… nuevamente es la flexibilidad laboral en su “máximo” esplendor.

 

¿Cómo sabe un responsable de proyecto que entiende poco de técnica si está consiguiendo la máxima optimización de la producción?

Simple, a cada fase de los proyectos, exigen un poquito más, a cada poco se hacen la pregunta “¿hay conflicto? ¿No? ¡Estupendo! ¡A la próxima a exprimir más!” Y en la siguiente iteración vuelve a aumentar un 10% más sus exigencias “¿hay conflicto? ¿No?” Otro 10% más, y así sucesivamente hasta el nacimiento del conflicto, de las quejas y de ver que los programadores se encuentren reventados. Es la técnica denomina “get run over” (aplastamiento por rodillo). Sólo entonces se sienten satisfechos. Por supuesto, el que se queje sin “delicadeza extrema” ya le sabemos su destino…

 

Tu tiempo de aprendizaje de nuevas herramientas no cuentan, aunque algunas de boquilla presuman de algún cursillo muy esporádico de vez en cuando. Las empresas no asumen, porque no les interesa, que hacer software es caro. Se pretende para cuadrar su balance de gastos, que la automatización que produce el software a medida se obtenga con una inversión mínima en diseño, creación del código y pruebas.

Lo peor que hay es que te mientan. Generalmente en las empresas grandes la mentira es más disimulada por el corporativismo y queda parcialmente difuminada. En la empresa pequeña se toma como algo más personal

Luego están (generalmente en las empresas muy pequeñas)  los que van de un supuesto “buen rollito”, pero en las que al final acabas trabajando más que “un desgraciado” porque no tienen dinero para afrontar lo que es producir. 

También  puedes ir de autónomo. En este caso deberás facturar a los clientes un mínimo de tres veces más del importe neto de lo que quieres ganar. Te tacharan de carero constantemente. ¡Cuidado! sino cobras esas 3 veces más serás el mayor explotado de todos los posibles tipos de empleados, pues los impuestos, gastos e impagos te comerán vivo.

Seamos realistas, trabajar es trabajar, y no un juego de niños. Trabajar implica un sacrificio, pero jamás debería ser más que un sacrificio moderado con sus pequeños momentos de placer.

Ni varita mágica ni soluciones universales. Las circunstancias cambian según el país, sector empresarial, e incluso del azar más puro: depende de dónde te toque.

 

Al final, te acabas planteando qué es lo que quieres en tú vida, harto de soportar tantas humillaciones psicológicas.

Por nuestros propios medios apenas podemos cambiar nada. Llegados a este punto, parece como si estuviéramos en un final de no retorno, sin solución. Pretender hacer más en menos tiempo sólo empeora las cosas, nos estresa y acabamos sufriendo.

Si, la vida en nuestro sector es mucho más dura de lo que socialmente se cree.

Ante tanto maltrato psicológico, jornadas de reventarnos la cabeza de tanto pensar, dolor del cuerpo por estar inmóviles… necesitamos un abrazo, te mereces un poco de cariño… respirar…

Pero… Un momento… ¿Y si hubiera un resquicio de salvación, una salida? 

¿Es posible?

¡ Síiiiiiiii !

Te invito a que sigas leyendo el siguiente post:

Cómo dejar de sufrir siendo externo

¡Marchando una de soluciones! 😊

1 comentario en “Lo que vive un programador. Así nos exprimen

  1. Hola Victor.
    Aunque no soy del sector, estoy ahora creando mi blog y, entre otros temas, trataré el Diseño Web con WordPress orientado a los emprendedores no nativos digitales. El mero acercamiento a la programación me hace tener un enorme respeto por los que os dedicáis a este mundo profesionalmente.
    Sabemos que en todas las profesiones hay que “aguantar” y no todo es de “color de rosa”, pero leyéndote he tomado conciencia de que hay un enorme error en general en cuanto a la consideración de que los programadores sois efectivamente unos “frikies” a los que os gusta tanto vuestro trabajo, que os lo pasáis en grande delante del ordenador.
    por lo que cuentas, nada más lejos de la realidad.
    Creo que lo que os ocurre es lo que ha ocurrido toda la vida:
    sois víctimas de las clásicas técnicas de explotación (en tu sector maquilladas y sibilinamente atenuadas), que ciertas empresas han usado para conseguir “más rendimiento”.
    Afortunadamente, ya hay empresas pioneras que piensan de otra forma y aplican otros métodos no sólo más humanos, sino más eficaces y rentables, de entender la productividad de sus empleados. Con el tiempo esto tendrá que extenderse, espero.
    Te seguiré con interés.
    Enfin, se agradece que alguien cuente las cosas que pasan

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.