Arquitectura de software puertas afuera

 

Hace ya algunas semanas que me cambié de trabajo.
Los motivos de alguna manera se fueron desglosando desde hace algún tiempo, y obviamente desde la parte de arriba de la pirámide hay cosas entre que se desconocían, que nunca se vieron (o no se quisieron dar cuenta), o que simplemente no se entienden, en fácil sería bueno que analizaran porque se va la gente y en que parte de la historia los stock options perdieron su atractivo inicial y su poder de retención.

Voy a reciclar un artículo que  ha envejecido bastante bien (no ha dejado de perder sentido): La necesaria mirada hacia adentro de la propia organización

La cosa es que entre las cosas que tuve que hacer antes de mi salida, aparte de tener que entrevistar a mi futuro reemplazo y revisar desafíos técnicos, fue proponer un plan de trabajo futuro, porque "me siguen necesitando" sea para  atender consultas varias o para optimizar algunas cosas, pensemos que el "desarrollador senior" de la empresa "que se encargaba de sacar los cachos (desafíos con dificultad mayor a la habitual, y que nadie quiere hacer)" ya no está, y alguien tiene que encargarse de "hacer lo mismo".
Después de una breve negociación llegamos  a un acuerdo que de alguna manera busca ser conveniente para todas las partes. No es un número de horas fijas al mes, el valor HH es menor a mi "precio habitual" pero mayor al propuesto inicialmente; lo que si hay un límite máximo de horas al mes, y precisamente por eso es conveniente para las 2 partes.

Por un lado no me  voy a inventar horas ni sobrecargarme con horas de trabajo, por el otro se pagan solamente las horas consumidas. Es como un plan de telefonía móvil, pero de los viejos, o con tarjetas de minutos.

El escenario de "ponerse precio" nunca ha sido  sencillo. Lo que no se debe perder de vista es que la HH fuera de un contexto de contrato jornada completa debiera ser mayor a la HH bajo contrato.

Hasta el momento aquí no hay nada de arquitectura.

La cosa es que de las tareas que me han sido encomendadas, no hay mucho de lo que no haya hecho en mi tiempo bajo contrato jornada completa. Y estas actividades más que apuntar a la resolución de bugs, apuntan a la la toma de ciertas decisiones de como debiera resolverse un problema, o bien optimizaciones generales a ciertos procesos de los sistemas de la organización, así como a la atención de consultas de temas que pueden exceder la complejidad habitual.
Al final es algo como una consultoría interna con matices de arquitectura de software.

Aquí es donde empezaron ciertos cuestionamientos existenciales respecto a lo que estoy haciendo, y  respecto a como veo el camino que está tomando la organización que  dejo detrás:

• La organización crece, y el crecimiento nunca debe ser interpretado como algo negativo, salvo cuando descuidas tu activo más valioso, que NO son tus datos, NI tampoco tus aplicaciones, sino las personas que  le dan valor a tu organización. Si como líder olvidaste eso, estas condenado a perder gente, y como me dijeron en otra empresa en la que trabajé "Son los buenos los que se terminan yendo".
• Quedan cabos sueltos, o cosas de las que nadie  se va a encargar, y no por falta de capacidad, ni porque se  carezca de las competencias adecuadas. Solamente porque nadie tuvo la voluntad para involucrarse en ciertos procesos, o si queremos ser menos pesimistas en la repartición de culpas responsabilidades, ha sido el día a día el que ganó esta batalla en la que ojalá hubiera alguien más que se dedicara a cubrir requerimientos de la organización que no son otro bug en el sistema.
  Entre estas:
