Los peligros de depender de los referidos en la industria del software

En la industria del software, es muy común encontrar trabajo a través de referidos, o referrals como se les conoce en inglés. Si no estás familiarizado con el término, un referido es básicamente cuando una colega o un conocido te recomienda para una vacante en su empresa o en una que conoce. Durante mucho tiempo, confié fuertemente en este método de conseguir trabajo.

En este punto, es importante destacar que algunas empresas incluso incentivan a sus empleados a traer a personas con las que ya han trabajado antes. A primera vista, esto podría parecer una gran estrategia. Después de todo, ¿quién mejor para evaluar a un candidato que alguien que ya ha trabajado con él o ella? Sin embargo, estos incentivos a veces pueden resultar contraproducentes. Al animar a las personas a contratar dentro de sus propios círculos, pueden crear un ambiente de trabajo homogéneo y limitar la diversidad de pensamiento y experiencia.

Los referidos te proporcionan una especie de falsa seguridad. En mi caso, ya no tenía que ir yo activamente a buscar oportunidades. Estas me llegaban a través de personas con las que ya había trabajado y que confiaban en mi capacidad y experiencia. Parece ideal, ¿no? Sin embargo, hay varios problemas en depositar toda nuestra confianza en este sistema.

Primer problema de depender únicamente de ser referido: las experiencias no tan padres una vez que entras

Uno de los problemas principales es que no siempre la experiencia laboral resulta tan padre como esperabas. Si cada parte de la empresa está contratando principalmente a través de referidos, sin un proceso de entrevistas estandarizado, es muy probable que te encuentres con una cultura laboral en la que cada quien está jalando para su propio lado.

Las experiencias más retadoras de mi historia profesional han sido cuando he entrado a empleos por referidos, pero sin un proceso de validación de qué tanto era compatible con la cultura de la empresa. Si no hay un proceso de entrevistas donde se evalúe esto, probablemente no haya una cultura de la empresa definida. Entonces, te encuentras en un ambiente de “todos contra todos”, donde cada quien se va a tener que rascar con sus propias uñas.

Piénsalo de la siguiente manera. En un ambiente de desarrollo de producto, si el departamento de ingeniería está contratando únicamente a través de referidos y sin un proceso de entrevistas estandarizado, es muy probable que los otros departamentos de la empresa también lo estén haciendo. ¿Cuál es el problema? Que cada grupo está creando, en esencia, cámaras de eco (echo chambers) que son incompatibles con las del resto de la empresa.

Un producto exitoso se desarrolla a base de colaboración entre diferentes áreas de la empresa. ¿Cómo se podría lograr esto cuando ingeniería está impulsando una filosofía de desarrollo, al equipo de producto no le importa nada de eso y solo quiere sacar nuevas funcionalidades, y marketing solamente quiere vender?

Créeme, no quieres estar en esa situación.

Segundo problema de depender únicamente de ser referido: salir de tu zona de confort

El segundo problema surge cuando quieres o necesitas cambiar de empleo, de industria, o crecer bajo tus propios términos. Te vas a sentir fuera de tu elemento. La industria cambia bastante rápido y te pueden correr en cualquier momento, sin necesidad de tener una justificación clara.

No necesariamente tiene que suceder algo malo en el mercado para que las empresas hagan despidos masivos. Como lo expliqué en mi artículo, muchas empresas están despidiendo gente hoy simplemente porque empresas más grandes también lo están haciendo, y no les van a caer tantos problemas.

Una amiga recientemente me comentó: “Además de la incertidumbre de no saber qué esperar, en mi vida me había entrevistado así, siempre había llegado por referidos”. Si siempre te mueves con referidos, cuando te toque enfrentarte al “mundo real” de las entrevistas y la búsqueda de empleo, puede resultar un shock bastante grande.

¿Entonces entrar por referidos es malo?

No. Es perfectamente aceptable y, de hecho, beneficioso tener referidos y una comunidad de apoyo. Tener una reputación sólida en la industria que haga que la gente quiera trabajar contigo nuevamente es valioso. Pero si no tienes un contrapeso que te aterrice en la realidad de la industria constantemente, cuando tengas que salir a buscar tus propias oportunidades en horizontes no explorados, vas a pasarla mal.

También es crucial no confundir ser el referido de alguien con tener un mentor. Un mentor es alguien que te guía, te da consejos y te ayuda a crecer profesionalmente, independientemente de si trabajas directamente con él o ella. Puedes aprender de las otras personas aun sin trabajar con ellas.

Aquí te dejo algunos tips para mantener un equilibrio y que no te tome de sorpresa cuando no puedas contar con tu red de referidos para encontrar un trabajo:

Desarrolla tus habilidades de búsqueda de empleo: No te limites a aceptar solo las ofertas de trabajo que llegan a través de tus referidos. Actívate en la búsqueda de empleo, prepara tu CV y practica entrevistas. Esto te mantendrá en sintonía con la realidad del mercado laboral.
Cultiva una red diversa: No dependas únicamente de las personas con las que has trabajado antes. Asiste a eventos, haz networking, conéctate con personas fuera de tu círculo habitual. Esto te dará una perspectiva más amplia y te abrirá a nuevas oportunidades.
Mantén una mentalidad de aprendizaje continuo: La industria del software cambia rápidamente. Asegúrate de mantener tus habilidades actualizadas y de estar al tanto de las últimas tendencias y tecnologías.
No te olvides de la cultura de la empresa: Si bien es cierto que un referido puede abrirte la puerta a una nueva oportunidad, es crucial que también hagas tu propia investigación sobre la cultura de la empresa. No querrás terminar en un lugar donde no te sientas cómodo o valorado.
Busca un mentor, no solo un referido: Un mentor puede proporcionarte orientación valiosa y perspectiva en tu carrera. Aunque un referido puede ayudarte a conseguir un trabajo, un mentor puede ayudarte a navegar los desafíos y a crecer en tu carrera a largo plazo.

