Me "ghostearon" como asesor externo

El término "ghostear" es la verbalización de la palabra ghost en inglés que significa fantasma. Y normalmente aplica cuando en una comunicación no presencial, ejemplo correos, mensajería, redes sociales, etc., de manera súbita tu interlocutor  literalmente desaparece del mapa, haciendo que todo  intento de contacto se pierda en el infinito.

Literalmente te hacen un > /dev/null

Bueno, les cuento la historia.
Nota al margen: Ojala no se aburran porque yo no creo en la historia corta, me voy a dar mil vueltas, voy a explicar mil cosas antes, y seguro va a parecer que me olvidé de lo que tenía que contar.

Algún tiempo atrás (en una galaxia muy lejana) me contacta un ex-compañero de trabajo, a quien le hice  más de un par de asesorías. La típica "¿en qué estás?" y "¿qué disposición tienes para  un trabajo extra?". La verdad es que el espíritu del mercenario nunca me ha abandonado, y el desafío se veía entretenido. Días después me contacta la jefa de proyecto que trabaja con él y me dice que "me vendieron" como alguien que puede solucionar cualquier problema. Debo confesar que la falsa humildad evita que yo me venda de esa manera, sin embargo mi arrogancia interna sabe que la maldita combinación de  inquietud intelectual y TOC normalmente  conducen a soluciones.

Trás un par de conversaciones acordamos una tarifa  x HH y me presentaron formalmente el desafío: Un sistema de facturación electrónica, cuyo backend está en Java con Spring Boot y el frontend en Angular.
Mi misión (que obviamente decidí aceptar) corregir/mejorar/hacer funcionar el formulario principal en la aplicacion Angular. Mi intervención sería solamente en el front. 

Diagnóstico inicial

Trás una revisión del código me quedaron claras varias cosas:

1. Quienes estuvieron a cargo de  hacer las definiciones iniciales no conocen bien las capacidades del framework (Angular).
2. La escuela inicial es Java, y si bien es cierto hay similitudes conceptuales entre la programación Java y Typescript, hay diferencias. No es llegar y traducir las estructuras. Hay cosas que se resuelven de otras maneras (GOTO 1)
3. Delegaron el desarrollo de partes sensibles de la aplicación a pollos digo.... desarrolladores menos  experimentados, ergo el desastre que empecé a ver en el código:
• Repetición de funciones.
• Funciones con múltiples responsabilidades (al bosillo la S de SOLID).
  
• Cero comprensión de los requerimientos, derivando en código  enredado, desordenado y complicado para requerimientos sencillos (golpeando a la fuerza con un martillo siempre se puede meter una pelota en el espacio de un cubo).
• Cero estándares de programación, desde la manera de nombrar las variables y funciones. indentación, tipo de comillas, etc.
• Cero documentación, sobretodo en aquellas partes "complejas".
• Desconocimiento importante de los conceptos básicos de OOP. 
• Desconocimiento de patrones de diseño.
  
• UN SÓLO gran componente con TODA la lógica de negocio en él. Más de 800 líneas de código, toda una obra de arte.
• Ausencia de una política clara de control de versiones. Usan git, así como  usamos calcetines.
  

Iban a ser jornadas de muuuucha diversión.

Cuando pesan las decisiones del pasado

Y no a mi en este caso. 

Empecemos:
Angular no es un framework sencillo. Tampoco es que sea taaaan complicado, pero no es sencillo, hay una base de OOP importante, y se le saca provecho en proyecto complejos (como el de este equipo), y más aún cuando hay conocimiento del framework.

Por ejemplo, uno de los pecados mortales que encontré, escribieron, o más bien arrastraron un servicio completo que extiende el HttpClient y agrega el token JWT de cada petición. ¡Sí! va a funcionar, pero... el HttpClient de Angular tiene soporte para los Interceptors, que van a actuar como middleware y pueden modificar las peticiones, no es necesario usar un httpGet propio que  agregue el token JWT a los headers. Lo peor de todo no fue tanto que lo arrastraran, sino que para peor, NO lo usaron en ningún lado y que cada una de las peticiones del sistema agregaba a mano el token.

Otro pecado mortal, servicios viejito, servicios... Salvo algunas contadas excepciones, claramente desarrolladas por otro pajarito (al menos eso decía el git log) TODAS las peticiones estaban dentro del giga-componente.

A ver, muy a grosso modo (siempre en el contexto de Angular):

• Componente: Unidad modular, habitualmente "tonta", sólo se encarga de desplegar información y reaccionar a ciertos eventos. No tiene lógica de negocio.
• Servicio: Es quien se encarga del "trabajo sucio". Los servicios saben que es lo que se tiene que hacer. Aquí hago una pequeña distinción, porque saber que se tiene que hacer es diferente a saber como hacerlo. Entonces tenemos 2 tipos de servicios que caerían en esta definición:
  
  • Facade: Fachada, que sabe que se tiene que hacer
  • Servicio (implementación específica): Sabe como hay que hacer loque se tiene que hacer.
    Y si, los 2 son servicios...
    

