Archivo de la etiqueta: trabajo en equipo

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.

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.

La diferencia entre trabajar en producto vs. consultoría

Toda la diferencia entre el trabajo de producto vs. el de consultoría está en los incentivos que determinan el cómo se trabaja.

Hacer consultoría se trata de completar proyectos para un cliente. El objetivo es entregar a tiempo y cumplir con un contrato.

Si trabajas en consultoría, lo que importa es entregar en tiempo y forma, lo que significa que la calidad y exactitud técnica del desarrollo no es prioridad. Después de todo, hay una gran posibilidad de que una vez que se llegue a la meta, y el cliente esté satisfecho, no será necesario revisarlo ni mantenerlo a largo plazo. Se le resolvió el problema al cliente, se entregó a tiempo y con los requerimientos cumplidos, y ahora puedes pasarte a pensar en el siguiente proyecto sin voltear atrás.

Trabajar en desarrollo de producto se trata de resolver problemas para un usuario. El objetivo es agregar valor.

Al desarrollar un producto, lo que estás buscando es crear tecnología para resolverle un problema a tu usuario. Muy probablemente (si trabajas en un startup, por ejemplo) no habrá una guía para encontrar la forma óptima de agregar valor. Tendrás que experimentar, investigar, innovar. Pero más importante, trabajar en producto tiene la implicación de que el mismo equipo será el responsable de arreglar cualquier cosa que se rompa, y de saldar cualquier deuda técnica que se adquiera.

La fuente de frustración más grande que he experimentado es cuando he intentado desarrollar un producto como si trabajara en consultoría, y viceversa. Pero dejo esa historia para otra publicación.

Un demo te ahorra o te compra problemas

Para un desarrollador de software es sencillo comprender por qué un proyecto se puede complicar. Entendemos las implicaciones y complejidades de desarrollar soluciones.

En una empresa tradicional, para bien o para mal, las personas que terminan tomando decisiones no siempre tienen el mismo nivel de entendimiento.

Tener el hábito de hacer demostraciones, demos, de tu trabajo ayuda a achicar esta brecha de entendimiento.

Un demo tiene el potencial de comprarte o ahorrarte problemas. Si del demo salen con más preguntas que respuestas, te compraste problemas. Si salen inspirados, con más ideas, te ahorraste problemas.

Es por eso que es importante que tomes los demos con seriedad. Porque a final de cuentas, desde un estricto punto de vista de negocio: si algo no funciona no sirve, y si algo no sirve, ¿para qué lo quiero? Un buen demo es tu oportunidad de evitar que alguien con poder de decisión a nivel negocio se haga esta pregunta.

El nombre que le pones a las cosas sí importa

“En las ciencias de la computación, hay únicamente dos problemas difíciles de responder: la invalidación de un caché, y cómo nombrar cosas.” — Phil Karlton

La cultura del Internet después modificó este refrán para incluir errores de enumeración de índices, pero esa es otra historia.

La realidad es que Phil tenía mucha razón: decidir cómo nombrar las entidades que manipulamos al programar es una de las tareas más difíciles de nuestra profesión. No por nada es tan común ver variables, métodos, clases, funciones, o cualquier otro elemento de programas, con nombres genéricos, como x, builder o manager.

Algunos argumentan que invertir tiempo en nombrar los componentes de un programa de manera coherente es una pérdida de tiempo. Las veces que he participado en discusiones donde se intenta impulsar la idea de que alguien debería poder diferenciar una variable X de otra simplemente por el nivel de sangría del código son demasiadas. Creo que desafortunadamente esto es otra muestra de lo inusual que es el sentido de compasión en la industria de la tecnología.

Al igual que agregar documentación completa a tus proyectos, usar nombres descriptivos y semánticamente correctos es un acto de compasión.

El lenguaje es el medio a través del cual los humanos razonamos sobre las ideas de nuestro día a día. Al compilador no le importa el nombre de tu variable, pero a la persona que va a leer y contribuir a tu código sí. Y como siempre, es importante recalcar que esa persona puedes ser tú mismo, años después.

Utilizar nombres descriptivos y semánticamente correctos para los componentes de tu programa no solamente hace más accesible la lectura de tu código. También te ayuda a razonar mejor sobre la solución que estás implementando. En algunos casos, hasta te podría salvar, potencialmente, de introducir vulnerabilidades de seguridad críticas.

Conforme he ganado experiencia colaborando en esta industria, he encontrado una relación, casi directa, entre el nivel de atención a la nomenclatura y semántica de los componentes de un programa y su fiabilidad.

Después de todo, me pregunto: si no te tomaste el tiempo de nombrar algo de una manera correcta y con sentido, ¿realmente habrás entendido el problema que estás intentando resolver?

Por qué hacer over-engineering