En resumen, los referidos pueden ser una herramienta importante en tu búsqueda de empleo, pero no deben ser tu única estrategia. Mantén un equilibrio y estarás preparado para enfrentar cualquier cambio o desafío que se presente en tu camino. Recuerda, en esta carrera no se trata solo de sobrevivir, sino de prosperar.

Cómo crecer tu carrera en software de manera responsable

En el mundo del desarrollo de software, muchas veces nos centramos en la tecnología y en aprender nuevos lenguajes de programación o herramientas.

Sin embargo, hay un aspecto que suele pasar desapercibido: la agencia que cada desarrollador tiene sobre su carrera profesional. En este artículo, exploraremos la importancia de tomar las riendas de nuestro propio crecimiento y éxito.

Elegir dónde y con quién trabajar: un aspecto clave

Es común que los desarrolladores pongan mucho énfasis en la tecnología con la que trabajarán, pero elegir dónde y con quién trabajar es igual o más importante. Un ambiente laboral tóxico o poco estimulante puede frenar nuestro desarrollo profesional, además de afectar nuestra calidad de vida y salud mental. Por ello, es crucial investigar y seleccionar cuidadosamente las empresas y equipos con los que colaboraremos, asegurándonos de que compartan nuestros valores y objetivos.

Sí, está bien que una de tus metas sea trabajar con la tecnología de moda — llámese Elixir, Clojure, o TypeScript. Pero toma en cuenta que toda la tecnología es una ola, nada más. Se va a ir, y mañana habrá algo nuevo que será la sensación.

¿Sabes qué es lo que no se va tan fácil? El daño de sufrir burnout por haber trabajado en una empresa sin visión clara, con comunicación horrible, y con liderazgo tóxico.

No te quemes de a gratis.

El éxito es encontrar un camino hacia delante

Todos enfrentamos obstáculos y desafíos en nuestra carrera profesional. El éxito no se trata de tener un camino perfecto y libre de problemas, sino de nuestra habilidad para encontrar soluciones y avanzar entre las opciones que realmente tenemos a nuestro alcance.

Ser resilientes y adaptarnos a las circunstancias nos permitirá seguir creciendo a pesar de las dificultades.

Las habilidades blandas: el secreto para crecer profesionalmente

Es fácil caer en la trampa de pensar que, como desarrolladores, solo necesitamos mejorar nuestras habilidades técnicas. Pero las habilidades blandas, como la comunicación, el trabajo en equipo y la empatía, son extremadamente importantes para nuestro crecimiento profesional. Estas competencias nos permiten colaborar eficazmente con nuestros colegas, resolver conflictos y generar soluciones creativas a los problemas que enfrentamos.

Aparte, toma en cuenta que cada día que pasa, si lo único que sabes es programar, tu carrera está en más riesgo.

Impacto vs. conocimiento: crecimiento exponencial

Medir nuestro progreso solamente en función de cuánto sabemos puede hacernos crecer de manera lineal, es decir, mejorar poco a poco en nuestras habilidades técnicas sin realmente avanzar en nuestra capacidad para resolver problemas reales y generar valor. Sin embargo, si nos enfocamos en buscar tener un mayor impacto en nuestro trabajo y en la comunidad, nuestro crecimiento será exponencial. Colaborar en proyectos de código abierto, compartir nuestro conocimiento con otros y contribuir al desarrollo de nuevas soluciones nos ayudará a aumentar nuestra influencia y a expandir nuestras oportunidades profesionales.

La responsabilidad es tuya

La responsabilidad de crecer en la carrera de desarrollo de software va más allá de aprender nuevas tecnologías y herramientas. Debemos elegir cuidadosamente dónde y con quién trabajamos, ser resilientes ante los desafíos, desarrollar nuestras habilidades blandas y buscar tener un mayor impacto en nuestro entorno. Al tomar las riendas de nuestra carrera profesional, no solo mejoraremos como desarrolladores, sino que también contribuiremos al crecimiento de nuestra comunidad y de la industria en su conjunto.

Inteligencia Artificial reemplazará 7,800 empleos en IBM; pausan contrataciones

Reuters reporta que IBM busca reemplazar miles de empleos con inteligencia artificial:

La contratación específicamente en funciones de oficina, como recursos humanos, se suspenderá o disminuirá, dijo Krishna, agregando que el 30% de los roles que no interactúan con clientes podrían ser reemplazados por inteligencia artificial y automatizaciones en cinco años.

Definitivamente, estamos entrando en una nueva era del desarrollo profesional.

El 2 de julio del 2021 escribí en este blog:

Lo que uno como desarrollador de software está buscando constantemente es la automatización de tareas mecánicas y manuales. La ironía es que, en sí, programar también es una tarea mecánica y manual. Y como tal, eventualmente también será automatizada.

En aquel entonces, hablaba sobre GitHub Copilot y sus implicaciones en la industria del desarrollo de software. Continúo:

La tendencia es clara. La verdadera ventaja competitiva para un desarrollador de software no será la parte técnica, sino las habilidades interpersonales.

Esto ya está sucediendo. Puede ser que los empleos de desarrollador de software aún no se vean directamente afectados por la automatización, pero el equivalente ya está sucediendo en otras industrias.

Evita frustrar aún más a tus usuarios con tu documentación

Escribir documentación es una de las habilidades más importantes de un desarrollador.

JustSimply.dev:

Si alguien ha llegado a buscar algo que has escrito en Google, significa que está atascado. Estar atascado puede ser frustrante y molesto. Así que trata de no hacer que se sienta peor diciéndole lo fácil que debería ser encontrar lo que busca. Esto puede obstaculizar su capacidad para aprender lo que quieres que aprenda.