Y aquí seguro explotaron algunos cerebros, las cosas dejan de ser sencillas. Ya nada es como el tutorial de la PokeAPI o como el proyecto del Bootcamp.

Pero no sufran tanto, voy con un ejemplo.
Supongamos que su componente tiene que traerse datos desde "algún lugar", la respuesta que  reciben y saben procesar siempre tiene la misma forma (tipo de datos conocido), solo cambia el "desde donde" se van a traer los datos. Entonces el instinto te dice:

"Ahhhh! un servicio que tenga 2 metodos:

1. getDataHttp()
2. getDataLocal()"

Y si, va a funcionar, pero se acuerdan de la  O de SOLID, Open-closed principle abierto a la extensión, cerrado a la modificación, vale decir que si el comité creativo se le ocurren 20 origenes de datos diferentes, o te llenas de funciones  o te llenas de ifs.

Lo más razonable en términos de arquitectura es ver una implementación tipo Strategy o Factory, donde todo el resultado de tener un conexteto acotado

Nos fuimos a la B... no compa, me hubiera dedicado a la pastelería...

Y acá si me pongo a desarrollar el tema puedo escribir demasiado, SOLID da para  mucho.

Bueno, de SOLID el desarrollo base las pelotas. La idea me dio la sensación que fue buena, pero en la medida que pasó el tiempo y que no supieron mantener la consistencia en el código (y de paso de mantenerse al día cono cómo se desarrollaban los proyectos en cada nueva versión de Angular) los destrozos eran algo de esperar.

Entonces nuevamente se juntan los ingredientes claves para que Santa cobre caro y tenga  pega el desarrollo de un proyecto se empiece a volver caótico:

1. Bases mal definidas
2. Escaso conocimiento en el Framework
3. Equipo poco/mal capacitado

Si todo lo que pudiste decidir mal; por que no sabías o no te  supiste asesorar, o derechamente no te asesoraste ni investigaste; lo decidiste mal,  y seguiste una formula "conocida" que funcionó alguna vez, de seguro todas esas malas decisiones te van a cobrar factura después.

¿Qué fue lo que hice?

Literalmente lo de la imagen. El formulario principal era inicialmente un caos del que era cosa de gastarse unos minutos, dibujarlo a mano en papel y darse cuenta que se podía separar en componentes mucha más sencillos. 

Claro que alrededor tocó generar nuevos tipos de datos, definir servicios, extirpar funcionalidades, optimizar algunos procesos, ordenar el código, ordenar el código... Cuando visualicé la separación lógica para esto empecé a recortar el original, cada  "bloque" en su propio componente. Documentación adecuada, explicaciones a ciertas implementaciones oscuras, poco a poco  fue tomando sentido.

Pero no estuvo exento de dolores de cabeza, cosas que me hicieron pensar "¿Pero porqué este animalito  lo hizo así si <explicación razonable que hasta ChatGPT  indica sin fallas>?"

El plazo de entrega  era acotado, me demandó una jornada continua de 12 horas de programación, y finalmente  pospusieron esa reunión. Hubo algo de espacio extra para afinar detalles y de paso me pidieron "un extra".

El extra

Necesitaban que el generador de documentos funcionara. 

Contexto:
Los documentos tributarios electrónicos (DTE) pueden ser de diferentes tipos, factura, factura exenta, factura de exportación, boleta, nota de crédito, nota de débito y más de alguno que se me debe estar olvidando. Cada uno de estos tipos de  DTE se identifica con un código específico, y si bien comparten en forma muchas de las propiedades del documento, también difieren en algunas propiedades, según sea el tipo de documento. Eso ¿les da algún indicio de  por donde puede ir la cosa?

Vamos por parte:

1. Documentos "parecidos en forma"
2. Documentos "parecidos, pero con ciertas diferencias"
3. Documentos identificables según su tipo

Mi opinión se vuelve  algo sesgada (biased) al respecto, pero

¿tiene pinta de OOP o no tiene pinta de OOP? 

Y acá me pusieron pila, la idea era hacer un generador relativamente simple, relativamente fácil de entender y extender, pero por sobretodo una implementación elegante/medianamente elegante (aunque considerando la base casi cualquier cosa era mejora).

Entonces generé un estructura parecida a esta:

Entonces a través de un Factory rescataba la implementación  especifica para el documento que  quería generar. La interfaz del Documento me  indicaba los métodos que cada implementación  debía implementar. Eso más un Builder para poder generar instancias de cada documento usando los datos de cada sección del formulario, y  un Adapter para poder ajustarlos en forma para que el objeto sea "compatible" con lo que sabe manejar el backend.

