sábado, septiembre 21, 2019

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.

 

sábado, mayo 04, 2019

Crónica de una muerte anunciada



Se veía venir, mi desmotivación estaba aumentando insanamente mi habitual hostilidad por sobre los niveles socialmente aceptables. Así que una vez que una de mis varias postulaciones prosperó, renuncié a mi trabajo.

Yo lo veo como el cierre de un ciclo, las favorables condiciones que "me enamoraron" en un comienzo cambiaron a tal grado que se respiraba malestar e incomodidad. Pero en la cima de pirámide siempre serán incapaces de mirar de manera crítica más allá de sus pestañas, porque incluso sus narices sería que miraran demasiado lejos. Lo dicho, empresa familiar donde quienes toman las decisiones sobre temas técnicos no son del área, y el gerente TI jamás se empoderó de su cargo (y por cierto tampoco es ingeniero informático sino eléctrico...)

Entonces analizo hacia atrás y miro al futuro. Un nuevo desafío, donde una vez más rememoro ese episodio donde se dijo que "hay cosas que no se transan", o en este caso cosas que no se pueden pagar con dinero.
Efectivamente se lee como una contradicción a uno de mis últimos artículos, pero todo se trata de plata y al final no se trata de plata. Como ya han señalado demasiados autores, uno no renuncia a su trabajo, uno renuncia a su jefe. Pero hay señores feudales que no van a aprender a gerenciar/liderar  equipos como se debiera hacer, alimentar el bolsillo es siempre más importante que hacer buena gestión, y digo gestión de proyectos, de recursos y por sobre todo humana. Al menos para mi resulta inconcebible que una empresa se maneje desde el desconocimiento de los proyectos en curso, el estado de estos proyectos, y con una priorización basada en el "tengo que facturar", o en cual es el cliente que está llamando al gerente. Sin embargo la parte triste de la historia es que parece que esa estrategia funciona.

En un viaje al extranjero, conversando con un chofer de Uber me quedo grabada una frase que dijo "La gente ya no se preocupa por la gente" ("People don't care about people"). Y en países tercermundistas aspiracionales como Chile, lo vemos a diario, sobretodo como empleados. No hay (lo sé, estoy generalizando...) preocupación real por los trabajadores.

Me fui desilusionado, desilusionado al ver que como en 5 años la misma empresa no haya aprendido absolutamente nada en cuanto a gestión de proyecto informáticos, cero avance en las tecnologías utilizadas, el archipiélago de islas uni-personales en el equipo de desarrollo persiste, cero crecimiento profesional (los años van a pasar y vas a seguir picando las mismas piedras) y por sobre todo un  retroceso en torno a la gestión del recurso más importante en una empresa: las personas; quienes siguen ahí no porque sea la mejor de las empresas, sino porque no pagan mal. Como dice el secreto a voces en la empresa "Se notó demasiado el cambio de mano" y no para bien.

Y podría seguir descargándome, pero no. Simplemente voy a concluir que como la mayoría de las segundas partes (a excepción del Imperio contraataca) este capítulo fue algo decepcionante.
Pero así es el rock & roll del ingeniero de software, es iluso esperar que todo sea felicidad y éxito; es  casi como esperar que todo funcione bien a la primera.

sábado, marzo 02, 2019

Reclutadores, LinkedIn, y los cargos de papel

Imagen sacada desde http://howtosavetheworld.ca/2018/08/29/hierarchy-is-the-enemy-of-learning/
Hace algunas semanas atrás apareció en la empresa para la cual trabajo un nuevo personaje. Su misión encubierta: gerenciar los proyectos en curso de una empresa "hermana". Su misión real, o más bien como la estamos percibiendo, hacer sonar los tambores y dar golpes de látigo de cuando en cuando, y paquear, como decimos en Chile a los que hacen de policia.

Eso, junto al cambio de oficina, definitivamente vino a quebrar el "equilibrio espiritual" que nos envolvía. Poniéndolos en contexto queridos lectores, el área de desarrollo se encontraba literalmente en el último rincón de la oficina, donde estábamos muy cómodos y tranquilos, con todo lo que necesita un área de desarrollo, agua, cafetera, fruta, dulces, pizarra, panel Kanban, mucho espacio y juguetes. Nos forzaron a mudarnos literalmente al frente de la oficina, detrás de la secretaria de recepción, totalmente expuestos, y obviamente con la absoluta carencia de  muchos de los elementos que nos mantenían cómodos y a ratos felices; sabiendo que las áreas de desarrollo tienen que mantenerse escondidas de los clientes (digamos que el orden diferente de estás áreas siempre es por lo bajo disrruptivo, y tiende a ser confundido con desorden).