Es probable que tengas la tentación de que al escribir documentación sobre tus proyectos, quieras usar palabras como “sencillo”, “fácil”, “simplemente”, “nada más”.

Se entiende. Lo que quieres es contarle a tu usuario lo mucho que estás haciendo por él o ella, resaltando lo poco que tienen que hacer para resolver su problema ahora que va a utilizar tu solución.

Desafortunadamente, con lo que tu lector se va a quedar es con un sentimiento de frustración e insuficiencia, pues en lo que ha estado atorado todo este tiempo, resulta ser “fácil” de resolver.

Tenemos que ser más cuidadosos y compasivos al momento de escribir documentación. Si alguien la está consultando, es porque quiere aprender algo más. Lo menos que podemos hacer es procurar que las personas que nos leen no se queden con la idea de que, dhu, lo que estás buscando es OBVIO.

Trabajar en tecnología en tiempos de recesión: ¿deberías preocuparte?

Si trabajas en la industria de la tecnología, es posible que hayas notado que muchas empresas están haciendo reducciones de personal. Pero ¿deberías preocuparte por tu trabajo en tiempos de recesión?

En la industria de la tecnología, las reducciones de personal no solo ocurren ante o durante una recesión. Las empresas pueden hacerlas en cualquier momento, incluso en tiempos de crecimiento económico. Y aunque es común que las empresas sigan las tendencias de la industria, muchas de las que están haciendo reducciones de personal son aquellas que contrataron de manera indiscriminada durante la pandemia.

En lugar de preocuparte por una posible recesión, es mejor centrarse en tomar oportunidades cuando se presentan. Si una buena oportunidad llega a tu puerta, no debes preocuparte por el futuro. Nadie puede predecir con certeza lo que va a pasar, y es mejor trabajar con lo que se tiene.

Pero, ¿qué hay de tu trabajo actual? Si bien no puedes predecir si tu empresa hará reducciones de personal en el futuro, puedes tomar medidas para proteger tu carrera en la industria de la tecnología. Asegúrate de estar al tanto de las últimas tendencias y tecnologías, y busca maneras de mejorar tus habilidades y conocimientos.

Busca oportunidades, mejora tus habilidades y conocimientos. Enfócate en ser alguien que agrega valor. Todo lo demás es circunstancial.

No te limites: cómo aprovechar al máximo tu pasantía

Las pasantías son una excelente manera de adquirir experiencia práctica en tu campo, pero tener una “mentalidad de aprendiz” puede limitar tu crecimiento. Esta mentalidad incluye dudar de tu capacidad para aprender, pensar que no tienes agencia y esperar que otros te den respuestas.

Para aprovechar al máximo tu pasantía, asume la responsabilidad de tu experiencia de aprendizaje. No la trates como un requisito de graduación; utilízala como una oportunidad para aplicar conocimientos teóricos y aprender nuevas habilidades.

Recuerda que las habilidades técnicas son esenciales, pero el conocimiento académico por sí solo no es suficiente para el éxito. Haz que tus habilidades se destaquen en la práctica y busca comentarios de tus compañeros. Usa tu pasantía para adquirir experiencia práctica y aprender de tus colegas de la industria.

Las pasantías ofrecen valiosas experiencias de aprendizaje para habilidades prácticas y conocimientos de la industria. No limites tu crecimiento con una “mentalidad de aprendiz”. Asume la responsabilidad de tu aprendizaje, aplica el conocimiento teórico a la práctica y busca comentarios de tus compañeros para prepararte para tu carrera futura.

8 verdades que aprendí cuando me despidieron de un trabajo como Software Engineer

Steve Buccini, escribiendo en su blog:

La única cosa que deseaba más que nada después de que me corrieran, incluso más que cualquier otro trabajo, era que alguien levantara la mano y hablara en términos simples, honestamente y con toda franquesa. Ese es mi objetivo con esta pieza.

Que te corran de un trabajo es un evento importante en tu carrera profesional. Casi me atrevería a decir que es un rito de paso. Irónicamente, poco se habla de esto en la industria.

Steve comparte 8 cosas que aprendió de la experiencia:

Que te corran es una experiencia profundamente solitaria
Va a tomar más de lo que piensas
La cantidad de entrevistas que tienes no son necesariamente un reflejo de qué tan deseable eres como profesional
Tendrás que hacer cosas que no quieres hacer
La mayoría de los ofrecimientos para ayudarte son respuestas reflexivas
La honestidad solamente te puede perjudicar
Probablemente, deberías de rechazar esa oferta de trabajo
Aprenderás más de que te corran que de lo que hiciste en tu trabajo

Si te tomas el tiempo de leer la pieza completa, probablemente estés de acuerdo conmigo: hay algunos dejos de resentimiento y frustración en el lenguaje. Me gustaría que tomaras esto en consideración si es que decides tomar estos aprendizajes de corazón.

Resalto el aprendizaje número 8 de Steve: Aprenderás más de que te corran que de lo que hiciste en el trabajo. Comenta:

Después de que me corrieran, mi principal emoción era una de alivio. No me lo esperaba. Estaba en aprietos: COVID estaba con toda la fuerza y ya no tenía seguro, el mercado de valores estaba cayéndose y tenía poco efectivo, vivía fuera de mi país y estaban cerrando las fronteras. ¿Por qué sentiría alivio? Porque sabía que no me gustaba mi trabajo, pero no tenía el valor de renunciar para cuando la pandemia llegó. Me hicieron un favor al aventarme por la borda.

Mi deseo es que, como Steve, tú eventualmente aprendas que detenerte a preguntarte qué es lo que realmente quieres, y actuar por ello, no es un acto de egoísmo, sino de valentía. Solo espero que no te tengan que correr para que lo entiendas.