Eso más mucha magia de Typescript, que también es algo que me llama demasiado la atención, y dentro de todo experticias que siempre fueron necesarias en este desarrollo.

Todo documentado, código "bonito" (y no porque lo diga yo), hasta un video les hice para explicar el proceso de la implementación. Claro que no profundicé en los patrones de diseño usados, eso literalmente da para un curso de  un semestre de universidad, y revisando el video un par de veces (no porque me guste el eco de como resuena mi propia voz) el video no es taaaaaaaan simple de entender, no sin una base medianamente sólida de OOP.

Quemé  más de un par de neuronas en el proceso.

Finalmente -> me "ghostearon"

Después de  caerse de espaldas con la factura que les mandé, porque no les salió barato (siendo que me aceptaron el precio x HH y que trabajé efectivamente cada hora que cobré) me consultaron si podía generarles un "proyecto base".

¿Qué sería este "proyecto base"?

De acuerdo a las mismas palabras de la JP "es un proyecto que tenga lo básico para poder empezar un proyecto, incluyendo buenas prácticas, etc."

Independiente de si trabajana o no en desarrollo de software es claro que TODOS los proyectos son diferentes, por mucho que estén basados en el starter-project, que de alguna manera busca ser esto.

Respecto a los starter-project, la idea no es mala, pero si tienes un triste precedente  de que aún con  ciertos lineamientos (buenos o malos, eso da lo mismo) de estructura de proyectos, tu equipo hizo un desastre, entonces por muy buenas prácticas que quieras poner en este starter-project  van a dejar el caos igual. Seamos realistas, por iniciativa propia un equipo rara vez se dedica a entender y aprender de  las buenas prácticas de un starter-project; habitualmente es un programemos encima a lo brutito, y si no hay un área de arquitectura que audite el desarrollo o una cultura de peer reviewing, no hay manera de sostener una arquitectura limpia.

Propuse en cambio capacitar al equipo, enseñarles  cómo se deben hacer las cosas, o quizás no exactamente el "cómo" que  puede resultar una posición impositiva, sino más bien qué enfoque se debe adoptar para poder llegar a una buena solución de software (mantenible, escalable, entendible, elegante...). sostuve mi propuesta con los argumentos que ya mencioné.

Y literalmente fue lo último que supe de esta empresa.
Llegó a ser  irónico pués  me  quitaron los accesos a los proyectos en git, salvo uno, y  ni siquiera me contestaron cuando se los indiqué.

¿De quién fue la culpa? (no eres tu soy yo...)

Mi 1er sospechoso es un poco la cultura de empresa, y esa mala valoración que le dan al trabajo y tiempo experto. Aquí yo sé que cobré caro, es la tarifa consultor habitual que suelo cobrar, precisamente porque me encargo que el producto que entrego valga lo que cuesta. 

Aquí tengo el ejemplo donde en cierta oportunidad quisieron negociar mi tarifa  x HH de consultoría  de manera equivalente a la HH a contrato de plazo fijo. En esa oportunidad mi cara de ¿cómo te lo explico sin que te sientas ofendido? fue épica.

Y mi 2do sospechoso fue  una frase final dentro del video donde explicaba la implementación del generador de documentos. Si volvemos atrás en este artículo nos daremos cuenta que  el generador es básicamernte contexto teórico, no hay nada que sea exclusivamente de frontend, por lo que puede ser  fácilmente aplicado al backend y lo más seguro es que  tenga los mismos beneficios relativos a la arquitectura de la solución.

Textualmente dije "...en vez de llenarnos de ifs, utilizamos  orientación a objetos como corresponde, hacemos distintas implementaciones y se nos simplifica infinitamente la existencia."

Me salió del alma ese cierre para el video. Ese tipo de verdades sin anestesia que no nos gusta escuchar sin decoración bonita.

Decirles a desarrolladores senior que programan en Java que no saben OOP y que no saben de  patrones de diseño es tan ají en el culo como decirle a un taxista que no sabe manejar... bien...

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...

Ofertas laborales: Lo siento, no tengo tiempo para responder tu desafío técnico

 

Cuánto sentido me hace este artículo que leí hace poco:  

Why I Don’t Have Time For Your Coding Challenge

A la fecha llevo 1 año y 5 meses trabajando para una empresa, y parte del flujo de contratación de desarrolladores involucra una prueba técnica. No es nada de la Nasa, pero tampoco es trivial.

Cuando recién postulé, paralelo lo hice a  otra empresa y, tras una entrevista personal, pedían resolver un desafío técnico que me tomó cerca de  7 horas resolver.

Por una cosa personal me dije responder el desafío y hacerlo con todo lo recomendado:

• Buenas prácticas
• Documentación
• Código versionado
• y otras originalidades que se me ocurrieron en el camino