Luis Lira, escribiendo en su nuevo blog:

Over Engineering es cuando nos gusta complicarnos la vida, algo como ser masoquistas, pero programando. Cuando estamos creando un proyecto y queremos sufrir por voluntad propia porque para un problema sencillo usamos una solución compleja. De hecho, este sitio es una muestra de eso.

En mi pueblo hay un dicho: salió más caro el caldo que las albóndigas.

Continúa:

Este Portafolio/Blog que hice aproximadamente en 10 días — aunque aún le falten cosas — pude haberlo hecho en unas horas y solo con unos cuantos clics, comandos en una consola o simplemente pagando una suscripción en algún sitio que me diera todo esto listo.

En vez de irse por la solución “integrada”, Luis decidió experimentar ensamblando su blog manualmente.

Se dice que algo está over-engineered (o diseñado de más) cuando la solución tiene cuesta más (tiempo, recursos, esfuerzo) que el problema mismo. Pero existe una distinción importante que me gustaría recalcar: construir algo desde cero cuando existe ya un paquete que resuelve el problema no es hacer over-engineering.

El término over-engineering es inherentemente negativo. Expresa que el diseño de tu solución está over, o de más. Es inútil, extra. Te lo pudiste haber ahorrado.

Lo que está haciendo Luis es algo sumamente positivo: tomar un problema que pudo haber resuelto con unos cuantos clics, desmenuzarlo y explorar creando una solución que se adapte exactamente a lo que él quería. Eso no es over-engineering, eso es engineering. 

A través de este ejercicio, Luis no solamente está aprendiendo y explorando nuevas herramientas de desarrollo, sino que está razonando un dominio de problema al que no estaba expuesto anteriormente. Este razonamiento seguramente le ayudará a comprender mucho mejor 1) la complejidad real del problema, y 2) la toma de decisiones que juegan un papel importante en hacer que WordPress, Ghost, Tumblr, etc., sean exitosos.

Eso es verdadero aprendizaje.

La cultura de desarrollo de software actual empuja a las personas a creer que entender las premisas básicas de los problemas que resuelven es algo negativo. ¿Para qué invertir tiempo en eso, si ya hay un paquete de JavaScript que lo resuelve? Sin embargo, es refrescante ver que aún hay personas que intentan comprender el problema antes de obviar el entendimiento del mismo y correr a implementar soluciones sin fundamentos.

Cómo saber si deberías dejar ir a un miembro de tu equipo

Un Engineering Manager en una posición no tan ideal me envió la siguiente pregunta:

¿Cómo lidias con la banda que no comunica (ausentes en chat, no confirman llamadas, etc) PERO que sí da resultados?

El que uses la palabra “lidiar” me dice que, muy dentro de ti, sabes que no te está dando buenos resultados, y es momento de hacer algo al respecto.

Desde el punto de vista de un Engineering Manager, si alguien es un buen ejecutor, pero tienes que estar invirtiendo tiempo y recursos para asegurarte de que lo está haciendo de una manera que no afecte negativamente al resto del equipo, esa persona no funciona. Aunque esa persona cumpla con sus responsabilidades a nivel técnico.

Tu rol es establecer procesos y generar estrategias para que se cumplan las expectativas del equipo.

Como Engineering Manager, una de tus preocupaciones principales debería de ser evitar cuellos de botella y silos de información. Tener a un miembro del equipo que no comunica eficientemente, ni trabaja en equipo, es la antítesis lo anterior. Sobre todo si esta persona sabe que sus habilidades técnicas de alguna manera justifican sus deficiencias en comunicación y colaboración. Esta es una receta para que eventualmente tengas a alguien que sabe mucho del proyecto y del negocio, que sea una carga negativa para el equipo, y que no podrás correr porque con él se iría todo el conocimiento de los proyectos en los que trabajó. Bus factor al millón.

Un estándar de calidad es lo que se tolera, no lo que se promueve. Puedes invertir tiempo y esfuerzo en promover buenas prácticas de comunicación y trabajo en equipo, pero mientras no tomes decisiones administrativas en pro de defender los procesos y estrategias que promueves, estarás trabajando en vano.

El mejor momento para remover a ese elemento del equipo era antes de que te pusiera en esta situación.

El segundo mejor momento es ahora, que estás buscando hacer malabares por alguien que no te está haciendo, ni a ti ni a tu equipo, el trabajo más sencillo.

Google Summer of Code no estará limitado a estudiantes en 2022

Stephanie Taylor, escribiendo en el el blog de Summer of Code:

Durante los 17 años de GSoC, el ecosistema del código abierto ha crecido y evolucionado, y nos dimos cuenta de que el programa necesita evolucionar también. Con eso en mente, tenemos algunos cambio smayores para la edición de 2022, diseñados para poder servir mejor a la comunidad de las comunidades de código abierto, y dar un poco más de flexibidilidad a los proyectos y contribuidores, para que cualquier presona puede unirse y contribuir a grandes comunidades de código abierto.