No tienes que convertirte en Manager después de ser Senior

El otro día, un amigo que ya estaba trabajando como programador cuando yo apenas iba en 6° de primaria, se sinceró conmigo.

A pesar de que en su trabajo le pagan bastante bien, y bajo todos los estándares, es un buen empleo, está extremadamente frustrado. “Ya estoy harto de hacer diario lo mismo.” Me platicó que su día a día se ha vuelto tan monótono, que hasta las ganas de programar se le están quitando.

“No hay nada interesante para hacer. Puros forms, maquetado, y resolver bugs de renderizado.”

Cuando le pregunté si había algo que pudiera hacer para cambiar su situación, su respuesta no me sorprendió en absoluto.

“Sí, ser manager. Pero me caga la gente.”

Algunas personas, cuando llegan a cierto nivel de seniority como desarrolladores, dejan de preocuparse por su carrera. Le dejan de prestar atención a su crecimiento profesional porque creen que el único paso que está delante es el convertirse en management. Algo que no quieren hacer.

Opino que esto viene de la idea de que únicamente existe un camino de crecimiento profesional. Como mencioné en la última Sesión Grupal de Soft Skills para Devs, esto es completamente erróneo.

Llegar a cierto nivel de seniority como desarrollador no significa que no puedes seguir avanzando en tu carrera. Después de convertirte en experto en tu tecnología, tendrás más oportunidades de aportar valor de una manera mucho más amplia. Si no te quieres convertir en manager, después de ser Senior, te podrás convertir en Staff Engineer. Y si quieres continuar por la ruta de contribuidor individual, es decir, sin tener que manejar personas, puedes incluso llegar a convertirte en Principal Engineer.

En la empresa correcta, una vez que eres Senior, convertirte en manager no es “lo que sigue”.

Pero hay una trampa: mientras más creces en tu carrera como contribuidor individual, menos se mide tu impacto en líneas de código. Habilitar a otros desarrolladores, aportar valor a otros equipos y áreas de negocio, dar visibilidad a problemas. Todas estas son competencias clave que vas a tener que desarrollar, sí o sí. Todas ellas, van a requerir que le pongas atención, de alguna u otra manera, a tus Soft Skills y a tus habilidades de colaboración con otras personas.

Está bien que no te guste (o te cague) la gente. No todas las personas somos sociales por naturaleza.

Pero la oportunidad de mejorar tu carrera ahí está. Si no quieres convertirte en manager, no tienes que hacerlo.

Lo que sí tienes que hacer, es asegurarte de estar en la empresa correcta para seguir creciendo sin tener que tomar tareas administrativas. Y trabajar en tus Soft Skills.

Convertirte en manager no es un ascenso. Es un cambio de carrera.

Si en tu empresa te quieren “promover” a manager porque eres la persona con mejores capacidades técnicas de tu equipo: felicidades. Acabas de ser víctima del Principio de Peter, que dice:

“En una jerarquía, todo empleado tiende a ascender hasta su nivel de incompetencia: la nata sube hasta cortarse.”

¿Hiciste un buen trabajo como Jr.? Felicidades, ahora eres Mid. ¿Seguiste haciendo un buen trabajo? Genial, ahora eres Sr. ¿Sigues siendo excelente en tu trabajo como desarrollador? Felicidades, ahora tienes un conjunto de responsabilidades para las que no estás preparado, y probablemente ni siquiera quieras tomar.

Las habilidades fundamentales que te hicieron tener éxito como contribuidor individual, no son las mismas que te harán tener éxito como manager.

Escribir “buen” código no se traduce en capacidad para analizar y resolver problemas organizacionales. Saber escoger el lenguaje de programación o framework adecuado para resolver un problema de arquitectura, no se traduce en saber entender las necesidades personales y aspiraciones profesionales de tu equipo, y alinearlas con las de la empresa.

Probablemente, dentro de tu organización, el convertirte en manager venga con aumentos salariales o mayores prestaciones. Pero ten en cuenta que es un trabajo completamente diferente. Convertirte en manager no es un ascenso. Es un cambio de carrera completo. Puede que estés trabajando en tu misma industria; incluso hasta con el mismo equipo. Pero tus responsabilidades ahora son completamente diferentes.

Antes de aceptar el “ascenso”, pregúntate: ¿sabes a qué te estás metiendo? ¿Estás consciente de las implicaciones del nuevo rol? Y más importante aún, ¿quieres hacerlo?

No tener claras las respuestas a estas preguntas te pone en riesgo de sufrir burnout.

Estarás jugando otro juego. Uno que no conoces. ¿Cómo vas a ganar?

Qué hacer si presencias acoso en tu trabajo o comunidad

Acabo de participar en un entrenamiento para prevenir acoso y discriminación en equipos de trabajo.

Me pareció que esta información debería compartirse. Así que aquí tienes 6 cosas que puedes hacer si presencias acoso en el trabajo, comunidad o sociedad en general, incluso si no eres manager.

Interrumpe la conversación

Haz algún comentario que desvíe la conversación e interrumpa el acto de acoso. Puede ser una broma, un cambio drástico de tema, o simplemente hacer un ruido que cambie el foco del grupo.

Pregúntale a la persona cómo se encuentra

Acércate a tocar base, y pregunta si hay algo que puedas hacer para ayudarle.

Aborda a la persona cometiendo el acoso

Especialmente en ambientes donde no estamos sensibilizados en cuestiones de acoso, es importante dar visibilidad y resaltar acciones imprudentes y dañinas.

Asume que la persona es ignorante de efecto de su comportamiento, y ofrece una perspectiva diferente: “Sé que tal vez no quisiste decir esto, pero este fue el efecto de tu comentario.”

Apela a la amistad y empatía con la víctima