Pero no, no voy a hablar de mis descargos, sino de cierta peculiariad que me hizo recordar cuando traté con un personaje que al irse de la empresa para la cual trabajábamos en ese entonces,  puso en su LinkedIn que había sido el arquitecto Java. El nuevo personaje en cuestión aparece con el original cargo de "Sub-gerente de desarrollo de negocios y estrategia digital" . Esto nos hace pensar varias cosas:

  • ¿Se puede ser sub-gerente de una gerencia que no existe en la empresa? Para LinkedIn y para los miles de "reclutadores" que se fían de  estos antecedentes, claramente.
  • Nadie nos informó que este personaje venía como sub-gerente. De hecho si no es por LinkedIn nadie se  entera del supuesto cargo que detenta.
  • ¿Las gerencias estarán enteradas de esto? La lógica nos indicaría que si, al menos por un tema ético, pero nuevamente, nadie nos ha informado al respecto. Uno esperaría que los amitos se dirigieran a la plebe con un "Hola. Les presento a Pepito TeVe , que va a er nuestro sub-gerente de blah... y se va a encargar de bleh.." Contra el como nos lo presentaron "Hola, él es Pepito TeVe y nos viene a apoyar en la gestión de los proyectos de blih...". Entre ambos discursos veo perturbadoras y no tan sutiles diferencias.
  • Finalmente surge la pregunta ¿porqué? y aquí es donde entran los "reclutadores" de LinkedIn.

Reclutadores de LinkedIn

Típico que cuando uno anda merodeando por LinkedIn, y sobretodo si uno se ha encargado de hacerse cierta publicidad llenando bien el CV, uno recibe algún mensaje de algún reclutador. Este tipo de reclutadores es como a quien encargan a leer los avisos económicos de los periódicos. Buscan algo que se ajuste a lo que se necesita, y después alguien más se encargará de llamarte o contactarte para una conversación más seria.

El problema es que puedes haber puesto "Jefe supremo del mundo mundial de todo el universo" y si el título pareciera ser lo suficientemente convincente nadie, y digo NADIE,  se encargará de verificar si efectivamente fuiste el Jefe supremo del mundo mundial. El papel aguanta mucho, entonces si el reclutador hiciera bien su trabajo harían un mínimo de trabajo de contactar a alguien (ojalá al azar) de estas empresas y hacer las averiguaciones básicas.
Esto sería la misma cuota de azar para bien o para mal, pero también  una ganancia para las empresas que no estarían perdiendo el tiempo con quienes mienten en sus cargos actuales, y un incentivo para los empleados para ser honestos en su CV. ¿Muy utópico? Probablemente, soy de la filosofía de que si no quieres hacerte cargo de tus mentiras, ni de las mentiras ajenas, entonces mejor no mientas.

Yo esperaría que en el futuro cuando Pepito TeVe sea un cesante más y un reclutador vea su CV en LinkedIn alguien verificara si efectivamente ejerció el cargo de "Sub-gerente de desarrollo de negocios y estrategia digital", o si solamente fue el cargo de papel que probablemente le valga la posición de Gerente de proyecto/producto en alguna startup, lo que siendo realista, como posición  es bastante más cercano  a lo que actualmente cree que está haciendo.

Palabras al cierre del artículo: Por si notó cierto malestar y una importante carga de ironía, si. Efectivamente. Al menos mi malestar, a modo personal, es evidente; sin embargo claramente importa un pepino. Peeeero... así como tienen personajes imaginarios en sub-gerencias imaginarias, lo siempre lógico es gerenciar sobre un equipo también imaginario.

jueves, febrero 07, 2019

La entrevista de 5 minutos

Original de https://www.flickr.com/photos/visualpunch/7245652114

