martes, 21 de noviembre de 2023

El camino hacia el dominio I: el test de egoísmo

 Antes de empezar, si no lo has hecho ya, te recomiendo leer el artículo anterior "Ansiedad VS Motivación: el estado de fluidez" para dar contexto a lo que te voy a contar a continuación.

El proyecto BLUELOCK


En una especie de juegos del hambre del fútbol, 300 chicos van a competir por convertirse en el mejor delantero del mundo. Por suerte los 299 restantes no van a morir, sólo se acabarán sus opciones de integrar la selección nacional :-P
Pero en Bluelock no solo van a aprender cómo llegar a ser el mejor delantero del mundo, sino que aprenderán a ser mejores, a mejorar.
Y ahora sustituid "delantero" por vuestra profesión en el mundo del software y ya lo tendréis ;-)

Capítulo 1: el test de egoísmo.
Jinpachi Ego

En el fútbol, cuenta Jinpachi Ego, los delanteros son los mayores egoístas que existen. Sólo les importan sus goles. 
Para ser el mejor delantero del mundo, debes ser, por lo tanto, un auténtico egoísta. Ego, que es el director del proyecto Bluelock, les pone una primera prueba a los 300 chicos para medir su egoísmo: el “tú la llevas”. Divididos en grupos de 12, aquel que “lleve” el balón cuando se termine el tiempo, quedará eliminado.






Yoichi Isagi

Nuestro protagonista, Isagi, el penúltimo clasificado de los 300 chicos, consigue superar el test de egoísmo golpeando con el balón a otro participante en el último momento, y así ascender en el ranking. 
Pero no golpeó a un participante cualquiera: era el mejor clasificado de su grupo. Y esa obsesión por la victoria personal, ganando al más fuerte, que se sale del sentido común, es lo que busca Ego: el egoísmo del delantero.

Y es que el ego no tiene por qué ser malo. ¿Qué tiene de malo disfrutar de la victoria? ¿O sentirse bien por los logros individuales? ¿O tener ambición? Lo que debemos hacer es un uso inteligente del ego ya que sino puede convertirse en un bloqueo para nuestro aprendizaje.


COMPETENCIA
Más adelante en la historia, Isagi se enfrenta en un 2 para 2 contra un rival que está más o menos en su misma zona del ranking.
El ego se convierte en un bloqueo para el aprendizaje, cuando con aquellas personas que están más o menos en tu mismo nivel, que saben más o menos lo mismo que tú, entramos en competencia.

En este caso, Isagi lo que hace es observar lo que hace este chico, ver qué tipo de juego tiene que a él le podría venir bien, coger todo lo que tiene este chico y que él no tiene y hacerlo suyo. Y de esa forma consigue ganar el partido.
Un buen ejemplo de un uso inteligente del ego. 

En uno de mis antiguos equipos había una chica que siempre te decía en las dailys que “todo iba bien”. Nunca necesitaba nada, nunca había que ayudarla… hasta que llegaba el día de entregar su código y entraba en crisis porque no lo había podido terminar o no funcionaba.
Llegaba a tal nivel de competencia con sus compañeras, que era capaz de quedarse hasta las 10 de la noche trabajando para resolver algo que una compañera le podría haber explicado en 5 minutos.
La competencia nos dice, no dejo que nadie me enseñe y además nunca pido ayuda.


PATERNALISMO
Un poco después, Isagi hace equipo con un tipo que se llama a sí mismo “El Rey”. Y que considera que todos los demás son sus súbditos. Si son sus súbditos significa que están por debajo de él. El ego se convierte en un bloqueo para el aprendizaje, cuando tratas a aquellas personas que tienen un nivel de habilidades inferior al tuyo con paternalismo.
¿Qué vas a enseñarme tú a mí, que yo no sepa?
Y este chico, al contrario de Isagi que sigue avanzando, se queda bloqueado en su aprendizaje ya que no acepta que puede aprender de sus compañeros. Hay un momento en el que su juego ya no funciona, no consigue marcar gol y le llegan hasta a dejar de pasar el balón.
Ejemplo de un uso poco inteligente del ego.