Hazle saber que tiene aliados, y que no está solo o sola. Reconoce que presenciaste lo que sucedió, y que estás ahí para apoyarle en lo que necesite, aunque sea simplemente moralmente.

Da retroalimentación directa y clara en el momento

“Aquí no hacemos o decimos eso, bajo ninguna circunstancia.”

Niégate a ser parte de la situación, y llévate a otros contigo

El mensaje más valioso que puedes mandar es que no te vas a prestar a crear un foro para este tipo de actos.

En cuanto te percates de que alguien está siendo acosado, retírate de la situación y busca que otros te sigan.

A veces lo que se necesita es alguien a quien seguir.

Ponerle un alto al acoso es responsabilidad compartida

“Acoso” puede significar cosas diferentes dependiendo el contexto. Apela a tus valores, o las reglas de convivencia del grupo, para aprender a identificarlos.

Pero hay un tipo de acoso que es incuestionable: calumnias, bromas sexuales, transgresión del espacio personal, comentarios hirientes o fuera de lugar.

Si observas cualquier tipo de acoso y no haces nada para resaltarlo y detenerlo, también eres parte del problema.

Ser Engineering Manager: los primeros aprendizajes

A finales de 2019 decidí cambiar la dirección de mi carrera profesional y probar suerte como Engineering Manager.

Para este entonces, tenía un poco más de 10 años de experiencia desarrollando software como contribuidor individual.

Hoy me encuentro iniciando mi tercer año como Engineering Manager, y creo que es una buena oportunidad para reflexionar sobre estos primeros dos años. Te quiero compartir algunos aprendizajes que he adquirido, con la intención de que te sean de utilidad si es que decides seguir un camino similar al mío.

Pero antes…

¿Cómo me convertí en Engineering Manager?

Llegué al puesto de Engineering Manager con un set de ideas bastante claras sobre el tipo de líder que quería ser, así como de las estrategias particulares que emplearía para lograrlo. El tema de liderazgo y la psicología organizacional siempre me han llamado la atención, y continuamente estoy aprendiendo y educándome en estas áreas.

Durante mi tiempo como desarrollador, tuve la oportunidad de experimentar de primera mano los beneficios de tener líderes que genuinamente procuraban mi bienestar y mi crecimiento. También me tocó tener jefes, de los clásicos que nadie debería tener. Pude ver, gozar, y sufrir, gran parte del espectro de los tipos de líderes que existen.

También es importante compartir que adquirí mi experiencia profesional, principalmente en un ambiente de startups de Estados Unidos y Europa. Esto jugó un papel considerable en mi transición, pues mis primeros dos años como Engineering Manager fueron trabajando para empresas Mexicanas. A pesar de que soy mexicano, habiendo trabajado principalmente con personas extranjeras, sentí el cambio cultural.

Lo que aquí te voy a compartir no son verdades universales ni reglas. Tómalas como lo que son: interpretaciones de situaciones que viví a través de mis valores, experiencias propias y deseos personales.

Tus decisiones, por más pequeñas que sean, tienen grandes implicaciones

Como gerente de ingeniería, tus decisiones tienen la capacidad de influenciar desde la composición técnica de tu proyecto, hasta aspectos fundamentales del negocio. Pero, mayormente, tus decisiones afectan la carrera profesional de las personas a tu cargo.

Cualquier decisión que tomes, debes de factorizar el impacto a mediano y largo plazo que esta va a tener en la carrera de las personas con las que trabajas.

Sí, el producto es importante. Pero sin un equipo sano, todo pasa a segundo plano.

Tu trabajo como Engineering Manager es habilitar a tu equipo

Es demasiado sencillo llegar a un puesto de Engineering Manager pensando que lo que se espera de ti es que asignes tareas, y te asegures de que se cumplan a tiempo. Y hay personas que podrían argumentar que sí, ese es el trabajo. Yo creo que es un poco más complicado que eso.

El Engineering Manager, a diferencia de un Project Manager, se encarga de entender las necesidades y visión del negocio. Además, asimila las fortalezas, debilidades, y deseos de su equipo. El reto es alinear estos dos mundos de una manera coherente, sostenible y humana.

Parte de tus responsabilidades es procurar que los proyectos salgan a tiempo y en forma. Pero no asegurarte. ¿Qué vas a hacer, obligar a tu equipo a que trabaje horas extras? ¿Preguntarles “cómo vamos” cada 3 horas? ¿Intentar comprar su felicidad con pizzas y refresco? Todos hemos tenido (o por lo menos escuchado de) gerentes que usan esas tácticas. Personas para las cuales lo más importante es la fecha, el cliente y su reputación, no su equipo.

Reflexiona: ¿te gustaría (volver a) trabajar con una persona así?

Por eso digo que el Engineering Manager procura que las cosas salgan bien. Entiende las necesidades de su equipo (las personas), tiene conciencia de un balance adecuado entre vida y trabajo, y además reconoce y asimila las capacidades de cada uno de los miembros de su equipo. Después toma toda esta información, y crea estrategias, procesos y formas de trabajo que produzcan resultados fiables, en tiempo y forma. En este video exploro un poco más este tema.

Tienes que buscar un balance sostenible

La analogía que me gusta utilizar para este punto es la de las mascarillas de oxígeno en los aviones. Antes de despegar, el personal del avión hace las demostraciones de seguridad pertinentes, y comentan al respecto: “en caso de despresurización, antes de intentar ayudar a otras personas, asegúrese de tener la mascarilla bien puesta usted”.

El mismo consejo aplica para alguien en el rol de Engineering Manager.

Como alguien que desarrolla software (y más si vienes de la cultura Latinoamericana), probablemente te acostumbraste a glorificar el trabajo duro y pensar que estar ocupado es un símbolo de que estás haciendo algo importante. Cuando tienes ese bagaje cultural y de repente te encuentras en un rol de gerencia, naturalmente vas a buscar formas de mantenerte ocupado.