Hace algunos días atrás LinkedIn me envió un listado de "atractivas" ofertas laborales, entre ellas una que particularmente me llamó la atención. Se trataba de una startup, con cierta antigüedad (pero sigue siendo startup, como los autos usados con olor a nuevo), que buscaban un profesional más o menos con mi perfil. Dado que la curiosidad fue más fuerte postulé, y no les miento, en menos de 5 minutos me estaban llamando por teléfono.

Haciendo caso omiso de la calidad de la llamada, porque se escuchaba como si mi interlocutor estuviera encerrado en un bunker bajo tierra, la llamada comenzó con casi un "¿Cuándo puedes partir?". Mi enfoque habitual es de "Por favor, cuéntame más de que se trata la oportunidad, qué es lo que están haciendo, y qué es lo que necesitan". Siempre procuro hablar de "oportunidad" contra hablar de "ofertas", ya que una oferta siempre va con el monto visible para los interesados. Por otro lado las oportunidades son comparables a ver el aviso de venta de una casa, no necesariamente  van con el precio.

El resumen corto, empresa "joven"; información corroborable en Internet; con pocos empleados, varios clientes "grandes/importantes" del rubro retail (lo que no es mucho decir considerando la cantidad de proveedores de servicios que manejan las multitiendas), más un par de organizaciones sin fines de lucro. El proyecto era para alguna multitienda, y la intención era hacer un cambio completo de arquitectura, de modo de irse por el camino de los microservicios , usando Java. La necesidad puntual, un arquitecto Java con, digamos, "destrezas" en "otras áreas".

Conversamos un rato, le conté que estaba haciendo, que había hecho, y llegamos a la parte siempre dolorosa para los entrevistadores, las pretensiones de sueldo. Le señalé que mis pretensiones se ajustaban acorde  a los más de 15 años de experiencia que tengo, y empezamos con problemas. Mis pretensiones obviamente no estaban acorde a los montos que la empresa consideraba para el cargo, me ofreció 2 montos, uno inferior a mi sueldo actual, y otro al nivel de mi sueldo actual. Consideren  que los cambios laborales, salvo circunstancias demasiado particulares, siempre debieran ser por mejores condiciones; si no hay mejora aparente mejor sigan donde están. Después de "aceptar" a regañadientes mis pretensiones, me consultó cuál era mi disponibilidad, a lo que repliqué que necesitaba al menos 2 a 3 semanas para poder cerrar los temas que tenía a cargo. La idea al cambiarse, es siempre salir por la puerta ancha; el mundo es demasiado pequeño para salir "en mala" como decimos en Chile, lo que eventualmente puede cerrarnos algunas puertas en el futuro.
Eso tampoco prosperó, la necesidad para esta nueva posición era inmediata, dadas las fechas cercanas del inicio del proyecto. Finalmente le dije que me mandara un correo; cosa que no hizo; con esos mismos antecedentes de modo de poder manejar mis tiempos y ver  la posibilidad de irme a su empresa.

Consejo gratuito a los reclutadores: NUNCA, pero NUNCA NUNCA NUNCA, revelen la urgencia de su necesidad de contratación. Es un antecedente que se va a volver en "su contra" (léase a favor de uno) al momento de las negociaciones. En fácil: Las urgencias siempre son más caras.
Corolario de lo anterior: Eviten que el rol del reclutador lo lleve un líder técnico.

Eso fue la llamada. Obviamente después hice un breve análisis de la situación. En lo personal me pasa algo cuando se me presenta un proyecto, donde el interlocutor habla con cierta propiedad de conceptos como microservicios, APIs REST, metodologías ágiles, TDD, devops, big data, business intelligence y otras "palabras de moda" en el contexto TI. 

Mi primera reacción es cuestionar la real comprensión de cada uno de los términos, porque por ejemplo para el caso de los microservicios, no es llegar y cambiar hacia una arquitectura a microservicios, sobretodo si inicialmente es un monolito. Eso aparte de una gran consideración que todos quienes hemos querido jugar con microservicios tendemos a olvidar: efectivamente hace que las capas de tu arquitectura se vuelvan modulares, "más sencillas" (es un gran es relativo), ya que van a resolver funcionalidades/servicios puntuales más pequeños; sin embargo tu arquitectura inmediatamente gana más componentes, lo que se traduce en más componentes para mantener. Esto sumado a que además debes hacer "conversar" los componentes entre si (aunque en rigor al menos esta parte es transparente, ya que la capa de orquestación se encargaría de esto).
Piensen en un monolito como bloque de piezas de Lego, pero uno donde pasarlo a microservicios implica desarmar el bloque y agregarle piezas nuevas para sostenerlas por separado. En el suelo es más fácil clavarse los pies al pisar muchas piezas pequeñas que clavarse pisando un bloque grande (un monolito).