En otro equipo con el que trabajé había una chica que directamente le llegó a decir a un programador junior: "deja de hacerte preguntas y haz lo que yo te diga". Porque en su cabeza, no cabía la posibilidad de que eso que estaba contando pudiese ser cuestionado.
Esto es un verdadero problema ya que se aprende muchísimo de las personas que están empezando. Porque se hacen preguntas que tú tal vez nunca te hayas hecho. Porque se cuestionan las cosas que tal vez tengamos interiorizadas como “esto siempre se ha hecho así”.


ADMIRACIÓN
Siguiendo la historia, en otro momento Isagi se enfrenta a un equipo formado por 5 "cracks" de talla mundial del fútbol profesional. Tras la (estrepitosa) derrota, Isagi asume que “no tenían nada que hacer”. Cuando te enfrentas a alguien que está por encima de ti en conocimientos, el ego no te va a permitir competir, ¡porque perderías! (como le pasó a Isagi), así que entramos en una situación de admiración. Ya que, no puedo competir porque "es que son cracks de talla mundial". Y el problema de la admiración es que todo lo que viene de ese “crack” nos lo creemos, no lo cuestionamos, lo aceptamos como dogma.

Sin embargo uno de los compañeros de Isagi está realmente frustrado por haber perdido. E Isagi al verlo reflexiona y dice: "yo sigo admirando a los que juegan a nivel mundial pero para ti son tus iguales y debes vencerlos".
Mucho cuidado con la admiración.

En otro equipo con el que trabajé, había un chico que pecaba mucho de esto. De hecho él mismo me lo reconoció. Y es que tenía como referente a otro tio que llevaba muchos más años que él en el proyecto, y para él todo lo que le decía era “la verdad”. Pero los referentes también se equivocan. Los referentes te cuentan cómo lo hacen ellos, o cómo lo han aprendido, pero eso no significa que sea la única manera, ni que sea la mejor.


Y ahora, teniendo en cuenta que hacer software es una actividad de grupo, que vamos a trabajar con otras personas inevitablemente, poneos por un momento en el lugar de Isagi:
¿Alguna vez habéis dejado que el ego bloquee vuestro aprendizaje? 


Continuará...

Gracias a Xavi Gost (@XaV1uzz)  y su charla "Aprender a enseñar a programar" por enseñarme a identificar las manifestaciones del ego en las personas de un equipo.

#thisistheway

martes, 7 de noviembre de 2023

Ansiedad VS Motivación: el estado de fluidez

En 2022 toqué fondo, en lo que a motivación se refiere.

Cuando mi jefe de entonces me preguntó por qué quería dejar el proyecto en el que trabajaba como Project Manager, me di cuenta de que mi situación se explicaba sola si te parabas a pensar en los 3 elementos de la motivación: falta de autonomía, falta de dominio, falta de finalidad.

A raíz del análisis de mi propia desmotivación empecé a analizar a las personas de mi equipo con ese mismo enfoque. Los momentos en los que había detectado (o directamente me lo habían compartido) la desmotivación, casi siempre se debía a la falta de dominio.

Decidí retroceder más en el tiempo y recordé otros equipos con los que había trabajado: otra vez la falta de dominio había sido la principal causa de frustración y desmotivación.

Y llegué a 2011, el año en el que pasé por una baja por ansiedad, provocada por la situación en el trabajo. Aunque en su día no llegué a saber por qué me pasó. Lo que conseguí con terapia fue exculparme. Ellos me pedían, me pedían y me pedían y yo hacia lo que podía, pero no era suficiente. 

Cuando lo que te piden esta muy arriba y tus conocimientos muy abajo, aparece la ansiedad.

Ahora lo sé. Mihály Csíkszentmihályi lo supo hace tiempo y lo reflejó en una gráfica como esta:

BLUELOCK 13


Existe una relación entre el reto que nos supone la tarea a la que nos enfrentamos y nuestro nivel de conocimientos. Si el reto es muy sencillo respecto a nuestros conocimientos, caemos en el aburrimiento. Si hay un equilibrio, entramos en la zona de máximo rendimiento, el estado de fluidez. Pero si el reto es demasiado complicado respecto a los conocimientos que tenemos, caeremos en la ansiedad.
Ahí estaba yo en 2011.