la idea era que aún cuando estaba, a sabiendas, cumpliendo sólo el 50% de lo requerido, mi postulación destacara al menos por sobre la media. Y el resultado, me informaron que pasé a una nueva entrevista, para la cual nunca me llamaron. 7 horas de trabajo gratis, sólo para el regocijo personal de haber hecho algo bien hecho... Ni siquiera un feedback de porque no resultó (en realidad  aún no se de ninguna empresa que  entregue feedback a aquellos entrevistados que no fueron seleccionados).

Como ya mencioné, la empresa para la cuál trabajo también hace este tipo de pruebas de selección. Y por esos misterios que a veces resulta mejor no saber, en mi caso bastó con presentar y explicar algunos de los litros y litros de código que había hecho. Mi actual jefe me hizo pregunta de la prueba técnica, y si mal no recuerdo le di al menos 3 formas para resolver el problema.

Ahora que ya llevo tiempo en la empresa, y ahora que lo pienso también, en realidad no tengo tiempo para desafíos técnicos. Y es sencillamente porque, a menos que en realidad me interese  demasiado la posición a la que estoy postulando, difícilmente hay salarios que valgan tanto la pena como para sacrificar tiempo de familia, ocio y descanso. 

Pensemos objetivamente (ojalá  toque un empleador leyendo esto): 

1. Un postulante ya trabaja en el área, seguramente  toda la semana viendo lo mismo ¿pedirle qué siga codificando fuera de horario?
2. Un postulante está buscando trabajo, y lo más seguro es que tenga al menos 3 o 4 postulaciones en curso. Lo más seguro es que al menos 2 de las áreas  creativas  ya estén solicitando que se respondan  desafíos técnicos. ¿Punto 1 multiplicado por n?
   Estamos claros que esto no es problema de ninguna empresa, pero esto no transmite  precisamente la mejor de la imágenes respecto a la cultural empresarial, si te piden que  para postular   sacrifiques  tiempo propio, ¿qué puedes esperar si te contratan?
3. Hubo una época que proliferaron ofertas de la India para responder tu test técnico para entrar a Facebook, Amazon, y Google,  era algo así como "x 60 USD  te aseguro que  quedas seleccionado". Un desafío técnico "para la casa" no da garantías que quien postula efectivamente lo haya resuelto, y aprender a explicar  código ajeno puede no ser  trivial, pero tampoco es  ciencia de cohetes.
4. Una entrevista técnica bien hecha (por alguien del área técnica) debiera ser suficiente para juzgar las competencias de un candidato. Resolver un desafío  de código breve in-situ es incluso ilustrativo del cómo piensa cada candidato para resolver un problema, esto es ¿cómo resolverías blah...? pseudo código, diagramas, etc.
5. Las entrevistas, en general, tienen intrínsecamente un factor intimidatorio, y buena parte de quienes hemos escogido este camino, somos de naturaleza más bien tímida (se pasa con los años...).  Dicho esto, si quiero conocer a alguien, mejor pedirle que hable de las cosas que ha hecho, con las que está familiarizado y de las que le resulta  natural hablar. Qué te expliquen código, o te muestren proyectos propios o en los que hayan participado es mucho más ilustrativo de las competencias de un candidato que forzarlo a resolver una prueba técnica.
6. Alguien tiene que revisar las pruebas técnicas. Supongamos un escenario imaginario optimista, más de 100 candidatos en total, y de esos 100 más de 40 respondieron la prueba técnica (de nuevo, optimista...). Yo fui ayudante de un curso de computación en una universidad, cursos de más de 40 alumnos, me tomaba una semana revisar los trabajos para la casa. 
   La empresa ya destinó tiempo para las entrevistas, ¿porqué mejor no aprovechar de buena manera ese mismo tiempo?
7. Si un candidato pasa el desafío técnico, es contratado y no rinde como se espera; como empleador; lo vas a terminar despidiendo igual. Los 3 meses a prueba antes del contrato indefinido no son un costo ni un riesgo que no se haya considerado, y los desafíos técnicos no van a disminuir la probabilidad que te equivoques en una contratación.

Y así podría estar mucho rato escribiendo sobre el tema. Los desafíos técnicos no son la forma adecuada para seleccionar desarrolladores. Hoy en día a menos que seas un estudiante  sin mucho que hacer en tu tiempo libre, te dediques a participar activamente en hackatones como si fuera un deporte, o que tu hobby sea escribir código (hay casos raros a sí de extremos), el costo personal de  responder un desafío técnico es muy alto, tiempo que nadie te paga, y que no vas a recuperar.