Acá están los cambios resumidos:

  1. La participación ya no está limitada a estudiantes. Cualquier persona mayor de 18 años puede participar.
  2. Los proyectos ya no están limitados en cuanto a su tamaño. Ahora puedes parcipar con proyectos medianos (~175 horas) y proyectos grandes (~350 horas).
  3. Mayor flexibilidad en el tiempo que le dedicas al proyecto. Ahora puedes expandir tu GSoC hasta 22 semanas.

Tip: Si quieres un crash course de cómo trabajar con personas con diferentes perspectivas, pariticpar en proyectos de código abierto es tu solución.

Repite lo que dices, múltiples veces

Tomasz Tunguz, escribiendo en su blog:

Los grandes líderes entregan sus mensajes con palabras memorables que repiten constantemente.

Muchas personas creen que liderar significa dar órdenes. Pero no es así. Liderar significa lograr que un grupo de personas le pongan esfuerzo, atención y empeño a resolver un problema en particular. Y una de las mejores formas de hacer eso es tener un mensaje claro.

Tip para ser mejor líder: ponle nombre a tus iniciativas, y repítelas como si no conocieras otra palabra.

Como pensar en términos de sistemas, de forma segura

El mundo es tan diverso, y la historia de la humanidad tan amplia, que sería extremadamente raro que te toparas con un problema que no haya sido resuelto por alguien antes. Los Modelos Mentales te ayudan a extrapolar la experiencia de otras personas resolviendo cierta categoría de problemas, para que tú puedas tomar decisiones para problemáticas puntuales.

Algunas reglas para que tengas cuidado cuando uses modelos mentales para resolver problemas:

  1. Cuando tu modelo mental y la realidad no concuerden, la realidad siempre gana
  2. Los modelos mentales no cambian, la realidad sí
  3. Todos los modelos omiten información; algunos modelos mentales omiten información crucial

Tip: Si bien usar modelos mentales es una buena estrategia para hacer una aproximación a una respuesta acertada, no es garantía de que obtendrás respuestas correctas el 100 % de las veces.

Si quieres conocer más sobre modelos mentales, te recomiendo que veas esta entrevista que me hizo Héctor, de The Dojo, hace unos meses.

Enlace: https://lethain.com/how-to-safely-think-in-systems/

Enseñándole a un auto a estacionarse en 500 líneas de código

Un tutorial sobre cómo enseñarle a un automóvil a estacionarse de manera autónoma, usando un algoritmo genético (un tipo de algoritmo que hasta hoy no sabía que existía).

Sí, la implementación de código es interesante. Pero me gustaría orientar tu atención la forma en que el autor te lleva de la mano para explicarte el por qué y el cómo. Primero, comparte un bosquejo del plan. Luego, paso a paso, te va diciendo qué es lo que está haciendo, y por qué.

Tip: recuerda que, cuando se trata de comunicar ideas y compartir conocimiento, es importante que conozcas a tu audiencia. Este artículo claramente está pensado para personas que tienen un entendimiento básico de inteligencia artificial, y que se están buscando mejorar sus habilidades con algoritmos genéticos. Observa cómo cada parte del artículo está cuidadosamente diseñado para ser útil para ese público.

Enlace: https://trekhleb.dev/blog/2021/self-parking-car-evolution/

Gatekeeping: qué es y cómo combatirlo

Gatekeeping. Cuidar ranchos. Creer que la forma en que tú ves el mundo es la única válida que existe.

Últimamente he empujado mucho este concepto en mis redes. Para mi sorpresa, cada vez que lo toco me lleno de menciones de personas que me preguntan a qué me refiero con “gatekeeping” o “cuidar ranchos”. Estoy escribiendo este artículo con dos objetivos; 1) tener un enlace para enviar la próxima vez que me pregunten, y 2) generar un poco más de conciencia al respecto — porque creo que hace falta.

Como muchos fenómenos sociales y culturales, promovemos o padecemos el gatekeeping sin saberlo — porque nadie nos explicó que existía, y simplemente somos víctimas… o victimarios. Sucede lo mismo con el gaslighting, por ejemplo.

El gatekeeping es una de las principales razones por las que las comunidades de tecnología se pueden sentir tan hostiles y cerradas para las personas que están intentando incursionar en este mundo. Viene de la noción de que “si me costó tanto trabajo a mí, no debería ser más sencillo para ti”, acompañado de un toque de narcisismo al asumir que la otra persona quiere exactamente lo mismo que tú — o que desea obtener exactamente tus mismos resultados.