Hay ciertos momentos en los que puede ser "normal" o podemos aceptar estar en un estado de ansiedad. Por ejemplo cuando empezamos en un sitio nuevo: un proyecto nuevo, un entorno nuevo, una tecnología nueva... Lo asumimos como normal porque estamos en un periodo de aprendizaje.

Pero qué ocurre cuando pasa el tiempo y ese aprendizaje no avanza. Cuando el nivel de nuestras habilidades no termina de subir lo suficiente como para entrar en la zona de fluidez. Entonces aparece la frustración y la desmotivación.

Primera ley del dominio: el dominio es un estado mental

Desde que empecé a trabajar con equipos, la ausencia del dominio ha sido algo que desmotiva a las personas. Normalmente, generalizando, las personas se daban 2-3 meses para llegar al mínimo nivel de dominio, o MML, que les permitía seguir motivados. Y si en ese tiempo no lo conseguían, entonces llegaba la frustración y la desmotivación. 

El tener que pedir ayuda a cada paso que das, el no ser capaz de resolver los problemas por ti mismo, proyectos con curvas de aprendizaje larguísimas... todo ello hace que la motivación caiga por esa ausencia del dominio. La gestión de la frustración es complicada y lo digo después de lidiar con ella muchos años.

Pero es que además, si permanecemos en la zona de ansiedad demasiado tiempo... acabas teniendo un problema. Y entonces llega la solución del siglo XXI, tomar ansiolíticos. Y si tienes suerte acabas de baja y en terapia.
Porque, seamos sinceros, esto en el mundo del software pasa. Casi todo el mundo conoce a alguien que ha tomado ansiolíticos, o que ha estado de baja directamente.

Ya veis las consecuencias terribles que puede tener un mal sistema de incorporación a un nuevo proyecto, un mal sistema de enseñanza, un mal sistema de aprendizaje.


Dicho esto, hace un tiempo tuve una revelación mientras leía el manga Bluelock. ¡Existen herramientas que nos pueden ayudar a enfrentarnos a ese camino hacia el dominio! ¡No todo está perdido! 
Pero eso os lo cuento otro día :-)

#thisistheway





martes, 17 de octubre de 2023

Desmotivación (agilecobol)

Hace muchos años, en una empresa de informática muy muy lejana...

Una persona que no cumplía con su tarea nunca. Una persona que tenía fama de vaga o "jeta".

La solución del manager fue amenazar, de algún modo quería gritarle todos los días si no había cumplido con la previsión de avance.

Obviamente no funcionó.

En aquella época yo no sabía nada de agilidad ni de motivación intrínseca y me tocó gestionar el equipo donde estaba esta persona.

Cuando me topé por primera vez con la situación de que el trabajo no estaba hecho (a pesar de que siempre que le preguntabas te decía que todo bien) empecé a sospechar que algo no iba tan bien con esa persona.

La segunda vez se lo comenté al jefe (ilusa) y me soltó su técnica de las amenazas.

Sin estar versada en gestión de equipos ni en rrhh sólo pude aplicar el sentido común: ¿cómo reaccionaria yo si me viniesen con amenazas? Pues mal seguro.

Así que opté por otro enfoque.

Le pregunté directamente si le pasaba algo. Porque yo había visto evidencias de que sabía hacer perfectamente el trabajo, incluso lo dominaba, pero por alguna razón estaba en modo "hasta los webs".

Cual fue mi sorpresa cuando me respondió con un gracias.

¿Gracias por preguntarle si tenía algún problema?

Pues sí que lo tenía. Sí que habían pasado cosas que lo habían llevado a ese estado. Pero nunca antes alguien le había preguntado por qué actuaba así.

En esa conversación me contó qué podría ayudarle a recuperar la motivación y llegamos a un acuerdo: yo lo ayudaría a cambiar de rol para hacer algo que lo motivase pero mientras tanto él debía ser sincero conmigo en relación al avance de su tarea.

Y ambos cumplimos. Y al cabo de unos meses cambió a otro equipo, y un tiempo después cambió de empresa para hacer algo que lo motivase aun más.