En lo personal una entrevista que la lleva completamente un reclutador sin conocimientos técnicos, y que además implica una prueba técnica, me levanta las alertas inmediatamente. Lo más probable es que no sea la oferta que estoy buscando (o que  deba mirar), y probablemente tampoco tenga  una oferta salarial atractiva.
Normalmente (sé que no es bueno generalizar, pero son años de experiencia viendo lo mismo, de una u otra forma)  las empresas cuyos procesos de selección van casi completamente definidos por una prueba técnica son empresas con olor a auto nuevo, que buscan al "recién egresado más competente y más barato de la actual generación". Ahí los viejos mañosos, caros y sobre-calificados, no tenemos cabida, y por eso se agradece cuando una empresa se arriesga con uno y valora la experiencia de eso que han llamado "ingeniero de desarrollo senior".

Plebiscito de Octubre 2020: ¿Apruebo o Rechazo?

 El paso de los meses lo hace inminente, se acerca el ya pospuesto plebiscito de Octubre 26, 2020 en Chile, donde la ciudadanía va a votar para determinar si  se APRUEBA la moción para la creación de una Nueva Constitución, bajo el alero de una Asamblea Constituyente, o si derechamente se RECHAZA.

Las opciones, como ya se podrán imaginar son:

• APRUEBO: Para aprobar la iniciativa
• RECHAZO: Para  rechazarla

No hay ciencia de cohetes en eso. Ahora, si  volvemos en el tiempo a 1988, el 5 de Octubre se llevó a cabo el plebiscito que  definiría el retorno a la democracia, después de 17 años de dictadura. En esa oportunidad se votó SI, para continuar con el "gobierno" (comillas intencionales...) del general Augusto Pinochet, y NO para  volver a la democracia. 
No puedo no pensar en que  las opciones  APRUEBO y RECHAZO, se denominaron así para no  desempolvar los fantasmas del pasado, que  muchos no han sabido dejar atrás; aunque obviamente el contexto es diferente y, en este caso votar SI (APRUEBO), es la opción "de los buenos"y votar NO (RECHAZO) la "de los malos". Sobre-simplificando, de una manera sumamente populista,  tenemos 2 bandos:

• Los "buenos", que quieren un cambio
• Los "malos", que quieren que todo siga igual

Pero tratemos de ir un poco más allá de esta burda separación.

¿Necesitamos una nueva constitución?

Partamos por que, sin conocimiento político ni leguleyo concreto, tenemos una Constitución  que data de 1980, es decir plena dictadura, y uno de sus ideólogos fue Jaime Guzmán. Una Constitución muy acorde a la época, y sin embargo en muchos aspectos garantista, en cuanto a los derechos humanos (en serio léanla, son 120 páginas de  sana diversión).

Entonces, si es de dictadura es mala (cuco, odio, satán, diablo, caca, malo malo)

En realidad, y nuevamente desde el punto de vista de un weón que no es político, ni entendido, no, no es que la wea sea mala. Los tiempos cambiaron, Chile cambió (aunque arrastra una generación entera de weones trancados), las necesidades cambiaron, la REALIDAD cambió, ya no estamos en los 80s, lo que excepto en aspectos musicales, es bueno, es bueno estar en el siglo 21.

La democracia, y el tiempo fue revelando que la Constitución del 80, es incompleta, y en muchos sentidos, muy pro ciertos intereses de ese porcentaje de la población que tiene más poder, sea adquisitivo, político o empresarial; eso obviando también aquellas  secciones donde la visión de los 80 termina siendo retrógrada. Entonces no es solamente el código de aguas, la plata de la AFP, el porcentaje máximo convencional, o el derecho al aborto, o como queramos decorar y referirnos a esa casi interminable lista de cosas que "no se pueden hacer" porque son declaradas como inconstitucionales, y obviamente el motivo de la corredera en círculos persiguiéndose la cola de todas las momias legendarias que  deciden en la corte lo bueno y lo malo desde el punto  de vista legal..

Pero ¿y el estallido social?, la gente está descontenta

Si, y no fueron los 30 pesos del alza del pasaje del Metro, que por cierto lo subieron igual por si alguien no se dió cuenta. Fueron años de rabia acumulada en que un país entero avanzaba en el tiempo (y sigue avanzando), pero bajo estándares de siglo pasado (literalmente).

Si bien es cierto se hicieron reformas a la Constitución, y las leyes, y bajo una impresión que siempre todas estas modificaciones protegen al empresariado y no al pueblo, estas siguen sin ajustarse a la realidad
país actual.

Dicho eso, resultado estallido social, un manoseo excesivo de la palabra DIGNIDAD, y destrozos. El presidente Piñera se refirió en algún momento, y de manera bastante desafortunada por decirlo de alguna manera, como "Estamos en guerra contra un enemigo poderoso e invisible". Quienes alguna vez pasamos por Plaza Italia después de alguna manifestación podemos dar fe de un escenario de guerra. Lo único que faltaba  era un par de edificios semi-derrumbados y  montones de cadáveres en el suelo. Una violencia desmedida, que efectivamente  es reflejo del descontento social, pero que no justifica una zona entera de la capital totalmente inhabilitada para todo. Gente que  perdió sus trabajos, que  vió desvalorizadas sus propiedades, que se vió obligada a  encerrarse (fuera de un escenario de  pandemia)  en sus casas. Demandas legítimas, SI, sin duda,  y que sin embargo se ven empañadas por destrucción.