• Actualización y mantención de SW anexo a los desarrollos locales, utilizado para algunas parte  "no tan críticas del sistema".
• Actualización de las versiones de las librerías utilizadas en el desarrollo. De aquí lo que más sufre es Angular, que se va a quedar un buen tiempo  estancado en la versión 15, ya que  demanda que haya otras librerías que se actualicen previamente.
• Actualización de las herramientas utilizadas en el Monorepo. De alguna manera relacionado con lo anterior.
• Control de calidad del desarrollo, buenas prácticas, etc. El tiradero de orejas claramente va a disminuir, porque no hay un área, o simplemente alguien que esté constantemente velando por esto.
• Promoción interna, a modo de publicidad gratuita. Yo siempre dije que la organización estaba haciendo cosas interesantes que iban al menos un par de pasos más adelante que varias de las organizaciones que me ha tocado conocer. Difícilmente habrá artículos técnicos que promocionen lo que están haciendo. ¿Podría hacerlo? ciertamente, pero esa no es la pregunta correcta...
• Desarrollo de nuevas librerías de uso general para simplificar el desarrollo futuro. Sin ir más lejos, un mantenedor de formularios dinámicos. Ese es uno de los grandes temas que se dejó pendiente. 
• Automatización de tareas recurrentes, sea mediante  algún script o desarrollo de alguna herramienta.
• Charlas de buenas prácticas, o show-off de proyectos, librerías o simplemente cosas que tecnológicamente tengan alguna relación con lo que se hace, o que puedan servir en algún desarrollo.

Entonces ¿la organización realmente necesita de un desarrollador senior? ¿o de un arquitecto de SW?
Y aquí es donde voy a opinar en más de un par de párrafos.

¿Qué necesita una organización?

¿Desarrolladores seniors? ¿un arquitecto de software? ¿un área de "arquitectura/infraestructura" (o invento afin)? 

Según yo, una organización que basa su funcionamiento en sistemas de SW que hayan sido desarrollados internamente y que pretenda escalar (léase por lo bajo como atender más clientes), NECESITA que alguien defina el cómo debiera solucionarse el desarrollo, siempre  aspirando a no hacer más complejo el ejemplo de tutorial o del curso online, sino sentarse y pensar en como hacer una mejor implementación, sobretodo si el problema dejó de ser simple.

Y eso normalmente es lo que hace un arquitecto de SW, ojalá en coordinación con los líderes de equipo, quienes normalmente son desarrolladores senior.

Aquí podría surgir otra pregunta, ¿este tipo de organización (mediana empresa con olor a startup), necesita un arquitecto de SW?
Y la respuesta es complicada. Quizás con la llegada de un senior, que viene con una experiencia y una visión mucho más acabada de ciertos flujos, la organización "se ordene", al menos en el sentido del desarrollo. De seguro va a ser  un poco menos "echarle para adelante" y pensar un poco más las cosas antes de sentarse a  vomitar líneas de código y a copiar ejemplos de StackOverflow; quizás... 

Ya sobrevivieron una etapa sin alguien que los ordenara, obviamente eso  se tradujo en código legacy, y una deuda técnica espantosa, pero "echarle pa' delante" funciona, igual que afirmar el acelerador de un auto con un alambre. Funciona...

Volviendo a mis dilemas existenciales, y a ciertas conclusiones que ya he sacado, lo más seguro es que  esta empresa nunca haya necesitado un arquitecto de software, ni un desarrollador senior con  demasiada experiencia.

Claramente no necesitaban, y probablemente nunca necesiten un evangelizador de software que  escriba artículos de que tan interesantes pueden ser los desarrollos internos. Menos a alguien que a través de esos artículos intente convencer a quienes postulen al área de desarrollo  que esta es la empresa en la que pueden crecer profesionalmente. El nivel de valor agregado que esto en particular agrega a una organización va a depender principalmente de cuanto les interesa destacar en el círculo de desarrollo de SW en el que se mueven, o si eventualmente te interesa  destacar en un círculo más grande.

Una vez que probaron tener a alguien experimentado probablemente se despierte esa "comezón" de tener a alguien que te diga "por ahí no, que hay muchas piedras y espinas" y que te mande por un camino más largo, de seguro más empinado, pero con cierta garantía de  poder llegar a destino sin muchos contratiempos, y con la suficiente energía para poder seguir adelante.
O probablemente no, y todos sigan picando piedras igual que siempre.

Es de aquellas cosas donde,  en lo personal, no me queda tan claro que tan compatible con el negocio sea darle cierto énfasis a la calidad del desarrollo de SW. A mi parecer sería lamentable que el time to market siempre fuera prioritario por sobre la calidad del producto entregado, y que tener algo bien hecho sea solamente parte de la esperanza  positiva del flujo de desarrollo. Aquí es donde se sopesa  el  hacer algo bien hecho en 1 semana vs sacar a flote una espantosidad en 3  días; ¿qué tan caro sale no hacer las cosas bien hechas? 

