Oscar Swanros

  • Inteligencia emocional para desarrolladores

    Gran parte del tiempo de mi día se lo dedico a ayudar a desbloquear a otras personas. Te sorprendería cuántos problemas tienen un origen emocional.

    Una de las habilidades que he desarrollado y más me ha servido es la de encontrar formas de comunicar conceptos complejos de maneras que hagan sentido para la otra persona. Cada una de las personas con las que hablo es diferente, y a cada quién le “caen mejor” ciertas ideas de una forma que de otra. Lo que he encontrado, independientemente de la situación, es que una analogía bien aplicada hace que se pueda asimilar mucho mejor un concepto.

    Así que justamente esto te vengo a ofrecer el día de hoy: una analogía para ayudarte a entender, de una vez por todas, lo que es la salud emocional, y por qué es importante que inviertas esfuerzo en ella.

    Las emociones son como un océano. Los sentimientos son las corrientes que recorren ese océano.

    Así como el océano, tu repertorio de emociones está siempre en flujo, cambiante y en constante movimiento. El equivalente a tener un problema en tu vida es un huracán o una depresión tropical de esas que nadie ve, pero tiene efectos reales en las costas.

    Podríamos decir que cada una de las emociones que puedes tener en tu vida representa una masa de agua. Las corrientes marítimas son ocasionadas, entre otras cosas, por cambios en la densidad entre masas de agua (causadas por diferencias en la salinidad o temperatura). Una corriente oceánica es un sentimiento en esta analogía. Al igual que las corrientes, los sentimientos pueden variar de intensidad, profundidad y duración.

    Hay algunos sentimientos que duran toda la vida. Hay otros que desaparecen a los pocos minutos de haberse creado. Unos son lo suficientemente fuertes para arrastrar flotillas de barcos completas, mientras que otros simplemente te sacan un susto en la playa.

    Las corrientes no pueden existir sin el océano, y el océano no podría albergar vida sin las corrientes. Y nuestros sentimientos tienen un origen, así como nuestras emociones necesitan ser expresadas. Y tal como los océanos y las corrientes, los sentimientos y las emociones son simplemente un hecho de nuestra existencia. No podemos ignorarlos, y tenemos que cuidarlos o sufrir las consecuencias.

    Las emociones, al igual que los océanos, pueden navegarse, estudiarse, nutrirse, ensuciarse, limpiarse y moverse. Y si de navegar de una masa de agua a otra se trata, tal como los grandes navíos que atraviesan el mundo de polo a polo, podemos usar los sentimientos para impulsarnos de una emoción a otra.

    Finalmente, así como sería arriesgado intentar navegar un océano sin un mapa (satelital o celestial), lo mismo sucede con las emociones. Si intentamos vivir nuestra vida sin conocerlas, entenderlas, estudiarlas y nutrirlas, nos encontraremos en situaciones complicadas, difíciles de navegar y probablemente fatales. Ir a terapia es un buen precursor para comenzar a desarrollar estos mapas emocionales.

    La inteligencia emocional no se trata de domar o reprimir las emociones, más de lo que ser un buen navegante se trata de calmar el mar cuando se pone duro.

    Ser inteligente emocionalmente se trata de identificar cuando es mejor momento de navegar ciertas emociones, y reconocer lo que necesitarás para que no te hundan. Así como un capitán experto sabrá cuándo usar las corrientes para navegar el océano de manera más sencilla, tú aprenderás a usar tus sentimientos a tu favor, llevándote de una emoción a otra.

    Si eres una de esas personas que necesitan ejemplos y lógica para entender conceptos foráneos, espero que esta analogía te ayude a comprender la importancia de invertir en tu salud emocional. Es importante.

    Ve a terapia.

    Si quieres aportar algo, podemos continuar la discusión en Twitter.

  • 3 consejos para que mejores tu Inglés

    ¡Escucha Inglés para Devs! Un podcast donde Darwin Pinto me explica cómo pronunciar un término de la industria del software, y yo le explico lo que significa. Miles de personas lo escuchan en Spotify.

    Trabajar en la industria del software es un acto de balance entre mejorar tus habilidades técnicas y tus soft skills.

    Como probablemente sabes, el lenguaje por defecto en tecnología es el Inglés. Así que es de vital importancia que, cuanto antes, aprendas a comunicarte en ese lenguaje. No estoy diciendo que si no hablas Inglés no podrás trabajar en esto. Pero sí estoy diciendo que si sabes comunicarte en el lenguaje universal de la tecnología, desarrollarte profesionalmente será una tarea mucho más sencilla.

    Como publiqué hace un tiempo, hablar Inglés ya no es una ventaja competitiva. Es igual (o más importante, algunos argumentan) que saber programar bien.

    Si no sabes por donde comenzar, aquí te dejo algunos tips que comparto cada vez que alguien me pregunta sobre este tema. Estos tips me ayudaron personalmente, y he visto cómo también han ayudado a muchas personas a sobrepasar la barrera del Inglés.

    [convertkit form=2572581]

    Lo que importa es que la idea llegue lo menos golpeada posible

    Primero aclaremos algo: no es necesario que hables Inglés perfecto. Con que logres comunicar la idea de manera eficiente es suficiente. Si encima de ello logras dominar las inflexiones, expandir tu léxico y neutralizar tu acento, estarás en el 1% de la población que no habla Inglés como su primera lengua.

    El lenguaje, la comunicación, es una cualidad imperfecta. Al contrario de un lenguaje de programación, que puedes aprender leyendo un manual, el Inglés (o cualquier otro lenguaje) no tiene un proceso de evolución determinado por una organización. Cada quién habla su propia versión del Inglés, y lo único que te toca es intentar apegarte lo más posible a las reglas gramaticales y fonéticas. Todo lo demás es un producto secundario del que lo está hablando, cómo lo aprendió y lo que quiere comunicar.

    Pregúntale a cualquier persona que haya trabajado para un cliente que hable Inglés, o que trabaje en una empresa estadounidense. El día a día de trabajar con personas hablando Inglés es una batalla constante por descifrar qué es lo que están diciendo.

    Sucede lo mismo con el Español, por cierto. Como lo aprendiste desde muy pequeña, sientes que lo dominas y ahora te tomas ciertas libertades para comunicar ideas. Porque lo que importa no es que lo hables perfecto, sino que la otra persona entienda lo que le quieres decir. Estos “atajos“ están determinados por el contexto dentro del cual te desarrollas. Así, mandar código a producción se dice “deployear“, cerrar un Pull Request se dice “mergear“ y eliminar los problemas de tu programa se vuelve “debuggear“. ¿Crees que alguien que no domina el Español va a entender de qué estás hablando?

    Así que no seas tan dura contigo misma. Y si estás pensando que las personas que trabajan en E.E.U.U. hablan un Inglés perfecto, no podrás estar más lejos de la realidad.

    Groovy!

    Exponte a situaciones reales

    Nadie nunca va a hablar como los audios que te ponía tu maestra en el curso de listening. Quítate esa idea de la cabeza.

    El día al día de trabajo usando Inglés se trata, como ya te dije, de descifrar qué es lo que realmente está sucediendo. Y mientras esos audios son una herramienta bastante buena para aprender la manera correcta de pronunciar una palabra, la verdad es que en el día a día no importa tanto como crees. La cosa es que difícilmente vas a lograr desarrollar la habilidad de entender cómo realmente se comunica una persona normal en Inglés si no te expones a situaciones que lo propicien.

    La ventaja de estar vivo en 2021 es que ya no necesitas viajar a Estados Unidos para mejorar tu Inglés. Hoy en día es tan fácil como suscribirte a un podcast y escuchar hablar a dos amigos de la infancia, uno de Boston y otro de Ohio, e intentar descifrar qué es lo que están diciendo. ¿Cómo habrías podido vivir esa experiencia hace 20 años? Viviendo un año en Boston, otro en Ohio, y luego inventándote la conversación en tu cabeza.

    Algunas personas recomiendan películas o audiolibros. Y aunque ciertamente no puede perjudicarte escucharlos, me gustaría que quedara claro que no son situaciones reales. Los medios que están producidos para las masas están, justamente, producidos. Son artificiales.

    Pero un podcast entre dos amigos rara vez va a estar cuidado para que todo mundo le entienda. Y ahí es justo donde sucede la magia.

    Identifica un tema que te llame la atención, busca un podcast en Inglés que hable de ello, and go to town.

    Práctica, práctica, práctica…

    Y para terminar, el consejo principal de este artículo: práctica.

    Práctica, práctica, práctica.

    Cualquier músculo por no ejercitarse se atrofia. Y el Inglés no es una excepción. Ojalá fuera así de fácil, y que pudieras estudiar algo una vez sin olvidarlo jamás.

    Este consejo ata los otros tips en uno solo. Atrévete a escribir y hablarlo sin preocuparte de si está perfecto o no, y hazlo en situaciones lo más parecidas a la realidad posible.

    • Escribe en foros, participa en conversaciones de comunidades adeptas a tu área.
    • Escribe blog posts o documentación en Inglés.
    • Únete a un grupo de Discord de tu videojuego favorito y comenta.
    • Comparte tus opiniones en proyectos de código abierto.
    • Haz entrevistas de práctica.
    • Acuerda con alguna amistad que los jueves únicamente se van a hablar en Inglés.

    El chiste es no quitar el dedo del renglón.

    Y sí, puede ser que te cueste trabajo al inicio, pero ¿qué cosa que valga la pena no cuesta trabajo? Tú puedes.

    P.D. — Escucha Inglés para Devs en Spotify.

  • Profesionalmente, crecí en un ambiente que desde muy al inicio me enseñó la importancia de ver primero a la persona, y luego al profesional. 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 hiciera más de lo que estaba haciendo bien.

    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 una jarra de agua fresca 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.

    Si tienes una posición de liderazgo: ¿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.

  • Deberías de buscar trabajar de manera remota tan pronto como puedas en tu carrera.

    Muchos piensan que para trabajar de manera remota necesitas estar en el pináculo de tu carrera. Que la progresión es Jr., Mid., Sr., trabajo remoto. Pero la realidad es que para trabajar de manera remota se necesitan más soft skills que conocimientos técnicos. Te lo dice alguien que nunca ha trabajado en una oficina en toda su vida.

    Trabajar de manera remota no solamente es atractivo porque (probablemente) te pagarán en una moneda extranjera. Aunque sea bastante relevante para tu calidad de vida, hay algo mucho más profundo a lo que me gustaría que le prestaras atención: trabajar de manera remota es un ejercicio de paciencia, tolerancia y humildad. Tendrás la oportunidad de trabajar con personas de todo el mundo, con pasados completamente diferentes al tuyo, motivaciones diametralmente opuestas y habilidades que ni siquiera podrías haber imaginado que se podrían obtener.

    Al trabajar de manera remota te expondrás a otras maneras de resolver problemas. Ideologías de trabajo que tal vez no hagan sentido para ti; principios y valores que harán cuestionarte si estás haciendo lo suficiente.

    Es por eso que es tan importante que tengas esta experiencia tan pronto como puedas en tu carrera. Porque así no tendrás un marco de referencia de “la forma correcta” de hacer las cosas. Estarás menos viciado, y será mucho más fácil adaptarte al cambio sin juzgar el proceso. Desarrollarás habilidades que te ayudarán a ser mucho más eficiente, productivo y tolerante. Y más que una tecnología o lenguaje de programación, la base de tu carrera será tu tolerancia, eficiencia, adaptabilidad y compasión.

    Como dice Seth Godin, la tolerancia crea resiliencia en los humanos. Tolerancia a diferentes habilidades y preferencias nos ayuda a trabajar con diversidad de pensamiento, técnica y experiencia. La combinación de estos factores produce mejores resultados al final del día.

    Así que no, no te esperes a ser el mejor en cierta tecnología para buscar un trabajo remoto. Exponte al reto.

    Gana perspectiva antes de que encuentres una “forma correcta de hacer las cosas” que funcione únicamente en tu burbuja.

  • Aunque a unos les cuesta más que a otros admitirlo, la pandemia nos ha afectado a todos.

    Me atrevería a decir que todos los que llevamos rato trabajando con software, tal vez de manera remota, hicimos menos los efectos que la emergencia sanitaria podría traer a nuestras vidas. “De todos modos ya no salía ni socializaba”. Seguro escuchaste a más de uno burlarse con esa frase.

    Sin embargo, no tardamos en darnos cuenta, después de unos meses de estar encerrados, que no estábamos preparados. Y que por más experiencia que tuviéramos trabajando remoto, no contábamos con lo difícil que sería mantener una relación sana con el trabajo en medio de una crisis mundial.

    Un estudio reciente de Haystack Analytics encontró que un 83% de desarrolladores de software están sufriendo de burnout (o como se dice comúnmente, “están quemados”) por los efectos de la pandemia. Aunque el estudio se hizo en un número bastante limitado de personas (258 personas mayores de 18 años, viviendo en Reino Unido), creo que lo que encontraron refleja la realidad que he visto platicando con otras personas en la industria: la estrategia de quedarnos encerrados a trabajar no está funcionando ni es sostenible.

    En muchos lugares del mundo las cosas parecen estar volviendo a la normalidad. Con esto, muchas personas, después de más de año y medio trabajando remoto, están considerando seriamente cambiar de trabajo a uno que les permita seguir trabajando desde su casa. Si tú te identificas con esta realidad, entonces es importante que tomes en cuenta lo siguiente, si es que no lo habías asimilado aún:

    • Trabajar de manera remota no significa estar disponible 24/7.
    • Tampoco es un pretexto para ser desorganizado.
    • Necesitas desarrollar tus habilidades de comunicación, y sentido de agencia.

    El trabajo remoto es un arma de doble filo. Desafortunadamente a muchas personas les tocó experimentarla en condiciones no ideales. Pero aún estás a tiempo de hacer cambios — si es que te interesa mantener tu salud y bienestar a largo plazo.

  • Para las personas que pensamos de manera lógica es tan divertido programar, que tendemos a enfocarnos únicamente en ello.

    El prospecto de aprender una nueva tecnología o herramienta es suficiente para que la adrenalina nos mantenga despiertos hasta altas horas de la madrugada. Pero cuidado: no caigas en el shiny new toy syndrome.

    Es válido aprender por mera curiosidad. Después de todo, así es como muchos descubren sus verdaderas pasiones. Sin embargo, hay una delgada línea entre explorar ideas con el objetivo de ganar nuevas perspectivas y ser complacientes.

    Yo dibujaría esa línea en el punto en que el tiempo que pasas aprendiendo cierta tecnología se convierte en potencial y esfuerzo desperdiciado. Por ejemplo, yo sabía desde un inicio que quería trabajar haciendo iOS de bajo nivel. ¿Me habría servido ponerme a estudiar Kubernetes?

    Probablemente sí, para conocer la herramienta y entender las implicaciones. Pero no tanto como para haber buscado una certificación, o invertir tiempo y dinero en un curso para dominarlo.

    Para alguien con Cerebro de Programador™ puede resultar bastante complicado ver un poco más allá de la parte práctica y técnica — programar. La idea de definir qué es lo que quieres hacer probablemente te parezca completamente ajena. Y con razón — la industria te ha hecho creer que tu tarea es resolver tickets. No es hasta que te topas con la necesidad de poner los pies en la tierra y decidir qué es lo que realmente quieres hacer, que se comienza a poner interesante.

    Aunque no es sencillo, definir para qué quieres aprender tal o cual tecnología es un proceso asequible. Lo único que necesitas es un poco de dedicación, y autocompasión.

    La manera más sencilla que te puedo compartir para resolver este problema es que diseñes tu progresión de carrera — y lo hagas lo antes posible.

    Para comenzar, plantéate las siguientes preguntas:

    • ¿Qué tipo de problemas te gustaría resolver?
    • ¿En qué industria?
    • ¿Rodeado de qué tipo de personas?

    Una vez que tengas tus respuestas, tendrás una estrella norte para seguir. Ahora tu tarea es hacer ingeniería inversa, y buscar las herramientas, experiencias y contactos que necesitarás para llegar a ella.

    Haz este ejercicio cada 3 o 5 años.

  • Hay personas en esta industria que reducen su trabajo a algo meramente mecánico: escribir código.

    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.

    Hace unos días GitHub presentó Copilot — un servicio que prácticamente programa por ti. Lo único que tienes que hacer es describir a grandes rasgos qué es lo que quieres hacer. Copilot genera el código que tú habrías escrito.

    Naturalmente, los memes no se hicieron esperar. Tampoco las discusiones sobre si el código que está generando esta herramienta cumple con licencias de distribución adecuadas. Pero muy pocas personas se pusieron a ver lo que acababa de pasar: los soft skills en desarrolladores de software acaba de volverse mucho más valiosos.

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

    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.

  • Cómo hacer soporte te hace mejor ingeniero

    Si tomas tu carrera en software en serio, deberías de buscar hacer soporte de usuario regularmente.

    Como ingenieros tendemos a creer que hacer soporte no nos corresponde. Que nosotros ya cumplimos escribiendo el programa; lidiar con los clientes debería de hacerlo alguien contratado para eso. Pero hoy estoy aquí para decirte que podrías obtener muchísimos más beneficios si cambias tu actitud, y si en vez de evitar hacer soporte, lo buscas.

    Hacer soporte de usuario es parte integral del desarrollo profesional de cualquier ingeniero de software.

    A través de la exposición a comentarios, preguntas, frustraciones y retroalimentación en general de las personas usando tu producto, ganarás más empatía por tus usuarios. También tendrás una mejor actitud cuando estés intentando arreglar problemas en tu producto, porque tendrás mejor visibilidad de cómo tus decisiones afectan a otras personas — directa, o indirectamente.

    Además, afilas tus habilidades de comunicación a la hora de reportar bugs por tu cuenta. Algo cambia cuando parte de tu trabajo es intentar exprimir información de un cliente que solamente manda un “no funciona” con una captura de pantalla de un 404. Tu próximo reporte de un bug será mucho más claro, conciso y completo. Te lo garantizo.

    Hacer soporte no es sencillo. Tienes que aprender a leer entre líneas para entender qué es lo que realmente te están reportando. Pero los beneficios de desarrollar esas habilidades son tangibles. Después de cumplir un tiempo haciendo soporte, tendrás un mejor entendimiento de lo que realmente valoran tus usuarios. Así, cuando vuelvas a trabajar en crear tu producto, sabrás exactamente a qué ponerle atención y cómo darles más valor agregado.

    Ser un ingeniero de software encargado de hacer soporte es un ejercicio de humildad. Te darás cuenta de que tus preconcepciones sobre cómo se usaría tu producto son erróneas, y de que, por más que te cueste aceptarlo, no puedes predecir cómo alguien va a interpretar tus propuestas de solución. Eres humano, y hay cosas que ignoras. Esos espacios en tu conocimiento se hacen más obvios cuando te toca ayudar a otra a persona a desbloquearse.

    Haz soporte. Te conviene.

  • 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?

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

  • Ser bueno técnicamente en X o Y tecnología no te hace bueno en todo lo demás que conlleva trabajar en esta industria. Necesitas ponerle más atención a eso.

    Es muy de programadores creer que como somos buenos en X, automáticamente somos buenos en Y. Pero eso está muy lejos de la realidad.

    Puedes dominar Linux, y carecer aún de la empatía necesaria para poder ser líder de un proyecto.

    Puedes ser un experto en Ruby on Rails, y necesitar ayuda para saber cómo arreglar una discusión en tu equipo.

    Puedes haber escrito el libro sobre trabajo remoto y aún así regarla horriblemente… porque nunca desarrollaste el hábito de resolver problemas desde la empatía y la compasión.

    Y ejemplos como estos hay miles. Todos hemos conocido alguien muy bueno en la parte técnica, pero que funcionalmente es más un blocker que un apoyo (o una molestia, cuando menos) para el equipo.

    Un líder…

    • con actitud de “quítate yo lo hago”…
    • que responde preguntas de manera condescendiente…
    • que no protege a su equipo…

    … pero que es muy bueno en Linux. ¿… yay?

    El argumento de que necesitas ponerle más atención a tus soft skills no es una negación de que la tecnología es importante. A final de cuentas es la parte operativa que te toca desempeñar.

    Y es ahí donde se abre la discusión.

    ¿Cómo le vas a hacer para darte cuenta de que la parte técnica es únicamente eso, UNA PARTE, de lo que te toca hacer en esta industria?

    Encontremos la respuesta juntos.

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

  • Probablemente te llueven ofertas de trabajo en LinkedIn — simplemente por listar el lenguaje de programación de moda como una de tus habilidades. Si es así: cuidado, esa seguridad que sientes es falsa.

    Saber más lenguajes, tecnologías y metodologías no significa que tienes mejores prospectos para crecer profesionalmente.

    Una trampa común para las personas que van iniciando en desarrollo de software es creer que su valor real en esta industria es el stack de tecnología que dominan. Así como yo, tú probablemente en algún momento sentiste orgullo en decir que desarrollabas X tecnología, y nada más. Pero te tengo que decir algo: el stack tecnológico, por más variado, amplio, profundo y dinámico que sea, es meramente un detalle de implementación. Cualquiera puede aprender cualquier lenguaje de programación, y volverse suficientemente bueno, con suficiente dedicación.

    Una carrera profesional, al contrario de un simple trabajo, no se construye de manera lógica, lineal o transaccional.

    Todos los carpinteros saben usar martillos, serruchos, sierras. ¿Por qué hay carpinteros más exitosos que otros? ¿Es porque saben usar el martillo mejor con más estilo? ¿O porque agarran el serrucho de una manera muy particular?

    El carpintero más exitoso, que se da el lujo de decir con qué clientes sí quiere trabajar; aquel que es reconocido por la manera en que materializa su visión de cómo se debería de ver un mueble, no llegó a esa posición por tener el mejor martillo. Ese carpintero se dio cuenta de que lo que realmente importa (y por lo que le pagaban) era todo lo demás. Entregar a tiempo, cumplir su palabra, saber negociar… no ser el mejor usando una herramienta en particular, sino saber qué herramienta usar para lograr su objetivo.

    ¿Cuándo fue la última vez que escuchaste alguien en una posición importante en esta industria presentarse listando las tecnologías que dominan? Y aquí estamos muchos, creyendo que llegaremos lejísimos y tendremos una carrera siendo nada más un “Ruby Developer”.

    Desarrolladores de Ruby encuentras en todos lados. Un verdadero profesional de la industria que sepa Ruby es algo mucho más raro.

  • Si estás leyendo esto es probable que te sientas estancado o estancada en tu carrera. Sí, has estado desarrollando software, tal vez profesionalmente, por algún tiempo. Pero ese breakthrough aún no llega.

    Aquí hay 7 cosas que estás haciendo, y que te están metiendo el pie sin que te des cuenta.

    1. No tienes bien definido qué quieres hacer, o en quién te quieres convertir. Te gustaría dominar cierta tecnología, pero no tienes claro por qué, ni para qué usarás ese dominio una vez que lo obtengas. Básicamente estás aprendiendo por aprender.
    2. Estás construyendo en aislamiento. Crees que la solución es más importante que el proceso, cuando en realidad en el desarrollo del problema es donde se encuentran los verdaderos aprendizajes. Nada crece en un vacío.
    3. Estás acumulando conocimiento. Le das más valor a aprender cosas nuevas, que a aplicarlas y experimentar. En algún momento tienes que cerrar tus 200 cursos de Platzi y ponerte a resolver problemas reales. goto: 1.
    4. Te quedas con la textura de las discusiones, e ignoras el bigger picture. ¿Qué importa más, si ganó tu propuesta o si la solución acordada impacta de manera positiva al equipo?
    5. Le das demasiada importancia a los detalles de implementación. Sí, es importante el framework que quieres usar, o la arquitectura con la que quieres resolver el problema. Pero nada es más importante que resolver el problema a la mano.
    6. Aún le tienes miedo a tu ego. No quieres fallar en público, le temes a compartir tu proceso, y prefieres llegar con soluciones ya armadas. Crees que la opacidad de tus respuestas es una ventaja, porque te hace esencial. En realidad te hace un punto de fallo dentro del equipo.
    7. Estás aplicando demasiada lógica. Tratas a las personas con la misma frialdad con la que diseñas algoritmos. No es sorpresa que la tengas difícil a la hora de generar capital social.

    Haz pequeños ajustes en estas 7 áreas, y verás cómo por arte de magia las oportunidades de crecimiento profesional comienzan a aparecer ante ti.

  • La trampa de la productividad sin consciencia

    ¿Por qué quieres incrementar tu productividad? La respuesta más común a esta pregunta es “para poder hacer más cosas”. Habiendo yo mismo dado esta respuesta múltiples veces, intento reflexionar en qué parte del proceso de crecimiento comenzamos a asociar la cantidad de cosas que hacemos con nuestro valor como personas.

    La idea de ser más productivo no debería de estar enfocada en hacer más, sino en reducir la fricción para que hagamos lo que tenemos que hacer de la manera más tranquila posible. De la manera más humana posible.

    Tú y yo somos parte de un sistema que, hora tras hora, está buscando exprimir la mayor cantidad de productividad de cada uno de nosotros. Eficiencia, dicen, es lo principal. Ser eficientes. Ser productivos. Si no estás siendo productivo, estás desperdiciando recursos. Si no maximizas tus horas de trabajo, estás siendo irresponsable.

    Mientras más enfoque le das a ser productivo y a incrementar tu eficiencia, más estás renunciando a lo que te hace humano: la imperfección. Al espacio para tener sentimientos, opiniones y reacciones a las circunstancias que se te presentan.

    A alguien que idealiza la como una medida para determinar su valor le costará mucho entender que lo que te hace único es tu perspectiva, experiencia de vida y tu humanidad. La misma humanidad que te hace a veces fallar en tus metas, y no completar tu lista de tareas a tiempo. Colectivamente, mientras más nos enfoquemos en ser productivos y eficientes por el simple hecho de hacer más, nos haremos menos humanos. Porque entonces necesitaremos menos personas.

    “Suena la campana que aún puede sonar. Olvida tu ofrenda perfecta. Hay una grieta en todo. Es así como entra la luz.” Leonard Cohen inicia su canción “Anthem” con esa reflexión.

    La próxima vez que te quieras sentir mal por no ser “suficientemente productivo”, recuerda: hay una grieta en todo. Es así como entra la luz.