Las nuevas generaciones  no tiene sentido de la propiedad, el país no es de ellos, sino de aquellos con poder, aquellos que hay que destruir y perjudicar, siendo que romper un paradero, o un semáforo no  daña al gran empresario, sino que daña al trabajador que ya no tiene donde tomar la micro para poder volver a su casa después de trabajar. El país es de todos nosotros, los que nos descrestamos el lomo trabajando para tener lo poco que podemos tener.

No justifico la destrucción, la parte triste de la historia es que para poder reconstruir tienes que  saber echar abajo.

Efectivamente, NO ES LA FORMA. Nuevamente un problema que se arrastra de una "cultura" (comillas intencionales) tercer-mundista, donde si el pueblo no patalea con destrozos, el gobierno, o las esferas de poder, no reaccionan.

Entonces, ¿necesitamos una nueva constitución?

Seamos realistas, por mucho RECHAZO que haya v a ganar el APRUEBO. Y aunque gane el APRUEBO, el proceso de  una nueva Constitución se va a demorar por lo bajo 4 años, o sea con fé el 2025 recién se va a ver  alguna luz del resultado de este proceso.

Y me preocupa que la Asamblea Constituyente, sea constituida por gente que no está debidamente capacitada para definir una Constitución, gente que conozca la actual Constitución, que la entienda, y que pueda definir algo mejor que lo que ya hay, porque otro elemento a considerar, se  pide un borrón y cuenta nueva, léase partir de  foja cero, en blanco.
La señora Juanita, que  siempre tiene algo que decir en las juntas de vecinos, a la que incluso los malandros más malandros del barrio le hacen caso, probablemente no sea precisamente la persona más adecuada para constituir parte de esta Asamblea. Y eso lo van a suplir con asesores que si supuestamente si tendrían las competencias para pronunciarse respecto a este tema, pero ¿qué o quién nos garantiza la transparencia política de estos actores? Y la respuesta es NADIE, el proceso querámoslo o no se va a teñir de algún color político vamos a tener peleas de monos en todos lados.

Para responder a la pregunta voy a referirme a mi experiencia. Por una cosa puntual tuve que sacar plata del APV para poder solucionar un problema financiero, ni siquiera hablamos de platas de la AFP, sino del APV, mi plata con menos restricciones que los fondos de la AFP. Cuando hice el retiro me explicaron que me iban a descontar un porcentaje  "en castigo" por haber retirado plata antes. Weón, ¡ES MI PLATA! y me cagan igual, y como uno necesita las lucas, cagaste, hay que asumir no más. Las ISAPRES, weón todos los años la misma pelea, los qls te suben los planes, cambian las condiciones  de los contratos unilateralmente, y si no reclamaste a tiempo (un trámite que  un mortal común y silvestre sin asesoría de u abogado no podría hacer bien), cagaste, te subieron el plan y anda a reclamarle a la FIFA. Otro ejemplo, las universidades, weón si en algunas no chupaste la suficiente corneta durante tus años de estudio, y no te  hiciste amigo del decano/rector/director de carrera/profe guía, te rajan o te cagan olvídate de exigir lo justo o lo que corresponde, son sectores con el suficiente poder como para cagarte alegremente y que  uno como vil mortal, las tenga todas de perder. En las empresas, te encargo el amiguismo, cuantas veces no vi que a colegas se los cagaba un weón de jefatura ql que es amigo de la alta gerencia. Entonces es una suma de weas, que uno, como vil mortal, esperaría que no fueran así, o que algún weón te defendiera, o en algún lado se resguardaran tus derechos.
Y SI, muchos de mis ejemplos no tienen puta relación con la constitución, el descontento  es así, y se quiere empezar por algo que al menos te garantice las bases (o te haga cree que las garantiza).

En un principio la opción era clara, RECHAZO, querer hacer una nueva Constitución es  estar puro webiando. Y no por miedo a convertirnos en un 2do Venezuela, como lo quieren hacer pintar algunos weones pro-RECHAZO. Hacer una Constitución desde cero es  estar puro webiando, ni culturalmente, ni educacionalmente, ni eticamente, ni moralmente, Chile derechamente NO ESTÁ CAPACITADO para gestar una nueva Constitución. Y sigo creyendo eso. Yo iba más por reformar la wea de Constitución que ya tenemos, pero eso tampoco es un APRUEBO, es un punto medio que no existe.

¿Entonces APRUEBO?