Quizás, bajo determinados enfoques,  hacer las cosas bien esté demasiado sobrevalorado y realmente no valga la pena el esfuerzo.

Entonces lo que quizás siempre  fue mejor era tener un arquitecto de  software puertas afuera, alguien fuera de  empresa a quien puedas consultar sólo cuando consideras que es estrictamente necesario; y asumir el costo de esta consultoría externa.

Con la absoluta  ausencia de humildad de este artículo: 

• ¿Cómo veo mi futuro? Espero que no sea una muerte lenta con buen sueldo, tal y como me  comentó un colega. Pero el salario es competitivo internacionalmente,  y es se nota más porque en general el empresario chileno prefiere profesionales menos experimentados que ojalá salgan baratos. Un gran amigo me dijo que trabajar para una empresa extranjera era algo que yo debí haber hecho hace muchos años atrás.
• ¿Cómo veo el futuro de la organización que dejo a un lado? Les toca un camino de maduración posiblemente algo agreste, lleno de aprendizaje. Ojalá las jefaturas se involucren con lo que se hace, sino esa desconexión les va a penar y pesar. Falta cambiar el lente para mirar desde una perspectiva diferente a la de una jefatura ya que no todo es "el negocio".

ChatGPT vs Desarrolladores junior

Hace algunos días atrás hablaba con un alumno en práctica que estuvo apoyando algunas de las cosas que hacemos. Me contaba sobre sus clases, en particular por el curso de #inteligenciaartificial que le toca este semestre. Según me decía, el profesor está muy en el hype de #ChatGPT , y les dio un discurso muy poco alentador.

Se refirió a los #desarrolladores "junior" con muy pocas esperanzas en el #mercadolaboral ya que según su visión:

"Los desarrolladores senior ahora van a resolver las tareas sencillas, que antes encomendaban a los desarrolladores junior, a través de una consulta hacia alguna #IA ."

En mi opinión, y probablemente con muchas menos credenciales académicas que el profesor, es que estos dichos son una afirmación que bordea lo irresponsable, por 2 grandes motivos:

1. ChatGPT es un chatbot que utiliza un #LLM (Large Language Model), y la calidad de las respuestas tiene una correlación directa con la calidad de los prompts. Si la pregunta esta mal planteada, es esperable una respuesta de baja calidad. Peor aún, sin la debida auditoría y revisión de las respuestas generadas, existe una probabilidad no menor que nos enfrentemos a respuestas de ChatGPT que son imprecisas, o incluso en un peor caso, derechamente erróneas.
2. Un profesor, académico de una universidad, de alguna manera es responsable de buena parte de la formación hacia el camino profesional de sus alumnos. Dicho esto, un profesor debiera (a lo menos como deseable) impulsar a sus alumnos en la carrera que hayan elegido, no a través del #FUD (Fear, Uncertainty, Doubt) sino motivándolos en la profundización de las materias. Alumnos en un promedio de 21 años de edad no necesariamente tienen la madurez suficiente para procesar de buena manera un discurso donde en resumen les dices que tras 4 años de estudio probablemente no hayan hecho la mejor elección.

Efectivamente hay mucho de idealista en mi visión sobre los académicos, sin embargo, tratando de ponerme en ese rol, me veo más como un mentor que como alguien que finalmente no está comprometido, más allá de lo laboral, con lo que está haciendo.

Y fue larga la conversación después. Traté de brindarle cierta tranquilidad, explicándole que ChatGPT, así como un buen número de chatbots, son antes que todo HERRAMIENTAS, así como un serrucho o un martillo, pensadas en ASISTIR a los usuarios que generamos prompts.

Llegamos a la pregunta, a estas alturas existencial, ¿qué es la inteligencia? o si la reformulamos ¿qué entendemos por inteligencia? Y podemos llegar a una especie de respuesta (muy incompleta por lo demás), que probablemente NO nos dejará tranquilos:

"Entendemos por #inteligencia a la capacidad de recopilar, interpretar, entender, relacionar y procesar #información , de modo de poder generar respuestas coherentes a preguntas bien fundadas."

Entonces, bajo esa definición ChatGPT es "inteligente", sobretodo considerando la cantidad de información con la cual fue alimentado el modelo, y la velocidad con la cuál es capaz de entregar una respuesta a una buena pregunta. Nótese que estoy hablando simplemente de respuestas y no implícitamente buenas respuestas.