Lo que para ti pudiera parecer ayuda, para tu equipo se convierte en un perjuicio.

No solamente importan las decisiones que tomas, sino cómo las tomas. El equipo que manejas aprende de tu estilo de resolución de problemas. Si no eres cuidadoso, precavido, diligente, transparente y disciplinado, le estás enseñando a tu equipo que está bien tomar decisiones “al ahí se va”.

Al inicio de mi carrera como Engineering Manager tenía lo anterior bien claro. A pesar de esto, no pude evitar caer (algunas veces) en la comodidad de tomar decisiones por mi cuenta y simplemente asignar tickets a mis equipos. No fue sino hasta después de un par de iteraciones, que me di cuenta de que la forma de trabajo que estaba impulsando no era sostenible. No solamente me estaba creando más trabajo, sino que además estaba afectando directamente el crecimiento de mis equipos.

Fue ahí cuando “hizo clic” la idea de que para ser un buen Engineering Manager, tenía que preocuparme más por habilitar a otras personas, que por hacer el trabajo yo mismo.

El feedback loop es muy largo

Tus decisiones deberían de estar basadas en el bienestar, sostenibilidad y productividad de tu equipo. Y los resultados de los cambios que implementes para fomentar una cultura de trabajo positiva tardan bastante ser aparentes.

Si tomas una decisión en función de prevenir el burnout de tu equipo, por ejemplo, el rango de tiempo para darte cuenta de si la estrategia está funcionando o no, podría ser de meses. No solo porque los cambios organizacionales son complejos y tardados, sino porque es muy difícil tomar una medición discreta del bienestar de una persona. Aunque tengas 1on1s recurrentes con cada miembro de tu equipo, las variaciones de estado de ánimo de una semana a otra pueden ser bastante grandes — y no siempre gracias a factores que tú puedas controlar.

Es por eso que como Engineering Manager tienes que enfocarte en las tendencias que ves en el equipo, no en datos discretos. Todos tenemos días malos, y si ves que alguien no la está pasando tan bien en tu equipo, no necesariamente tienes que hacer algo de manera inmediata (a menos que la situación lo amerite). Pero cuando ves que alguien ya lleva varias semanas pasándola mal, es momento de cambiar algo.

Cambiando el paradigma

Creo que hoy, más que nunca, es importante que humanicemos nuestro trabajo, y dejemos de glorificar las horas extras y el sacrificio del bienestar mental y emocional de las personas. Y considero que el Engineering Manager tiene un papel fundamental en esta transición.

Convertirme en Engineering Manager ha sido un proceso interesante. He aprendido mucho sobre mí y mis sesgos. Me he enfrentado a mi propio ego, y me ha ayudado a entender que el mundo en el que vivimos tiene muchos más matices de los que pensaba.

¿He tenido mis momentos difíciles? Sí. ¿He cometido errores? También.

Pero también he aprendido, y he crecido. Y si reflexiono un poco sobre estos primeros dos años en esta carrera, siendo honesto, considero que lo estoy disfrutando más de lo que disfruté mis primeros dos años como desarrollador.

Algunas reflexiones extras:

No todas las empresas necesitan Engineering Managers. Hay algunas empresas que simplemente necesitan un Project Manager con nociones de ingeniería de software, pero no un Engineering Manager. Asegúrate de que sabes qué es lo que realmente necesitan.
Ser Manager significa algo diferente para cada empresa. No te quedes simplemente con el título, indaga un poco más en cuáles son realmente las tareas y expectativas del puesto.
Ser Manager no es para todos. Muchas personas creen que la progresión natural de una carrera en esta industria apunta hacia puestos de gerencia, pero no es así. Ser bueno escribiendo software desafortunadamente no te hace buen manager.
Para ser Manager, necesitas renunciar a tu identidad como desarrollador. Ve este video.

¿Cómo le hacen los que no pueden usar Git en su trabajo?

Un usuario de Reddit escribe:

Esta mañana, gasté 3 horas reescribiendo lo que hice ayer, porque mi compañero lo eliminó accidentalmente en la carpeta de Windows Server que usamos para desarrollar. No nos permiten utilizar control de versiones, y de hecho, muchos de mis compañeros de trabajo nunca han escuchado de Git. ¿Alguno de ustedes ha trabajado en algún lugar así y encontrado una manera de sobrellevarlo?

Obviamente, las respuestas recomendándole que huyera de ahí lo más rápido posible no se hicieron esperar.

Hace casi 22 años, Joel Spolsky publicó en su blog su popular checklist para determinar si un equipo de desarrollo de software es bueno o no: 12 Pasos Hacia Mejor Código. La primera pregunta es: ¿Tu equipo usa manejador de versiones?

Aunque es fácil caer en la tentación de burlarse del creador del hilo en Reddit, me gustaría reflexionar sobre su situación.

Recordando que muchas personas crecimos con la idealización del trabajo duro, no es difícil ver cómo esa forma de pensar podría llevarnos a la progresión lógica de que cualquier cosa que le haga al programador la vida más fácil significaría que entonces la empresa no lo está aprovechando al máximo. Estoy seguro de que podrás identificar alguna persona en tu vida (probablemente alguien mayor, o “de la vieja guardia”) que defendería esta retórica. “Los programadores de verdad compilan su propio IDE.” Esto es lo que pasa cuando personas con esta mentalidad dirigen empresas.

(Dándoles el beneficio de la duda: es probable que esta persona esté trabajando en una industria donde únicamente se pueden utilizar tecnologías aprobadas y validadas por algún tipo de organismo o estándar. En este caso, entendería que, por regulación, no estuviera permitido que usaran tecnologías de código abierto.)