P'ta si, pero más que por querer una Nueva Constitución como todos/casi todos los weas pro-APRUEBO sin leer una puta wea de la actual Constitución más allá de la portada azul con letras blancas dicen, es por una wea de mensaje.

El mensaje del voto RECHAZO no es rechazar una nueva Constitución, es querer que la wea siga exactamente igual a como ha funcionado hasta ahora, que nada cambie y que los   qls calientasillas del Senado sigan sin hacer ni una wea útil.

Votar APRUEBO remece esa wea, hace que los weones por último entiendan que la gente quiere que las weas cambien, a pesar que  esa wea ya la saben, pero en democracia los weas necesitan de votaciones para saber que wea quiere la ciudadanía.

Usted sabrá que wea vota si es que vota, yo quiero que las weas cambien, ojalá cambien, pta hagan el amague de cambiar, aunque sea en el largo plazo. Votar RECHAZO es decirles a todos los weones inútiles que las weas están bien como están, y que no es necesario que cambien.

Como ser Amazing: La necesidad de un desarrollador senior

Sólo por si las dudas, este no soy yo :)

Hace algunos meses comencé a trabajar en una empresa pequeña, bajo el requerimiento de "Desarrollador full-stack senior". Al poco tiempo los chicos del equipo me empezaron a denominar medio en serio medio en broma "Amazing", básicamente por cierta capacidad que he desarrollado con los muchos años de experiencia, de ver un mensaje de error, entenderlo y solucionarlo de manera relativamente rápida. Cabe señalar que no funciona con absolutamente todos los errores, pero si con una gran mayoría, por fortuna los que desarrollamos software tenemos cierta tendencia a ser medianamente claros con los mensajes de error que aparecen en las pantallas, salvo los originales que desarrollaron Microsoft Windows (recuerden las míticas pantallas azules y sus códigos inentendibles).

En una actividad de empresa decidí hacer la presentación "Cómo ser Amazing" en la que traté de  explicar un poco el proceso de mantenerse vigente, a la edad de 42 años, en equipos de desarrollo conformados por millenials (promedio 27 años +-). Para ver la presentación naveguen con las teclas N y P de sus teclados.

Partamos por lo básico, ¿qué es un desarrollador senior?

Si nos vamos por el lado literal, sería alguien de avanzada edad que aún se dedica al desarrollo de software. Pero por ahí no va la cosa, un desarrollador senior es un desarrollador que tiene varios (a veces muchos) años de experiencia en el desarrollo de software, conoce varias tecnologías, conoce varias metodologías de desarrollo, varios lenguajes de programación, y ha adquirido experiencia demostrable en varias áreas del desarrollo de software. No necesariamente es un experto en todas las materias que conoce, pero tiene la capacidad de desempeñarse bien en todas ellas.

Típicamente los reclutadores no saben medir a un senior, por eso deben auxiliarse en entrevistas directas con personal de las áreas más técnicas para poder saber si un candidato es el desarrollador senior que dice ser en su Currículum Vitae.

¿Cuánto se demora un desarrollador en llegar a ser senior?

No es un tema de años, es un tema de experiencia. Con un ejemplo, puedes llevar más de 15 años picando piedras y eso no te va a convertir un experto constructor. Conozco desarrolladores senior 10 años menores que yo, y también quienes llegaron a serlo pasados los 50. Hay que programar mucho, meter los dedos en la máquina, adquirir una visión global de las necesidades informáticas que estamos atendiendo, y aprender mucho en el camino. Y cada cual tiene su propio paso para lograrlo.

Y no es magia. No es que uno termine los estudios en el instituto, universidad u otra institución académica y salga como desarrollador full-stack o desarrollador senior.
Por cierto, me referí a la subespecie full-stack de desarrolladores; eso da para un artículo totalmente aparte. El resumen útil es que uno no llega a ser full-stack con un curso carísimo (ejem cof cof Desafío Latam, NextU) que entrega pinceladas de las herramientas que se utilizan en desarrollos full stack; el proceso mental de entender que estamos usando y porque lo estamos usando es estrictamente necesario antes de ensamblar los bloques de Lego a lo brutito.

Competitivamente es complicado mantenerse vigente. Complicado porque cada nueva generación viene mejor capacitada, nacieron con Internet y pantallas touch, acceder al conocimiento es tan simple como un par de clicks. Más complicado cuando nuestra realidad de país se mezcla con realidades de otros países, realidades social y económicas muy diferentes, que hacen que el profesional senior  nacional (Chile) se vuelva comparativamente  caro con profesionales extranjeros igualmente capacitados e instruidos, incluso a veces mucho mejor que nosotros.

Eso nos lleva a los seniors a una lucha constante por mantenerse vigentes. Hay que leer y escribir mucho código, leer muchos artículos, no parar nunca de aprender, un proceso que no puede detenerse.

¿Qué gracia tiene un desarrollador senior, de dónde viene la necesidad?