Y también tocamos un poco de antecedentes históricos. La revolución industrial, y más adelante las cadenas de producción de Ford (1910-1920) generaron inquietud entre los trabajadores:

"¿Las máquinas nos van a reemplazar?"

Imaginen cuál fue la sensación de los trabajadores de General Motors cuando se implementaron las 1eras cadenas de producción usando robots de ensamblaje, a eso de 1960.

Probablemente ya nos estemos enfrentando a una nueva revolución industrial.

Como resultado de esto estuve leyendo bastante; aparte que los contenidos curados de varias newsletters a las que estoy suscrito me bombardearon con el tema; y llegue a 3 recursos que quisiera compartir:

1. El primero, https://loige.co/the-senior-dev/ , lectura extensa y sin embargo lejos la mejor visión que he leído últimamente de lo que es y hace un #desarrolladorsenior .
2. El segundo es uno de los tantos artículos que trata de "entregar tranquilidad/generar inquietud" respecto a la pregunta si las IA van a reemplazar nuestros puestos de trabajo; a estas alturas el tema se ha vuelto un cliché clásico entre muchos quienes escribimos un blog: https://levelup.gitconnected.com/are-programmers-getting-replaced-by-ai-gpt-4s-top-strategies-to-future-proof-your-coding-career-a5a2d4ba95ed
3. Y finalmente el tercero es un video de #IBM (un santo que no es de mi devoción por otros motivos): https://www.youtube.com/watch?v=r4kButlDLUc Risks of Large Language Models (LLM), o como me gusta decirlo a mi "Dónde se caen los LLMs y porqué puede que no sean la herramienta que necesitas".

Para muchas gerencias TI ChatGPT se ha vuelto un poco como los microservicios, todos creen que son la solución y respuesta a todos los problemas de desarrollo de una organización, y tienden a pasar por alto los muchos problemas y dificultades que puede significar su adopción de manera impulsiva e irresponsable.

Seguramente habrán escuchado o leído la frase:

"Cuando la única herramienta que tienes es un martillo, todos los problemas parecen un clavo."

Al paso que vamos ChatGPT (y en general todos los chatbots entrenados con algún LLM) se están empezando a convertir en el único martillo que muchos quisieran ver.

Enamoramiento y desencanto laboral

Amo mi trabajo... la pregunta es cuanto dura el enamoramiento

Muchos de los artículos que he escrito apuntan al como me gustaría; dejemos inmediatamente claro que es una cosa personal y no algo que necesariamente  vaya a ocurrir; que una empresa "reaccionara" después de que se va gente. Pero ¿qué pasa cuando el escenario se  invierte? y a esto voy cuando es la empresa la que por diferentes motivos debe desvincular  funcionarios.

Pongámonos en el contexto  actual Febrero 2023, o derechamente finales de 2022, inicios 2023; muy a grosso modo.

• Pandemia (el COVID sigue activo por si se habían olvidado)
• Guerra en Ucrania (mi opinión hacia los rusos no es precisamente lo mejor)
• Economía mundial en recesión

Elon Musk, Robert Kiyosaki entre muchos otros ya han anunciado que el 2023 se nos viene duro, así que no es sorpresa lo que ha sucedido en muchas empresas, no sólo en Latino-américa, sino a nivel mundial.

Ya vimos lo que pasó con Betterfly, que al final fue un "better fly", literalmente dejaron volar al 30% de su planilla de funcionarios (o colaboradores, como les gusta decir a las empresas de la nueva era), una catástrofe que fue muy bien adornada con la dolida carta de su CEO.

Digamos que los movimientos de gente, en cualquier organización, los quieras mucho, poquito o nada, te sumen o no te sumen, los movimientos de gente inquietan a las tropas. Esa incertidumbre de no saber que es lo que puede suceder mañana, sobretodo cuando los equipos se desarman, es uno de los caminos al burnout.

Burnout...

Entonces, como  una de las consecuencias de este movimiento de tropas, todo ese enamoramiento, todo eso que  te encantó, aparte del jugoso sueldo y los beneficios, todo eso que te motivo a estar trabajando donde estás, todo eso que te motivaba a despertar animadamente  cada mañana para ir al trabajo, se empieza a desvanecer.