Hacer gatekeeping es estar tan envuelto en tu propia idea del mundo, tu craft o tus gustos, que ignoras los deseos, necesidades y perspectivas de las personas que te rodean. Antepones tu versión de lo que es “correcto” a tus supuestas ganas de “apoyar”, y terminas compartiendo respuestas condescendientes, que lo único que hacen es hacer sentir mal a la persona que lo único que quería era tu ayuda.

Sufrir del gatekeeping, en contraste, no te hace sentir superior ni valida tus ideales. Al contrario, te hace sentir mal, te hace dudar de tus habilidades y tu potencial. Te hace creer que no vas por el camino adecuado, y refuerza en ti la idea de que hay una única forma “correcta” de hacer las cosas, lo que es completamente erróneo. Sufrir del “cuidarranchismo” también es desalentador y te puede llevar a resentir la ayuda de aquellos que genuinamente quieran ayudarte.

Qué hacer para combatir el gatekeeping

Si te das cuenta de que cuidas ranchos: felicidades, acabas de completar el paso más difícil. Ahora es momento de hacer cambios en cómo te conduces. Primero, cuando alguien te pida ayuda (o quieras dar un consejo espontáneo), hazte las siguientes preguntas:

  • ¿Reconozco que la otra persona tiene un objetivo muy particular que no necesariamente tiene que ver conmigo y mi historia?
  • ¿Comprendo las necesidades, capacidades y situación de la otra persona?
  • ¿Tengo la claridad mental necesaria para compartir mi aporte sin intentar validar mi preconcepción personal de lo que es correcto o válido?

Segundo, recuerda que si hay algún ambiente en el que haya respuestas absolutas y 100% correctas, no es en el mundo de la tecnología. Lo que hoy es aceptado, mañana puede ser considerado una mala práctica. Como publiqué en Twitter, una de las características más importantes para trabajar en esta industria es tener la mente abierta.

Tercero, haz las paces con tu yo del pasado que hacía gatekeeping y se sentía orgulloso por ello. Está bien, parte del proceso de crecer personal y profesionalmente es darte cuenta de lo que está mal y no aporta, y hacer algo al respecto. Y en eso estás, así que date la oportunidad de reconciliarlo y sigue adelante.

Si eres víctima de un cuidarranchos, debes de saber que no es tu culpa. Esta industria está llena de personas con hábitos reduccionistas y absolutistas, y no eres la única persona que está pasando por esto. Puede sonar como justificación para su comportamiento, pero no lo es. Porque así como hay muchísimas personas en tecnología que basan su identidad en estar bien y promover estas prácticas, hay otras tantas que estamos jugando juegos infinitos, con ganas de ver a nuestros colegas crecer. Me atrevería a decir que somos más los que genuinamente queremos darte las herramientas para que salgas a hacer lo que tienes que hacer.

Primero, te invito a asimilar este concepto y agregarlo a tu vocabulario. También, comienza a identificar los indicadores de que estás lidiando con un cuidarranchos, y de que deberías de enfocar tus energías en buscar otro lugar para pedir ayuda:

  • Te quieren vender una única idea de cómo hacer las cosas
  • Te chantajean mencionándote cómo podrías fallar si no usas lo que ellos te recomiendan
  • Hacen menos las contribuciones de otras personas en la industria a diestra y siniestra
  • Cuando más “aportan” es cuando se sienten su identidad amenazada (p. ej., salen a respingar cuando dices que deberías agregar documentación a tu código, y no únicamente escribir código que se documente solo.)

Segundo, ayuda a que más personas se hagan conscientes de esto. Mientras haya más personas con la conciencia de lo que hacer gatekeeping representa, será mucho más sencillo sacar a flote estas discusiones. Esto es importante porque creo que nos merecemos tener espacios seguros donde podamos sentirnos respaldados por una comunidad que nos quiera ver crecer.

Si detectas que alguien está haciendo gatekeeping, hazlo notar. Haz ruido, levanta la voz, hazles ver lo que está sucediendo. Si estás en una posición de liderazgo en la que puedas tomar acciones concretas al respecto, hacerlo es tu responsabilidad. Da feedback, modera, lidera. Y si ni explicando razones se remedia la situación, ahí no es.

Saber lo que es el gatekeeping no es una licencia para que agregues un buzzword tech a tu vocabulario y sigas como si nada. Lo que diferencia a los humanos del resto de los animales es nuestra habilidad de ponerle nombre a las cosas. Hemos desarrollado un lenguaje que nos permite comunicarnos, establecer reglas y llegar a acuerdos. La principal motivación de ponerle nombre a las cosas es poder explicarlas, estudiarlas y mejorarlas. Así que ahora que sabes lo que es, que existe y por qué es importante compartirlo, también tienes la responsabilidad de hacer algo al respecto.

