• Las dos dimensiones del trabajo, y cómo puedes usarlas a tu favor

    Todo trabajo tiene dos dimensiones. Tienes que estar consciente de esto si quieres maximizar tu impacto en cualquiera que sea tu responsabilidad.

    • La dimensión operacional o práctica.
    • La dimensión política o de poder.

    Mientras más rápido logres reconciliar este hecho, más sencillo será navegar tu día a día en una organización. Te quiero contar un poco de cada una de estas dimensiones, para que entiendas cómo la puedes usar a tu favor.

    Dimensión operacional

    Esta dimensión es práctica, porque se enfoca en el “qué”. Te pagan por programar, por diseñar o por enseñar.

    Lo más importante en esta dimensión es tu craft: que mejores tu técnica, que desarrolles sistemas de productividad para que tu producción sea mucho más eficiente y prolífica. Lograr identificar qué tipo de música te ayuda a escribir mejor código es un claro ejemplo de esto. Saber que tienes que desayunar para poder concentrarte también.

    La mayoría de personas estamos familiarizados con esta dimensión del trabajo porque es la que nos enseñan en las escuelas y los cursos. Los problemas que se presentan en esta dimensión son técnicos y tangibles. Se pueden resolver con un Pull Request, o haciendo una modificación a procesos de la organización.

    Dentro del gran esquema de las cosas, los problemas en la dimensión operacional son problemas sencillos por su misma naturaleza práctica. Y aunque esto puede parecer algo positivo, existe un riesgo latente para las personas que únicamente se enfocan en dominar la dimensión operacional de su trabajo: quedarse haciendo lo mismo durante toda su vida.

    En esta dimensión, lo que te preocupa es resolver el problema. No importa si par hacerlo necesitas colaborar, aprender una nueva tecnología o hacer algo que no estaba en tu contrato.

    Dimensión política

    Aquí es donde la cosa se pone buena, porque dejamos de preocuparnos por la exactitud de las soluciones, y nos empezamos a preocupar por cómo tal o cual solución nos hace sentir.

    Al contrario de la dimensión práctica, con la política no muchos estamos conscientes de que existe. Desafortunadamente, de esta dimensión se habla poco en las escuelas y cursos, y muchas personas simplemente le ponen la etiqueta de que “así son los trabajos”.

    La dimensión política se trata del ego. Si en la dimensión práctica lo más importante es el “qué”, en la dimensión política lo que más importa ese el “cómo” y el “quién”.

    Esta dimensión del trabajo es un poco más complicada. Los problemas que se originan son mucho más sutiles de detectar, y no se pueden arreglar con un Pull Request. Me atrevería a decir que todos hemos sentido esa impotencia de no sentirnos reconocidos, y de haber sido humillados por otro miembro de nuestro equipo. ¿Esa vez que te fueron a acusar con tu jefe porque no dejaste de hacer algo para ayudar con algo que no estaba en tus prioridades? Política.

    En esta dimensión es más importante el reconocimiento, el poder y el status. Las personas que operan en esta dimensión no es suficiente saber que se llegó a la meta: necesitan saber que se llegó a la meta gracias a ellos. Un miembro de la organización que se enfoca en la política, se convierte en jefe. Alguien que aprende a balancear la política con la operación, se convierte en un líder. Porque sabe que lo más importante es apoyar a su equipo a tener buenos resultados. Y eso puede significa crear espacios para que otras personas puedan tomar las riendas de la situación en algún momento.

    Donde convergen las dos: el día a día

    Todos los empleos están compuestas por ambas dimensiones. Como todo en extremo, tener un trabajo 100% operativo o 100% político, puede ser algo poco ideal.

    El balance que te propongo es el siguiente: busca maneras de nutrir la dimensión práctica de tu trabajo, y busca maneras de mantener tu dimensión política a raya. El esfuerzo por mejorar tu carrera profesional no debería de estar únicamente concentrada en una de las dimensiones de tu trabajo.

    • Si ignoras lo político, corres el riesgo de quedarte estancado en tu carrera.
    • Si ignoras lo práctico, corres el riesgo de avanzar en tu carrera pero sin sustento alguno. Como los políticos que llegan a un cargo público sin tener la más mínima conciencia de las consecuencias de sus decisiones.

    Por más que intentes enfocarte únicamente en agregar valor a través de tu trabajo, necesitas tener en cuenta que hay un componente político que tienes que resolver. Hazte consciente de esta realidad, y trabaja para encontrar ese balance que te funcione. Lo demás es detalle de implementación.

  • Las 4 fases del conocimiento

    [fusion_builder_container type=”flex” hundred_percent=”no” equal_height_columns=”no” menu_anchor=”” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” class=”” id=”” background_color=”” background_image=”” background_position=”center center” background_repeat=”no-repeat” fade=”no” background_parallax=”none” parallax_speed=”0.3″ video_mp4=”” video_webm=”” video_ogv=”” video_url=”” video_aspect_ratio=”16:9″ video_loop=”yes” video_mute=”yes” overlay_color=”” video_preview_image=”” border_color=”” border_style=”solid” padding_top=”” padding_bottom=”” padding_left=”” padding_right=””][fusion_builder_row][fusion_builder_column type=”1_1″ layout=”1_1″ background_position=”left top” background_color=”” border_color=”” border_style=”solid” border_position=”all” spacing=”yes” background_image=”” background_repeat=”no-repeat” padding_top=”” padding_right=”” padding_bottom=”” padding_left=”” margin_top=”0px” margin_bottom=”0px” class=”” id=”” animation_type=”” animation_speed=”0.3″ animation_direction=”left” hide_on_mobile=”small-visibility,medium-visibility,large-visibility” center_content=”no” last=”true” min_height=”” hover_type=”none” link=”” border_sizes_top=”” border_sizes_bottom=”” border_sizes_left=”” border_sizes_right=”” first=”true”][fusion_text]

    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.

     

    Fases del conocimiento y el efecto Dunning-Kruger
    Fases del conocimiento y el efecto Dunning-Kruger

     

    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?

    [/fusion_text][/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]

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

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

  • Por qué importan los 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 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.

  • Trabajo remoto: encuentra uno antes de que sea demasiado tarde

    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.

  • 83% de los desarrolladores de software sufren burnout

    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.

  • Cómo trazar tu futuro en el desarrollo de software y alcanzar tus objetivos

    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.

  • GitHub Copilot: si solamente sabes programar, tu carrera tiene fecha de caducidad

    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.

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

  • Ser bueno técnicamente es solamente una parte de lo que te toca hacer

    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.