Burnout..., te "empezaste a quemar" con tu trabajo, ganas de hacer nada, absoluta desmotivación, tu ánimo baja, tu actitud cambia negativamente, empiezas a cuestionar si los valores de la empresa están efectivamente alineados con los tuyos, te preguntas si ese discurso de las áreas de bienestar y RRHH (que a veces no existen) es de verdad o es la chapa para que se vea lindo. Eso pasa cuando los equipos se empiezan a  desarmar, sea porque se van yendo de a poco o porque los van yendo de a poco.

Si a eso le sumamos jefaturas inexpertas, o resultados de una meritocracia (o incluso parentesco), o cuyo liderazgo esté sostenido no por el carisma sino por el miedo que infunden "es que el/ella es el/la jefe/a". Cuántos se han callado denuncias sobre jefes abusadores por temor a quedarse sin trabajo, o incluso por represalias tipo bajarles las comisiones de ventas (por ejemplo). En ese sentido hay jefes a los que  no les importa liderar equipos, sino simplemente dirigir subalternos, y la diferencia es mucho menos sutil de lo que parece. Y claro, puede que como empresa necesites un tigre, pero mínimo esperar que ese tigre no se coma a tu gente (o que te genere otro tipo de problemas).

Y finalmente el discurso. En lo personal, la consistencia en el discurso es algo que valoro demasiado. Si me dices que se va a mantener blanco, te voy a creer, pero si me pintas todo negro después, pasan varias cosas:

• Empezando, mi confianza en ti (pensemos en la confianza que puedo sentir hacia una organización) se va al carajo. 
• Todo lo que me digas pierde credibilidad.
• Me empiezo a quemar más. Y quemarse con alguien no es bueno, por lo bajo, te hace perder objetividad, entre otras cosas.
• Me siento traicionado.

Tratando de  explicarlo con un ejemplo:

Es como cuando eras pequeño y le decías a tu mamá que querías un helado y te decía que no porque "no tenemos dinero para comprar helado", y esa misma semana tu mamá llega con un par de zapatos nuevos que se había comprado.

Da lo mismo si había una reserva de dinero para los zapatos de mamá, o si los zapatos sí  estuvieran en la lista de necesidades y prioridades (no así el helado). La cosa es que te  dijeron que no había dinero y resulta que sí había dinero.

No digo que laboralmente sea diferente. 

Probablemente hayan mil y un antecedentes que "el pueblo" no maneja, y las decisiones que se tomen efectivamente  tengan un soporte sólido que sólo manejan las jefaturas (básicamente de quien dependen las decisiones finales). Pero si para sostener que la empresa debe reducir personal, el argumento es que estás fuera de presupuesto, o que tenemos que ajustarnos el cinturón por la recesión, no puedes en esa misma semana estar contratando gente, o incluso tener posiciones abiertas ¿no qué estábamos reduciendo personal porqué no hay presupuesto?

En el caso que  ejemplifico, puede que efectivamente las nuevas contrataciones estén debidamente justificadas, sin embargo ¿cuál es el mensaje que le entregas al resto de tu organización? 

Déjame responderlo: Tu discurso es inconsistente. Da lo mismo que sea incompleto porque no  quisiste, no puedes, o incluso porque simplemente olvidaste mencionar los puntos de excepción; tu discurso ES inconsistente; dijiste algo, hicieron exactamente lo contrario.

Y eso te quema. Prepararse para ese escenario en que alguien (en algunos casos un mismo) tendrá que absorber y asumir todo aquello que se podía asignar a quienes ya no van a formar parte de tu equipo también quema. 

Quema el siquiera pensar que los niveles superiores de la pirámide organizacional (imagen sacada de este otro artículo mio) están considerando muy por encima el impacto de desarmar los equipos (más si lo sumamos a la inconsistencia del discurso). Quema más pensar que probablemente les interese un carajo el impacto de desarmar un equipo porque "es parte del crecimiento de la empresa". Quema...

Y entrar en esa fase de desencanto, duele por dentro,  quema, y quemarse  no es bueno. He estado ahí.

¿Será que es el momento de dar vuelta la página? y pongo las cosas en la balanza, y me resisto a evaluar esa opción, y espero no sea un error...