Por otro lado, es probable que el autor original del hilo simplemente se encuentre rodeado de gente que ignora la existencia de los controladores de versiones, así como sus beneficios. Un par de veces en mi vida me he encontrado con personas que encuentran abrumadora la idea de tener que aprender otra tecnología (Git) además del lenguaje de programación en el que están especializándose. Así que simplemente hacen lo que pueden con lo que saben: ponen su código en Dropbox, Google Drive, y listo. No es hasta que salen problemas que el valor de usar controladores de versiones se vuelve aparente.

La parte clave de su mensaje es esta:

No nos permiten utilizar control de versiones, y de hecho, muchos de mis compañeros de trabajo nunca han escuchado de Git.

Apostaría que la persona que escribió esto encaja en el siguiente perfil: alguien joven, al inicio de su carrera en software, con grandes aspiraciones, en su primer trabajo formal. Probablemente, la empresa sea de una industria vieja (finanzas, construcción, legales, donde las cosas se hacen por regulación) que se está intentando renovar, y lo están haciendo contratando programadores, pero sin crear una cultura de desarrollo de software.

No conozco al autor del hilo, pero no me sorprendería si tuviera una carrera próspera en su futuro. Después de todo, está demostrando una capacidad que (desafortunadamente) no todos tienen: la de cuestionar el statu quo. No se está quejando, está haciendo una pregunta para educarse y crecer. Está buscando datos, consejos y soluciones.

Algunas lecciones que me gustaría que todos nos lleváramos de esta experiencia:

No en todas las empresas se puede desarrollar software. Ve esta porción de una de mis charlas para entender más sobre esto.
Algunas empresas solamente quieren programadores, no desarrolladores.
Desarrollar software es mucho más que escribir código.
Se vale preguntar, cuestionar y decidir si la situación en la que estás es en la que quieres estar.

El Open Source no se trata de ti

Rich Hickey, creador de Clojure, escribiendo en GitHub Gist:

Ser usuario de algo que es Open Source, no te hace merecedor de nada en absoluto. No necesitas contribuir. No tienes por qué exigir nuevas características. No te mereces la atención de otros. No significa que tus quejas tengan un valor para el producto. No te mereces esta explicación.

Si tienes expectativas (de otros) que no están siendo cumplidas, esas expectativas son tu propia responsabilidad. Eres responsable de tus necesidades. Si quieres algo, hazlo.

Hace un tiempo escribía sobre como ser desarrollador Open Source parecía no ser tan buena idea hoy en día. El Gist que publica Rich no es nuevo, tiene por lo menos unos 5 o 6 años, pero demuestra la tendencia hacia el burn-out que muchos administradores de proyectos Open Source hoy están reportando.

No inviertas más en tu educación. Invierte más, y mejor.

Publiqué este Tweet justo antes de inscribirme en un curso algo costoso. Me dio curiosidad saber cuánto dinero invierten las personas en su educación al año.

USD $500 (MXN $10,000) es también más o menos lo que había estado invirtiendo anualmente en mi educación, en promedio, hasta 2020.

Me puse a reflexionar, y me di cuenta de que, por lo menos en mi caso, durante mi proceso de formación, nunca se me inculcó la importancia de invertir en educación. Claro, se me mencionó que la educación continua era importante. Pero nunca se me dijo que una de las formas de mantenerme educado continuamente era “aventándole dinero al problema”.

Suena raro, ¿no? Hasta parece obvio.

Sin embargo, en mi caso, creo que interpreté la idea de “educación continua” como “aprende lo más que puedas de las situaciones que se te presenten”. Que es un consejo sabio, y lo aplico. Pero nunca me pasó por la cabeza que podía influenciar directamente la calidad de la educación que recibía incrementando la cantidad de dinero que le destinaba a ello.

Hasta que lo intenté. Dejé de buscar cantidad, y me enfoqué en calidad.

Hoy en día prefiero mil veces tomar el toro por los cuernos y trabajar con un especialista en sesiones individuales de coaching, que comprar 10 cursos diferentes a 95 % de descuento (tú sabes de qué plataforma hablo) — simplemente para nunca realmente darme el tiempo de ver los videos y hacer mi tarea.

Cada uno de nosotros aprende de manera diferente. Yo encontré que me funciona mucho más tomar clases en vivo, acompañado de una cohorte de alumnos, que suscribirme a una plataforma de videos y verlos por mi cuenta. Descubrí que me funciona más comprar libros físicos y tenerlos a la mano de manera tangible, que buscar PDF gratuitos y leerlos en mi iPad.

Muchas personas confundimos cantidad con calidad. Creemos que simplemente comprar libros, videos y suscripciones, cuenta como educarnos. No leer, ejecutar o participar. Comprar.

Tener acceso a más información no es lo mismo que tener mejor educación.

¿Tú cuánto inviertes en tu educación al año? Y si tuvieras que duplicarlo, ¿simplemente invertirías más? ¿O invertirías más y mejor?

Video: El costo de especializarte

Otro clip tomado de la participación que tuve en The Dojo, el canal de mi amigo Héctor, hace unos meses. En este, hablo sobre lo que tuve que sacrificar para especializarme como desarrollador de iOS, y las implicaciones que eso tuvo en mi vida. El artículo de Paul Graham que menciono se llama Bus ticket theory of genius.

Explicando código con arte ASCII

Aquí hay otro ejemplo de cómo la documentación aumenta el valor de tu código. John Regehr recopiló imágenes de cómo en algunos proyectos de código abierto se usa arte ASCII para explicar el código de manera más clara.

En su artículo, escribe:

Las personas tienden a ser visuales: usamos imágenes para entender problemas. Los lenguajes de programación más populares, por el contrario, operan en un espacio completamente abstracto, dejando una gran brecha entre programa e imagen.