Y esto no quiere decir que los microservicios sean intrínsecamente malos, sino que la labor del arquitecto de software (obviemos la etimología del concepto arquitectura) no es sólo velar por la correcta implementación e implantación de los microservicios, sino además saber y hacer saber si efectivamente son la mejor solución para el problema.

Entonces tomando como antecedentes la urgencia del requerimiento, el rango salarial ofrecido, la experiencia y perfil de la empresa, y la cantidad brutal de conceptos de moda que lleva el proyecto, mi conclusión; en un lenguaje bastante coloquial; es que esta startup se está tirando los peos más arriba del poto (literalmente en español no-chileno, y usando el verbo peer conjugado correctamente, peyere más arriba del trasero). Una empresa con pretensiones excesivamente altas para un equipo que sospecho (arriesgo equivocarme) aún no tiene las competencias para un proyecto con microservicios. Y de paso les cuento algo: Yo tampoco tengo esas competencias, en un contexto práctico no académico-teórico.

domingo, diciembre 23, 2018

Cambio de trabajo: Un año después


Y bueno, ha pasado un año (en realidad algunos días más) desde que decidí cambiarme de trabajo. Lo típico, el análisis de porque me fui y que ha sido de eso.

El porqué me fui, ya no es misterio, entre la incertidumbre de no saber si el próximo mes iba a haber algún proyecto, entre seguir siendo el ingeniero frontend más caro dentro de la empresa, y seguir haciendo "nada útil",  y ver un "cambio". En estricto rigor fue algo más como un "cambio de aire" que otra cosa, ya que volví a una empresa donde ya había trabajado.

¿Y la promesa? (otra promesa, no las del chiste "fino") Nuevos proyectos, nuevos desarrollos, varias cosas en las que mis especialidades calzan perfectamente.
Y ¿es cierto? Si, claro. Pero al final no se trata de crecimiento profesional, ni de espacios para investigación, ni de un buen computador para trabajar. Tampoco de ser parte de un equipo de excelencia, donde el nivel técnico fuera muy alto; si fuera por eso hubiera seguido picando piedra donde mismo.

Al final se trata de lucas, dinero, chinchin, cash. Si el sueldo es bueno, y las condiciones de trabajo se ajustan al margen que uno está dispuesto a negociar, el espíritu del mercenario despierta. Si tu oferta es buena, no me estás vendiendo humo, y las condiciones son a lo menos comparables a mis condiciones actuales, conversemos. Laboralmente, por feo que se lea el ser tan honesto, todos tenemos un precio, por el cual ningún compromiso laboral, ninguna camiseta de la empresa, ni gorro corporativo, ni elegante uniforme de trabajo, valen el quedarse. Las oportunidades raramente golpean tu puerta 2 veces, y no es y llegar dejarlas pasar de largo.

Pero eso fue mi año laboral, raro, donde mucho sigue igual, mucho debiera haber cambiado para mejor, pero a la larga lo mismo de hace 5 años atrás donde la empresa familiar sigue siendo familiar, y donde el área de desarrollo es un República independiente.

¿Y el año que dejé atrás? Como le mencioné a un ex-compañero, que ya no trabaja ahí, la torre de Yenga se derrumba. Por lo que alcancé a ver antes de decidir terminar el contacto con ese grupo al que tanto cariño le tuve, han sabido sobrevivir. Pero en un año y al menos 3 personas menos en ese equipo, me queda claro que allá más arriba, no aprendieron nada. Las tropas siempre inquietas, y sobretodo disconformes por no saber que pasa en el Olimpo. Si claro, el Olimpo maneja las cosas entre Dioses, pero nosotros los pobres mortales que a la larga nos encargamos de "parar la olla" como dice nuestro lider técnico (cof cof wannabee), tenemos que al menos saber si los Dioses exigen un sacrificio.