En resumen

  • ¿Quieres de verdad llegar a ser un 10X Developer? Deja de cuidar ranchos.
  • ¿Quieres hacer algo por tu comunidad? Ayuda a un cuidarranchos a dejar esos modos.

Cómo vencer el síndrome del impostor

Todos sufrimos del síndrome del impostor.

Tan solo basta con hacer una búsqueda en Twitter para darte cuenta de que no estás sola. A unos nos vuelve paranoicos. A otros nos paraliza completamente, mientras que a varios simplemente nos atormenta en cada decisión que tomamos en nuestra vida profesional.

Cuando hablamos del síndrome del impostor también estamos hablando, hasta cierto punto, de vergüenza. Seguramente a ti también en tu niñez te dijeron que estar mal es algo que deberías de evitar a toda costa. Probablemente en varias ocasiones te dijeron, como a mí, que si no tenías algo bueno que aportar, mejor no aportaras nada.

Vivir el día a día con síndrome del impostor es agobiador. Sobre todo si trabajas en equipo. Y aún más, si trabajas en un ambiente ultra competitivo como lo es el desarrollo de software. El miedo de exponer una idea y quedar mal, como el que no sabe. El síndrome del impostor hace que nada de lo que tienes que aportar pueda salir a la luz. Pero todo esto se puede prevenir.

Considera lo siguiente: así como no mandarías código a producción sin probarlo o validarlo, tampoco deberías de convertir ideas en código sin antes pulirlas con tu equipo.

La próxima vez que sientas miedo de quedar “mal parada” por compartir tu idea de solución con el resto del equipo, recuerda: eso también es hacer software. Estás probando la viabilidad de la idea. Si escribir tests te ayuda a confiar más en tu implementación, exponer tus ideas con tu equipo y recibir feedback de ellas te ayuda a confiar más en que vas por el camino correcto.

Vencer el síndrome del impostor es tarea de todos

Si bien cada quien lo experimenta de manera diferente, todos en algún momento de nuestra vida nos hemos identificado (o nos vamos a identificar) con este síndrome. Creo que es una de las pocas cosas en las que todos podemos estar de acuerdo: el síndrome del impostor es algo que tenemos que tratar.

Y considero que es responsabilidad de todos los que estamos en esta industria buscar maneras de erradicarlo.

Recientemente, me compartieron una técnica que ha hecho maravillas para mí y mis equipos. Nos ha ayudado a bajar la barrera de entrada a discusiones, y al mismo tiempo, ha ayudado a que las soluciones a las que llegamos como equipo sean más diversas y ricas en perspectivas. La técnica se llama Wrong Answers Only, o “respuestas incorrectas únicamente”, pero me gusta más el nombre en Inglés.

Wrong Answers Only se trata de poner como regla, en cualquier discusión de equipo, que únicamente se vale compartir respuestas incorrectas.

La barrera de entrada ahora es mucho más baja, porque ahora lo que no quieres es estar en lo correcto. Dale rienda suelta a tu imaginación, y di lo primero que se te venga a la mente. Conforme va avanzando la reunión, la abundancia de ideas que no están atadas a la expectativa de tener que estar bien comienza a ofrecer un panorama mucho más amplio y diverso de soluciones posibles.

Poco a poco, utilizando esta técnica, los miembros del equipo ganamos confianza en nosotros mismos y aprendemos que estar mal es parte del proceso de aprendizaje. Y mientras más nos demos cuenta de lo anterior, más se rompe la asociación de que estar en lo incorrecto es un juicio directo sobre nuestra valía y capacidades como profesionales.

Las 4 fases del conocimiento: aprende a identificar en cuál estás

La semana pasada participé en un taller donde aprendimos el valor de escuchar sin intentar resolverle los problemas a otras personas. En la explicación que dio el facilitador, compartió un concepto que me voló la cabeza: las fases del conocimiento.

Durante el taller, usó esta idea para recalcar la importancia de mantenerse receptivo ante los sentimientos de los otros.

No lo había escuchado nunca, pero se me hizo una forma extremadamente práctica de entender cómo es que el conocimiento se vuelve parte de nuestra vida. Y hoy te quiero compartir ese concepto para que lo utilices cada que quieras aprender algo nuevo.

El conocimiento puede existir en 4 fases dentro de nosotros: Punto Ciego, Aprendizaje, Aplicación y Encarnación.

Las fases del conocimiento: Punto Ciego, Aprendizaje, Aplicación y Encarnación