Un ejemplo tomado del compilador de Swift:

Puedes utilizar apps como Mondraw para crear este tipo de documentación. Recuerda el Triángulo de la Documentación de Código, y que agregar documentación no es una admisión de que no fuiste lo suficientemente inteligente para escribir “buen” código.

El Triángulo de la Documentación de Código

Hace un tiempo propuse que deberías escribir código que se documente solo, y luego agregarle documentación. En el artículo original, escribí:

La idea de que “tu código debería de documentarse solo” no es un get out of jail free card para no documentar tu código. Las ocasiones en tu carrera profesional donde escribir documentación no agrega valor a tu trabajo son muy pocas. Tan pocas, de hecho, que no se me viene ninguna a la mente. ¿Tal vez cuando estás trabajando en un proyecto propio? Pero hasta Damian Conway dijo que “la documentación es una carta de amor que le escribes a tu yo del futuro”.

Hoy me encontré una idea que aumenta mi punto: El Triángulo de la Documentación de Código.

Este modelo mental nos dice que toda pieza de código está documentada en 3 dimensiones distintas, cada una respondiendo una pregunta muy particular.

¿Qué?: Tu código, en sí, explica lo que estás haciendo.
¿Por qué?: Los comentarios que le agregas a tu código, explican tu proceso de toma de decisiones y la razón de tus soluciones.
¿Cómo?: El contexto dentro del cual estás desarrollando tu programa; la descripción original del problema.

Si te enfocas en escribir código que “se documente solo”, en un futuro no sabrás por qué llegaste a esa solución, ni cómo esa solución es apropiada para el problema original.

Recuerda, agregar documentación a tu código (en forma de comentarios, glosarios, RFCs, pruebas, etc.), no es una admisión que no fuiste lo suficientemente inteligente para escribir “buen” código, sino un acto de compasión. Demuestra tu interés porque la siguiente persona que modifique tu código pueda enfocarse en agregar valor al proyecto — y, muy probablemente, esa siguiente persona vas a ser tú.

GitHub Copilot ahora disponible de manera general

Hace un par de días, GitHub anunció que Copilot está ahora disponible de manera general.

Cualquier persona, hoy puede pagar $10 USD mensualmente por un compañero de pair programming creado con inteligencia artificial.

Buen momento para recordar lo que escribí hace casi exactamente un año:

Con el aspecto técnico resuelto (parcialmente) por inteligencias artificiales, las discusiones técnicas dejarán de ser la parte más importante del desarrollo. Los “programadores” ahora se dedicarán a tener discusiones sobre la ética y seguridad del código generado por la computadora. Las tareas técnicas serán resueltas, en su mayoría, gracias a la ley de Moore. Desarrollar software ya no se tratará de programar.

Aún habrá trabajos para escribir código, pero requerirán una alta especialización. Las personas que sigan escribiendo código lo harán para crear la infraestructura que soportará al resto del ecosistema: compiladores, IA, generadores de código, redes, etc.

Si estás en la industria del software y piensas que tu único trabajo es programar, heads up. Le acaban de poner fecha de caducidad a tu carrera. Y tienes de dos: o te pones a refinar tus soft skills, o comienzas a especializarte en tecnologías fundamentales.

Fomenta una cultura de privacidad, no de secretos

El término “comunicación” es tan amplio y dependiente del contexto del trabajo y la industria en la que uno se desempeña, que muchas organizaciones deciden simplemente no ponerle mucha atención. Adoptan una mentalidad de que “lo que importa es que las cosas se hagan, pero no importa cómo.”

Adam Thomas escribió brillantemente al respecto (traducido por mí):

La cultura de comunicación de tu empresa tiene un gran impacto en el resto de tu negocio. Cultivar una atmósfera de confianza es esencial para el éxito. El nivel de confianza que las personas en tu organización depositan en sus líderes y en ellos mismos, afecta la productividad, la salud de tus compañeros y la retención a largo plazo del equipo.

En su artículo, Adam menciona que existen principalmente dos tipos de empresas: las que quieren hacer las cosas en privado, y las que quieren hacer las cosas en secreto. La diferencia es sutil, pero el diablo está en los detalles.

Cualquier información que se comparta llamadas, mensajes directos o canales privados se pierde en el limbo. Esto le resta visibilidad al equipo, se pierde la trazabilidad del proceso de toma de decisiones, y en muy poco tiempo, la confianza del equipo se ve mermada por esta opacidad.

A muchos líderes les cuesta trabajo ver más allá de la meta puntual que tienen en frente, e ignoran las consecuencias de fomentar una cultura de comunicación que hace que los miembros del equipo se sientan asediados, estresados e inseguros.

Personalmente, estoy consciente de estos problemas y lo fácil que es caer en una situación de secresía. En mis equipos procuramos que cualquier llamada que tengamos con otros miembros quede resumida en un mensaje donde se listen los acuerdos a los que se llegaron. También, usamos canales de Slack públicos por defecto, y todos tenemos la expectativa de mover cualquier pregunta que nos hagan por DM a un canal público.

Durante los más de 12 años en la industria del software, he aprendido a identificar que si sientes que necesitan comunicar algo en secreto (por DM, en una llamada, o por medios fuera de la compañía), significa que inconscientemente no confías en tu compañía. La cultura está rota.

Legislatura en Washington obliga a que las vacantes incluyan información de salario completa

El Proyecto de Ley 5761-S, en la legislatura de Washington, dicta que las descripciones de vacantes deberán incluir detalles completos de la compensación que recibirá la persona contratada.

Puedes leer el documento final aquí. A considerar es que esto solamente aplicaría para compañías que tengan 15 o más empleados.

Espero que esto se vuelva práctica estándar eventualmente.