Eso sumado a quienes constantemente dicen que quieren emprender un nuevo camino profesional. Las tropas están inquietas, y a los buenos soldados hay que cuidarlos; eso no debiera ser difícil de entender, aprender y asimilar.

¿Fue una buena decisión? Siempre es buena decisión moverse, ojalá no demasiado seguido para que los psicólogos laborales no empiecen a inventarse una lectura entre líneas. Siempre es bueno si ese movimiento te permite una reinvención financiera, digamos pasar de excavador sepulturero a caminante blanco.

Mi consejo (no solicitado, por cierto) para sus propios años laborales: Hagan lo que consideren mejor para ustedes. Si creen que quedándose donde están estan mejor, quédense. Si creen que necesitan aceptar esa oferta de Tesla, váyanse. Si creen que merecen descansar unas cuantas jornadas, HÁGANLO. Pero OJO, nunca dije que lo mejor para ustedes sea lo correcto, a veces eso también hay que saber transarlo (aunque hay cosas que no se transan).
Vean la proyección a futuro de las ofertas que se les presentan, a veces la genial y súper cachilupi startup con sala de juegos es una empresa donde respiras el perfume de la fecha de expiración; o donde todo es muy bonito, cultura de empresa, metodologías, pero te casas con el sueldo que pediste (y con tu cargo, y con el computador que te pasan).

Cuando los quieran retener con el clásico discurso de "Te igualo el sueldo que te ofrecen, pero quédate" simplemente cuestiónense porque no les subieron el sueldo cuando  lo pidieron y les ofrecen subirlo ahora que se van. Estadísticamente, si aceptan esa oferta y se quedaran, al final igual terminan lléndose.

Y después de este desborde de honestidad, probablemente Bobba Fett sea un candidato más atractivo que yo para ciertas empresas.

miércoles, enero 17, 2018

La necesaria mirada hacia adentro de la propia organización

by https://www.flickr.com/photos/144152028@N08/33772074972

Mañana se cumple exactamente un mes desde que dejé mi antiguo trabajo. Por esas cosas del destino ahora estoy en una empresa que ya conocí, sacando cuentas he vuelto después de 5 años.
No puedo negar que ahora me siento bastante más cómodo, la dinámica de trabajar por proyectos versus trabajar en torno a un producto que está posicionado en el mercado hace más de 20 años es muy diferente. Proporcionalmente hablamos de una empresa con un área de desarrollo mucho más pequeña, por ende mucho más especializada, contra una empresa que es derechamente de desarrollo, donde el área encargada es bastante más grande, y consecuentemente más heterogénea. Pero no quiero referirme a eso, sino a una reflexión que tuve antes de cambiarme de trabajo.

Desde el punto de vista de la empresa, ahora se fue uno (en rigor hace un mes), un recurso menos, un elemento reemplazable, con más o menos dificultad, pero siempre reemplazable. La pregunta a hacerse desde dentro es ¿porqué? ¿qué pasa en MI organización, que la gente piensa en irse a otra empresa?
El que tan indispensables somos depende de las estrategias de cada empresa. Si cada desarrollador es "dueño y señor" de los desarrollos que se le encomiendan, y si no existe un equipo de más de un solo hombre (o mujer) encargado, entonces se vuelve más complicado reemplazar a alguien que se va. Pero ¿porqué se va la gente?

¿Mejores condiciones? ¿salarios más atractivos? ¿mejores proyectos? ¿mayor proyección profesional?
A mi parecer, y un poco lo que personalmente me motivó, es una mezcla de factores, donde claramente el salario fue el 1er elemento a considerar, pero no el único.
Cuando día tras día la rutina de ir a trabajar se empieza a volver tortuosa por la percepción de una falta generalizada de voluntad por hacer cosas, y cuando empiezas a darte cuenta de una inusual venta de humo, de la que alguien (probablemente uno) tendrá que hacerse cargo, con requerimientos imposibles y en plazos irreales, entonces hay algo que dispara todas las alertas en tu interior. Si a eso sumas que la organización difícilmente ajustaría las condiciones y el equipo conforme a estos nuevos "desafíos", o simplemente ves que  te estás condenando profesionalmente a "seguir picando piedras", las señales no pueden ser más claras.