Cada una de estas 4 fases se vive de manera consciente o inconsciente.

  1. Punto Ciego: Inconsciente. No sabes lo que no sabes. Asumes y supones, pero no te cuestionas por qué de las cosas. Simplemente, aceptas la realidad tal cual. Caes en dogmas y vas por la vida sin preocuparte por los efectos de tus acciones en el mundo que te rodea.
  2. Aprendizaje: Consciente. Por alguna razón, te diste cuenta de tu punto ciego y estás buscando, de manera consciente, expandir tu conocimiento. Estás estudiando, investigando, encontrando maneras de desbloquearte. Haces preguntas, investigas y te vuelves más receptivo a nuevas ideas.
  3. Aplicación: Consciente. Estás cristalizando tus aprendizajes de la fase pasada. Tomas lo que estudiaste, lo que aprendiste, y lo aplicas para terminar de asimilar el conocimiento. La aplicación de lo que has aprendido, a su vez, genera más preguntas. En esta fase es donde descubres tu propia versión de la verdad.
  4. Encarnación: Inconsciente. Lograste dominar tu craft y ahora puedes ejecutarla sin pensar — logras aplicar tu conocimiento de manera inconsciente. En esta fase es donde el conocimiento se vuelve sabiduría. Vuelves a no saber por qué sabes lo que sabes.

Si tienes la suficiente astucia, te darás cuenta de que este no es un proceso lineal, sino cíclico. Cuando logras encarnar el conocimiento, en tu mente se libera espacio para poder ponerle atención a otros aspectos de tu vida. Es ahí donde descubrirás más puntos ciegos, y podrás comenzar el camino de nuevo.

Esta forma de pensar también encaja perfectamente con el efecto Dunning-Kruger (el inverso del síndrome del impostor): “mientras menos sabes, más crees que sabes.” Te hice una gráfica.

La próxima vez que rechaces una idea, pregúntate:

  • ¿Es este mi punto ciego?
  • ¿Hay algo más que pueda aprender de este tema?
  • ¿Podré aplicar lo que aprenda de esto?

Cosas que no te enseñaron en la escuela, pero debes saber para trabajar en la industria del software

A continuación te comparto cosas que no te enseñaron en la escuela, pero que debes de saber si quieres trabajar en la industria del software.

  1. Tú te pones tus propias metas. En la escuela tenías la comodidad de llevar un “plan de estudios”. Sabías lo que seguía en cada paso. Acá afuera nadie va a entregarte un plan de estudios para tu carrera profesional. Tienes que definirlo por ti misma.
  2. No tienes que pedir permisos. ¿Quieres aplicar para un trabajo? ¿Te urge cambiar de tecnología? ¿Te gustaría ganar en dólares y vivir en LATAM? ¿Tu sueño es trabajar para un unicornio? ¿Lo que quieres es pasar más tiempo con tu familia? Date. Nadie te detiene.
  3. Debes de tomar decisiones por tu cuenta. En la escuela te condicionaban a aprender una metodología preestablecida. Salirte del protocolo era castigado. En la vida real tienes que aprender a tomar decisiones y a hacerte responsables de sus consecuencias. Nada más.
  4. Puedes irte en cualquier momento. Tenía un profe que se quejaba de los alumnos diciendo “es que ustedes creen que las cosas van a ser como ustedes quieran”. ¿Y por qué no? Si estás en un trabajo o situación que no te favorece, ¿para qué te quedas? No te pongas la camiseta.
  5. Se espera que sepas colaborar, no que te sepas todos los lenguajes de programación del mundo. Saber más lenguajes de programación solo significa que sabes más lenguajes de programación. Aprende a resolver problemas colaborando — técnicos, de negocio, de usuario.
  6. Saber hacer la pregunta correcta es más importante que ser una enciclopedia de conocimiento. Expandiendo en el punto anterior un poco. “No es la respuesta de StackOverflow, es que sepas lo que tienes que Googlear para encontrarla.”
  7. Programar es un medio para resolver problemas, no un fin. Sí, yo sé que es bien divertido programar. Te aconsejaría que no te clavaras únicamente en eso. Puedes programar toda la vida y no resolver ningún tipo de problema. Y te van a pagar por resolver problemas.
  8. Una solución que es correcta el día de hoy, mañana puede ser considerada ineficiente. Yo creo que en software no hay soluciones “exactas”, sino soluciones “ideales para la situación actual, con el conocimiento que tenemos”.
  9. Existen lenguajes más aptos para resolver ciertos tipos de problemas. Hay desde “lenguaje especializado” que es complicado de aprender, pero te dará soluciones compactas, a “lenguaje genérico” que es fácil de aprender, pero será lejos del ideal para resolver todo.
  10. Mientras más “escalas” de posición, se trata menos del código y más de las personas. Las habilidades más valiosas de alguien considerado “Sr.” son las sociales y de liderazgo. Gente que programe “bien” hay un montón.
  11. Necesitas una red de apoyo. Sí o sí. Rodéate de gente que te quiera ver crecer y que comparta tus principios y valores.
  12. Aprende a valorar tu trabajo. Costo ≠ Valor.  No cobres por el esfuerzo físico que lleva hacer una tarea. Cobra por el valor del problema que estás resolviendo.