Lo recuerdo como si fuera ayer porque cuando presentó la dimisión vino a contármelo. Y me dio las gracias por haberle ayudado, por haberme preocupado en entenderlo.

Y ese subidón cuando sientes que has ayudado a alguien que lo necesitaba no se olvida fácilmente.


Podría hablar sobre cómo ese proyecto se fue desmantelando, cómo acabamos siendo 6, yo ya no tenía equipo que gestionar, y la motivación en general estaba por los suelos.

Pero entonces llegó la agilidad...

#thisistheway


martes, 10 de octubre de 2023

Grace Hopper Celebration

 La semana pasada tuve la oportunidad de participar en nuestra "Grace Hopper Celebration" particular, con una presentación sobre el Cobol en la era digital junto a varias compañeras de GFT para todas las personas de GFT España.


Hacía tiempo que no me ponía el gorro de cobolera en el trabajo y la verdad es que me hizo ilusión.

En mi parte empecé dando un dato muy importante: Grace y yo nacimos ambas un 9 de diciembre 💜

Y también hablé, ¡cómo no!, del Consultorio Cobol. Puse algunas estadísticas del blog para mostrar que la gente sigue buscando información sobre cobol en internet, nos siguen llegando visitas, el cobol sigue vivo en la red por todo el mundo.


Este mapa es de los últimos 6 meses. En total ha habido más de 85000 consultas. Podrían parecer estadísticas de hace 20 años, pero no, esto está pasando ahora.

También me hizo mucha ilusión conocer a algunos de los lectores del blog, gente que nos tiene en favoritos o que nos conocen desde hace años. ¡Hacía tiempo que no era "la del Consultorio Cobol"! xD

Mis compis contaron sus experiencias recientes con cobol que incluyen JSON y XML con cobol, cobol en Bitbucket, test automation... lo que viene a ser COBOL in the Digital Era, como bien anunciaba el título de nuestra presentación :-)

Les mando un enorme gracias a las cuatro por pensar en mí para participar en este día de Grace. Susana, Marian, Tamara, Cristina: ¡el mundo entero sigue programando en COBOL!


#thisistheway

miércoles, 13 de septiembre de 2023

Curiosidades COBOL: los límites del compilador.

DEPRECATED!

Con las nuevas versiones de COBOL, como COBOL 6, las cosas han cambiado!


----------------------------------------------------------------------------------------------------------------------

Normalmente un programa no suele alcanzar los límites del compilador (a no ser que seamos muy bestias^^), pero existir, existen.

Alguna vez os habéis preguntado cual es el máxino número de OCCURS que puede tener una tabla interna??? Vamos a ver algunos números curiosos : )

Líneas de un programa:
El nº máximo de líneas que puede tener un programa son 999.999 líneas. Sinceramente, encontrarse un programa así de largo haría que nos acordásemos de toda la familia del que tuvo la idea...

En dos palabras, in-mantenible^^

Ficheros:
El nº máximo de ficheros por programa es de 65.535 ficheros.
Y si tal que haya que cruzarlos!!!

Longitud de fichero:
La longitud máxima que puede tener un fichero en su RECORD es de 1.048.575 posiciones.
Total na.

Variables de working:
La suma de las variables definidas en la WORKING-STORAGE, no podrá pasar de 134.217.727. Lo mismo para la LINKAGE-SECTION.

EVALUATE:
El nº máximo de cláusulas WHEN en un EVALUATE será de 256.
Si que son posibilidades!

PERFORM:
A lo largo del programa sólo podremos utilizar 4.194.303.
Debe ser por si queremos codifcar el programa de 999.999 líneas...

OCCURS:
El número máximo de occurs que podrá tener una tabla interna será de 16.777.215.

USING en la procedure:
Cuando tengamos un programa con LINKAGE SECTION, el máximo de variables que podremos incluir en la PROCEDURE DIVISION USING ... será de 32.767.

Cláusula VALUE:
El total de las longitudes de los valorse incluidos en las cláusulas VALUE no podrá superar los 16.777.215.


Todo esto y mucho más lo podéis encontrar en el apéndice B del manual de IBM
Enterprise COBOL for z/OS and OS/390 IBM
Language Reference