Incorporar un senior en un equipo de ... iba a decir de pollos, pero se lee feo... de millenials, pasa por darse cuenta que tu organización necesita una dosis extra de experiencia y visión que no necesariamente vas a encontrar dentro del equipo que ya tienes. No me malentiendan, elementos brillantes va a encontrar en todos los equipos de desarrollo, personas con un grado de genialidad y visión destacables; sin embargo hay momentos en que  se necesita la visión dada por  la experiencia, de aquel que no sólo ha resuelto problemas sino que también ha visto como evoluciona cada solución propuesta.

Ya, pero ¿qué gracias tiene un senior?

Hasta donde me he dado cuenta todo parte desde la experiencia. Pero uno tiene que saber hacerse valer. Algunas cosas que sin ser exclusivas de un senior, si debieran ser esperables en quienes dicen serlo:

• Atención al detalle, código fino que considera los casos de borde. Al principio pensé que era un tema casi exclusivo de la Escuela, pero en realidad no es tan así, hay de todo en la viña del Señor.
  Por ejemplo un endpoint en una API, resuelve un requerimiento. Pero hay un caso bastante aislado, que sucede de cuando en cuando, donde la respuesta es nula por un problema de conexión. Lo más típico es que la API implemente la solución al problema, y la captura de errores sea o pospuesta (el peor caso de creer que todo siempre opera bajo el escenario feliz) o delegada a un ErrorHandler más global (lo que es bueno de tener). Un senior típicamente analizará la implementación, forzará ese error y otros aún más raros, y verá cómo atenderlos de la mejor manera posible.
• Fuente de respuestas a consultas varias. Debido a que un senior "las ha visto todas", cada nuevo requerimiento puede pasar por su consulta experta.
  Qué herramienta utilizar para cierto requerimiento, que librería puede servir, hasta un clásico de qué manera lo harías son consultas recurrentes. Y típicamente un senior tendrá algo que decir para todas ellas.
• Soluciones o enfoques fuera de la norma. Muchas veces va a suceder que un problema termina siendo más complicado de lo que suponíamos. Al consultar a un senior es altamente probable que le dé un enfoque diferente al tradicional.
  Un ejemplo que recuerdo, me consultaron sobre el siguiente problema, una aplicación de identificación de rostros debe poder determinar si la imagen que se le está presentando es o no una fotocopia. El problema es que el análisis de colores de la fotocopia arroja colores dentro de la gama de grises y amarillos, pero obviamente el software sólo obtiene valores numéricos y no colores propiamente tales, fuera que la medición es continua y no discreta. El enfoque que se propuso fue determinar una "banda de grises" usando como referencia el selector de colores del programa The Gimp; así si una muestra estadística de los colores de una imagen cae en esta banda, entonces hay cierta probabilidad que se trate de una fotocopia. Y con una debida parametrización este enfoque  funciona bastante bien.

Y esas son pocas entre varias, al final la experiencia de un senior es valorada independiente de si es o no un experto en las materias que se le requiera. Un poco como la historia del tornillo.

Los peros

Que te entreguen la denominación de senior también conlleva saber cargar con ese rol:

• Un senior no puede pecar de arrogante, y confiar demasiado en su experiencia.
  Los errores por "creerse demasiado el cuento" son tan grandes  como tu propio ego, y eso lo aprendí después de varias caídas importantes.
• Muchos van a querer adoptar a un desarrollador senior como su mentor, o como su ejemplo a seguir.
  Ser un ejemplo a seguir implica dar el ejemplo, conocer buenas prácticas, código limpio, metodologías, dominio sobre las áreas de experticia, y sobretodo tener la claridad que a pesar de ser un senior, no necesariamente tendrá la verdad absoluta ni la última palabra en un tema.
• Un senior debe reconocer el mérito ajeno, e impulsar los pequeños logros que lo rodeen.
  Ya sea en el código, incluyendo las referencias a las fuentes originales (Github, Stackoverflow, otros), o en reuniones donde otros integrantes del equipo se hayan echo cargo de resolver problemas que hayan consultado al senior.
• Un senior debe transmitir liderazgo, tanto por experiencia, conocimiento y por calidad humana.
• Un senior no puede quedarse atrás.
  En particular la informática es una constante carrera de información y aprendizaje constante, no se detiene, y si se quiere mantener vigencia como profesional del área, uno no puede darse el lujo de quedarse atrás. Y esto es difícil, porque la lucha se vuelve contra un mercado cada vez más competitivo.

Y así muchos más que se escapan de la cobertura que puedo dar con este artículo.

Al final la clave de todo está en la experiencia y cuanto se haya aprendido de ella, no sólo en términos técnicos y como resolver los problemas, sino como se combina lo anterior con el crecimiento personal; y como se sigue creciendo cada vez que toca ser un senior en una organización.