Originalmente compartí este hilo en Twitter, donde también puedes seguirme.

Liderazgo efectivo: La importancia de las reuniones 1on1 en equipos de desarrollo

Profesionalmente, crecí en un ambiente que desde muy al inicio me enseñó la importancia de ver primero a la persona y luego su utilidad. Y aún recuerdo el primer 1on1 (one-on-one, o una plática uno a uno) que tuve con mi líder.

Hoy sé lo afortunado que fui.

Aún no tenía tanta experiencia en la industria. Y, como muchos, pensaba que el rol del líder era regañarme, presionarme o criticar mi trabajo (luego entendí que lo que yo pensaba era un líder, en realidad era un jefe). La sorpresa que me llevé cuando en mi primer 1on1 con él, durante una hora, en vez de reclamarme por lo que es lo que estaba haciendo “mal” (a mi parecer), me preguntó que cómo me podía ayudar para que lo que estaba haciendo bien fuera más sencillo.

En ese momento fue cuando entendí el trabajo de un líder: crear conexiones con las personas con las que trabaja, entender qué los motiva y buscar la manera en que sus labores diarias sucedan en la periferia de sus intereses personales.

En una industria que está tan acostumbrada a enfocarse en el aspecto utilitario de las cosas, una conexión humana puede sentirse como un vaso de agua fría en el desierto.

A lo largo de mi carrera en software he conocido personas que, a pesar de llevar años trabajando con su equipo, nunca han intercambiado una palabra más allá de un reporte de progreso. Líderes que no saben que su equipo está quemándose porque no están haciendo aquello que los motivó a aplicar a su empresa en primer lugar. Contribuidores individuales que únicamente tienen visibilidad de lo que tienen que hacer de aquí al viernes.

No es sorpresa que tantas personas estén descontentas con lo que hacen 8 horas al día.

Líder: ¿cuándo fue la última vez que saliste de una llamada con tus reportes y saliste con un mejor entendimiento de qué puedes hacer para ayudarles a tener más éxito?

Ten 1on1s regulares. Hablen de qué los motiva. Hablen de qué les causa estrés. Haz un esfuerzo por ir más allá del dashboard de Jira, y si algo no está funcionando, entiende por qué. Luego busca la manera de arreglarlo. Sé ese líder que van a recordar porque no solo pedía resultados, sino que ayudaba al equipo a conseguirlos.

El 1on1 es una oportunidad para ambas partes. No la desaproveches.

Por qué te cuesta aceptar nuevas ideas: el efecto Semmelweis

En algún momento de la historia, los médicos no se lavaban las manos antes y después de atender pacientes. Como podrás imaginarte, esto daba como resultado muchísimos contagios y muertes innecesarias.

En 2021 eso sería considerado negligencia médica. En el siglo 19 era simplemente como se hacían las cosas.

Ignaz Semmelweis descubrió, por ahí de 1847, que la tasa de mortalidad se reduciría 10 veces si los médicos se lavaran las manos después de atender un paciente, y antes de atender a otro. Sugirió que los cirujanos usaran una solución clórica para limpiarse.

Él comenzó a realizar esta práctica, y sus pacientes dejaron de enfermar. Aunque aún no había “una ciencia” que avalara su propuesta (la teoría bacteriana de la enfermedad no se descubriría por otros 20 años), sí había suficiente evidencia empírica para soportar su teoría: lavarse las manos entre pacientes salvaba vidas.

A pesar de esto, miembros del gremio médico decidieron ignorarlo. No solo eso, sino que lo rechazaron y buscaron desacreditarlo públicamente. En ocasiones, las justificaciones de su rechazo eran por ideas que ni siquiera tenían que ver con la medicina.˙ Por ejemplo, algunos genuinamente creían que “las manos de un caballero no podrían transmitir enfermedades”.

A este fenómeno social se le conoce hoy en día como el efecto Semmelweis. Es la reacción involuntaria de rechazar nuevas ideas, datos o evidencia que no concuerde con nuestro sistema de creencias — por más evidencias o pruebas que existan.

Todos en alguna ocasión hemos rechazado una idea al instante, solamente para darnos cuenta, para infortunio de nuestro ego, de que era completamente válida. Ganar conciencia del efecto Semmelweis es importante — especialmente para nosotras, las personas con Cerebro de Programador™, que pensamos que todo en esta vida se trata de lógica y relaciones lineales. Creemos que nuestra vida se basa en evidencia y hechos, cuando la realidad es que muchas de las decisiones que tomamos en el día a día vienen desde nuestro sistema de creencias.

La próxima vez que sientas el impulso de rechazar una idea, pregúntate: ¿la estás rechazando porque no hay suficiente evidencia? ¿O porque esa idea no cabe dentro de tu sistema de creencias?