Entonces desde dentro probablemente van a ver todo bonito y tu partida será injustificada. Aquí es donde es importante no perder la objetividad.
¿Qué está pasando en MI organización? Si tu administración es desde el desconocimiento, entonces puedes esperar que muchos se vayan y no vas a entender porqué. La mirada hacia adentro debe ser crítica y siempre objetiva. No es pecado ni mal visto bajar del Olimpo a ver que pasa en la Tierra.

Las tropas no se mueven si no hay un liderazgo claro, pero tampoco dejan los puestos de batalla por nada.
Nota: Este artículo probablemente se lea como una contradicción (en algún grado) a este otro artículo . Si y no. Como mencionaba más arriba, las condiciones (entorno) pueden ser  muy buenas y atractivas, incluso mejores que las de cualquier otra empresa, y seguramente es eso lo que va a ver un jefe. Pero la informática es dinámica, y no se alimenta sólo de juguetes, vestimenta informal, pizza, café, golosinas y bebidas energéticas. El problema esencial es cuando el líder no se da cuenta (o no quiere darse cuenta) que las tropas están inquietas, ya sea por ese constante picar piedra o simplemente por la incertidumbre frente al futuro; y frente a eso por muy buenas que sean las condiciones del entorno la gente se va a ir.

martes, enero 09, 2018

Eventos y autogestión: Ojalá no se equivoquen

Este sábado 6 de enero recién pasado tocamos junto a mi banda Sin Cielo, en un evento autogestionado denominado Construye telaraña. Finalmente el evento salió adelante, sin embargo hubo muchas cosas que; al menos a mi; me dejaron con la sensación que no se hicieron bien.

Cuando recibimos la invitación nuestras primeras dudas fueron:

  • Fecha y lugar del evento
  • Bandas participantes, y estilo de las mismas.
  • Backline disponible; vale decir que equipos iban a estar disponibles para que utilizaran las bandas que iban a tocar en el evento.

Lo único de lo que había claridad era la fecha y lugar, el Galpón de la Juana, en la comuna de Conchalí. Una vez allá nos dimos cuenta que no se trataba de un recinto, sino más bien un área abierta, techada, aledaña a una multicancha y a una calle.
Durante la semana se iban a definir las bandas participantes, que a priori incluían a algunas bandas de rock, e intérpretes de "trova". Y sobre los equipos disponibles, en un principio nada, irían consiguiendo  los equipos entre las mismas bandas participantes. Ya en ese momento nuestras expectativas del evento empezaban a ser bajas, sobretodo por el tema del equipamiento, tanto así que una semana antes incluso dudamos de nuestra participación.

No es que seamos Rock Stars, pero incluso habiendo sido invitados a participar lo mínimo que esperas es contar con lo básico; léase al menos 2 micrófonos para la voz,  2 amplificadores para guitarra, 1 amplificador de bajo, una batería. Al confirmar el backline disponible, la organización señaló que faltaba un amplificador de guitarra, pero que "Aún hay tiempo para conseguir otro" (a un día del evento).
En alguna parte de las conversaciones se les preguntó porqué no arrendaban lo que faltaba, solicitando el apoyo monetario de quienes participaran, a lo que respondieron que era  "un evento autogestionado, y preferían conseguir los equipos con quienes participaran".

Sobre el tema de conseguir y facilitar equipos, es complicado, ya que en mi caso particular, dispongo de algunos equipos, sin embargo sin conocer a nadie salvo al gente de mi banda, no puedo llegar y confiar, menos cuando no hay una voluntad manifiesta de hacerse responsable en caso que llegaran a dañar un equipo.
Imagino que parte de esta particular filosofía de "autogestión" era ver esos temas sobre la marcha.

Otra consulta que hicimos fue el orden en que se presentarían las bandas e intérpretes participantes, básicamente si tienes 10 participantes, y el evento empieza a las 5 ó 6 de la tarde, para poder sacar un cálculo de cuanto tiempo dispone cada banda para tocar, y a que hora te vas a presentar en el evento. En principio no hubo respuesta, y finalmente dijeron que 1ero tocarían quienes no requerían de amplificación (show acústico, presuntamente los intérpretes de "trova") y luego las bandas.
Respecto a la hora de llegada nos citaron a las 2 de la tarde "para poder ayudar a armar". Llegamos tipo 3 de la tarde, y nos encontramos con otros chicos que si llegaron a las 2PM, quienes nos comentaron que "no dejaron que los ayudaran".