Haz código que no necesite documentación. Y documéntalo.

Los programadores tenemos tendencias egocéntricas.

Entendemos (o creemos entender) cómo funcionan las computadoras. Y eso nos hace sentir especiales. Y si somos tan especiales para entender cómo funcionan las computadoras, cualquier persona que no entienda mi código no es tan especial como yo.

Documentar qué estás haciendo, y por qué, puede ser un golpe al ego. Pero uno que vale la pena. Que documentes algo 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 seas tú.

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

Escribir documentación no tiene que ser aburrido ni estar limitado a únicamente escribir comentarios.

En orden de accesibilidad, puedes escribir:

  1. comentarios en tu código.
  2. READMEs
  3. glosarios
  4. RFCs o documentos de diseño
  5. pruebas
  6. Documentos de arquitectura

Te invito a que veas la documentación como un tema de accesibilidad, y no de exactitud. ¿Qué opinarías de alguien que dice que no debería haber rampas en las banquetas de una ciudad porque no necesita caminar para transportarse? Reflexiona.

¿Qué hace competente a un programador?

Saber más lenguajes de programación, arquitecturas o tecnologías no te hace un programador competente.

Más allá de sus contribuciones con compiladores, sistemas distribuidos y sistemas operativos, Dijkstra nos dejó el aprendizaje más grande de todos en su clase de 1972, The Humble Programmer: la característica más importante de un programador realmente competente es su humildad.

Si eres un programador competente entonces eres consciente de que no lo sabe todo. Así que te aproximas a cualquier tarea que se te asigna con humildad, y no caes en las trampas de tu ego — no te complicas por la simple motivación de hacer notar que sabes más o eres mejor.

Estar en lo correcto se siente bien. Y creo que hay un lugar y un espacio para hacerlo — a final de cuentas reconocer nuestros éxitos es también parte importante del crecimiento. Pero hacerlo en exceso es una receta para el delirio.

Hay una línea muy delgada que todos los profesionales de esta industria debemos de trazar. Esta línea te ayuda a identificar si estás intentando resolver un problema para agregar valor real o para satisfacer tu propio ego.

Si no eres consciente de la razón por la cual estás resolviendo algo, es muy fácil que caigas en la trampa del ego.

También, si no tienes la humildad para reconocer cuando estás resolviendo algo por ego y no por avanzar tus objetivos, te conviertes en un bloqueo para tu equipo.

Lo que te hará mejor desarrollador no es saber más lenguajes de programación, frameworks o arquitecturas. Es tener la humildad de aceptar que no lo sabes todo, e intentar resolver tus problemas partiendo de esa premisa.

Contrario a la idea con la que probablemente creciste, aceptar que estabas mal o que no sabes algo no significa que eres incompetente. Significa que tienes la humildad de reconocer tus errores y la integridad de aprender de ellos. Mientras más pronto lo admitas y te hagas consciente de ello, más rápido te moverás hacia la respuesta correcta.

Ser líder: ¿quieres el puesto o la responsabilidad?

El puesto de liderazgo está sobrevalorado.

Muchas personas asociamos ser “únicamente” seguidores, o miembros de un equipo, con sentimientos negativos. Como si no tener el reconocimiento del puesto nos hiciera menos personas. Y como si el hecho de no tener un nombramiento oficial significara que no podemos ejercer el rol de liderazgo que sentimos merecemos.

En realidad, dentro de una organización, todas las personas están siguiendo los pasos de otras. Nadie es un líder sin ser liderado.

Hay líderes, y hay seguidores. Y así como hay buenos y malos líderes, hay buenos y malos seguidores.

Un buen líder da dirección y provee al equipo de herramientas y frameworks para cumplir objetivos a largo plazo. Un mal líder reparte tareas y espera que las metas se cumplan porque sí.

Un buen seguidor puede tomar la dirección de un buen líder, estar en desacuerdo, y buscar maneras de hacer saber que la premisa de la tarea es incorrecta. Un mal seguidor tomará la tarea, y aún sabiendo que la dirección no es la correcta, la implementará. Después culpará al líder.

Un buen seguidor a su vez es un buen líder. Pues ser un líder no significa que sabes más o que tienes el control — o que tienes un nombramiento, necesariamente. Sino que tienes una responsabilidad con tu equipo. Cómo materializas esa responsabilidad es lo que te definirá como un profesional.

Un buen líder a su vez es un buen seguidor. Pues sabe que la retroalimentación de las personas a las que está liderando no siempre será fácil de digerir, pero que el resultado neto será siempre positivo.

¿Quieres el puesto, o la responsabilidad? Porque la responsabilidad está lista para que la tomes. Todo lo demás es tu ego hablando.