Supuestamente al llegar temprano también podríamos a hacer una buena prueba de sonido. La verdad es que si no dispones del equipamiento necesario difícilmente podrás hacer una buena prueba de sonido...
Nota al margen: No hubo prueba de sonido...

El evento comenzó a eso de las 4 de la tarde, casi a  las 5. Nos dimos cuenta que faltaba un amplificador de guitarra, o mejor dicho sólo disponían de un amplificador mediano, el otro amplificador disponible era un amplificador "de habitación" (10 watts con suerte). 

Y aquí es donde terminaron de revelarse los problemas de la organización.
Cómo no existía un orden a priori para las bandas e intérpretes, la presentación se hizo "en la medida que aparecían". Los "trovadores" estaban todos atrasados y hubo momentos muertos en el evento. Después de un rato de incertidumbre le planteamos a uno de los organizadores si podíamos hacer nuestra prueba de sonido, ya que dado que les faltaba un amplificador de guitarra tendrían que ver como microfoneaban el mini amplificador, un problema que iban a tener ya que al menos otra banda  más entre las participantes (aparte de nosotros) tenía 2 guitarras en su formación.

Cuento corto, nuestra prueba de sonido se convirtió en nuestra presentación, ya que la gente prendió cuando empezamos a tocar. No tocamos nuestro playlist completo y nos bajamos con una sensación de haber estado en un "ensayo con público".

Lo malo:
(tristemente lo más fácil de apreciar en las circunstancias de este evento)
  • Mala organización (perdonable si fue el 1er evento que organizabas).
  • No se contaba con el equipamiento mínimo (perdonable si hubieran tenido la disposición de conseguirlo, vs esperar del cielo la buena voluntad de alguien).
  • El único micrófono dispuesto para la voz falló durante todo el evento (imperdonable).
  • No había orden dispuesto para los participantes (imperdonable). Si no hubiéramos tocado en el momento que lo hicimos, seguramente hubieran tenido que cortar las presentaciones de otros para poder dar tiempo a todos. ¿Mala organización? OK admisible, pero tampoco puedes ser tan al lote.
  • Seguridad ciudadana llegó a terminar el evento (imperdonable).

Lo bueno:
(ya que no todo puede ser malo)   

  • Sacaron adelante el evento, a pesar de todo.
  • El apoyo del público. OK, bandas  apoyando a otras bandas, más los familiares, más amigos cercanos, más los borrachines locales, más los perritos, pero apoyo al fin y al cabo.
  • El ambiente generado. El hecho de poder interactuar con otros músicos y bandas y poder abrir la posibilidad de organizar cosas en conjunto es, por si solo, valorable.
  • La oportunidad de darse a conocer. Nosotros, como Sin Cielo, no somos una banda conocida. Supongo que será el caso de varios de quienes participaron de este evento. Hubo gente que no nos había escuchado nunca, que estuvo presente, nos puso atención y disfrutó de nuestra música.
Puntos notables:
  • La niña de pelo rosado que cantó con su guitarra, a la que los borrachines que le cambiaron el coro de su canción.
  • Los borrachines que aplaudieron, cantaron y gritaron con todas las bandas.
  • Los perritos que se acercaron a acompañarnos.
  • Cerveza polaca a CLP$500.
  • El campeón que llegó con su amplificador, tocó una canción de Los Bunkers, terminó, tomó su amplificador y se fue.
  • Las salvadoras sopaipillas.

Pero no se equivoquen, en este contexto la buena autogestión no es sólo sacar adelante un proyecto (evento musical), y conseguir los equipos sin pagar ni un peso a terceros.
Es (entre  un millón de cosas más) poder transmitir un mínimo de seriedad a los participantes, lo que se traduce en confianza hacia la organización, y el deseo de participar en otros eventos del mismo comité.

Nosotros salimos con sentimientos encontrados de este evento. Lo que es claro que frente a cualquier invitación a tocar y presentarnos como banda, las preguntas base van a seguir siendo las mismas:

  • Fecha y lugar del evento
  • Bandas participantes
  • Backline disponible