El feedback está en todos lados

La retroalimentación, o feedback, es una de esas habilidades blandas que solemos ignorar hasta que nos enfrentamos a situaciones que la requieren. Pero aquí te digo algo: dar y recibir feedback no solo es crucial para tu desarrollo profesional, sino también personal.

Creo que la razón por la que ignoramos la importancia de esta habilidad hasta que es muy tarde es muy obvia, y también muy humana: es incómodo. Es incómodo reconocer nuestros límites, y darnos cuenta de que hay cosas en las que necesitamos mejorar. O, incluso, que hay cosas que hacemos, que tienen efectos secundarios que ni siquiera habíamos considerado.

Sin embargo, por más incómodo que sea, es importante que como profesionales del software desarrollemos la capacidad de dar, recibir, e integrar feedback. Después de todo, si nuestro trabajo se trata de ser lo suficientemente resilientes al enfrentarnos a problemas indefinidos, ¿por qué no deberíamos de invertir un poco en ser más resilientes en un ámbito más personal?

El feedback que recibes moldea tu trabajo. Y tu vida.

Hace más de 10 años, Héctor, uno de mis mejores amigos, me aconsejó que dejara de amargar a los demás si ya no quería ir a la universidad. “Si ya no quieres venir, no vengas, pero no estés aquí haciéndonos pasar un mal rato”. Ese fue mi último semestre en la escuela.

Unos años después, un recién graduado de Stanford me despidió semanas después de entrar a la startup donde ya llevaba yo más de un año trabajando. La relación no inició de buena manera, y un martes por la mañana me subí a una reunión de Hangouts con él, y me dijo que yo era muy difícil para trabajar, y que ese era mi último día.

¿Doloroso? Sí. ¿Incómodo? Obviamente. ¿Útil? También.

Durante mi carrera y vida personal, los momentos que han dejado huella son aquellos en los que recibí feedback. Tan directo como mi amigo diciéndome que ya no era divertido tenerme cerca, lo que me llevó a tomar una decisión que cambiaría la ruta de mi vida. O tan indirecto como alguien simplemente diciéndome que ya no quería trabajar conmigo, tomando una decisión por mí.

Consciente o inconscientemente, das y recibes feedback todo el tiempo

Pensaba que la retroalimentación era una actividad puntual que tenías que hacer y programar. Así como puedes quedar con tus amigos para salir a tomar algo, ¿quedamos para darnos feedback?

Aunque sí funciona así en el contexto profesional (en el mejor de los casos), la realidad es que constantemente estás dando y recibiendo feedback. Estés consciente de ello o no.

Las muecas o gestos que otros hacen cuando les cuentas tus ideas, también son una forma de feedback. ¿Se muestran emocionados y animados, o hacen gestos de duda y consternación? ¿Te hacen preguntas de seguimiento, o solo te escuchan, asienten, y pasan a lo siguiente?

Y lo mismo aplica para ti. ¿Cuál es tu postura cuando alguien te está compartiendo sus ideas? ¿Estás presente en la conversación, escuchando, o solo estás oyendo las palabras que salen de su boca?

Se trata del comportamiento y sus efectos, no de la persona

Es clave separar el comportamiento de la persona.

La Navaja de Hanlon, uno de mis modelos mentales favoritos, dice:

Nunca atribuyas a malicia lo que puede se explicado por estupidez.

En este caso, creo que aplica cambiar la palabra “estupidez” por “ignorancia”. No atribuyas a malicia, lo que puede ser explicado por ignorancia.

Todos somos ignorantes en algunos aspectos. Y está bien. Cuando das retroalimentación de manera directa — es decir, con intención — lo que estás buscando es hacerle saber a la otra persona el efecto de su comportamiento en su entorno, obsequiándole el beneficio de la duda de que dicho efecto se encuentra en su punto ciego.

Así, eliminas el componente personal de la retroalimentación e incrementas las probabilidades de que el comportamiento sea corregido.

Héctor hizo exactamente eso conmigo hace una década. En vez de decirme “eres un amargado y ya no quiero tenerte cerca”, me hizo saber el efecto que mi comportamiento estaba teniendo en mi grupo de amigos. Y no solo eso: también me dio una sugerencia de cómo lo podía resolver.

Y le estaré siempre agradecido.

Si haces lo que Héctor hizo conmigo, la persona que reciba nuestro feedback no lo verá como un juicio a su identidad personal (ego), sino como una oportunidad de revisar o seguir teniendo un comportamiento: algo que está completamente dentro de su control. Y sí, el feedback también es importante para reforzar los comportamientos con efectos positivos de las personas.

Hay miles de maneras de dar y recibir retroalimentación

También es retroalimentación:

  • El compromiso que generamos en otras personas
  • El detalle con el que otras personas contribuyen a nuestras ideas después de que se las contamos
  • La postura que adoptamos al interactuar con otros
  • La calidad de atención que le prestamos a alguien
  • El nivel de energía con el que interactuamos
  • Entre otras…

Haciéndote conscientes de esto, puedes apreciar la importancia de que, al compartir feedback puntual, tienes que hacerlo buscando resaltar aún más las características del comportamiento que quieres corregir o promover en la otra persona.

Recuerda que el feedback no es un lujo, sino una necesidad para crecer como profesional y ser humano. La invitación es a que aceptes la retroalimentación como una parte integral de tu oficio, tanto interna como externamente, y estarás en el camino hacia una carrera más humana y sostenible en la ingeniería de software.

El código que escribiste hoy ya es legado. No te encariñes.

Recuerdo la primera vez que escribí código en producción que me hizo sentir orgulloso. Había pasado un buen rato adentrándome en un dominio con el cual no estaba familiarizado. Cuando por fin pude entender cuál era el problema, y luego sentirme lo suficientemente competente para saber cómo resolverlo, me sentí el mejor desarrollador de software del mundo. That’s how it’s done, baby. Esa noche ni dormí de lo emocionado que estaba por haber encontrado una solución tan impecable para arreglar el bug que me habían asignado y así resolverle un problema a un cliente.

Un par de semanas después, un colega intentando resolver otro bug se encontró con mi código y decidió era un blocker para él poder resolver su problema. Hizo lo que haría cualquier otro (buen) ingeniero: analizó el problema, entendió el contexto del problema que yo había intentado resolver, lo incorporó a su conocimiento de dominio, e implementó una solución que abarcaba tanto mi problema como el suyo.

Cuando vi su Pull Request eliminando mi código, sentí una combinación entre frustración, vergüenza y hasta un poco de enojo. Pero recuerdo que principalmente me sentí “atacado”. Por alguna razón, el que otra persona hubiera venido a arreglar un error en el proyecto, y que parte de su solución fuera eliminar código que yo escribí… eso era algo personal. En su momento no dije nada, pero sí me quedé con esa insatisfacción por un buen rato.

Un poco después, en otra empresa, me volvió a pasar. En esta ocasión, mi código no estaba intentando resolver un bug particular, sino que intentaba crear una base para construir otro feature dentro de la aplicación. El Pull Request de mi compañero no solamente lo eliminaba, sino que repensaba completamente la filosofía con la que se deberían construir los features subsecuentes.

Ouch. Creo que en esta segunda ocasión sí le mencioné algo a mi manager, pero no dejé de tener una sensación incómoda.

Luego pasó otra vez. Y luego otra. Y otra.

Esto no dejó de pasar. Independientemente de la empresa en la que estuviera, eventualmente me iba a tocar revisar un Pull Request que modificara, o simplemente eliminara, código que yo había escrito.

Hasta que entendí que fomentar el apego emocional al código que escribía no iba a ser sostenible. Invariablemente, alguien más llegaría a transformarlo o eliminarlo. Eso no iba a cambiar — es la naturaleza de trabajar en esta industria. Entonces lo que tenía que cambiar era la forma en como me relacionaba con mi código.

No dejé de recibir Pull Requests que eliminaran mi código. Lo que sí cambió fue mi actitud al respecto.

Déjame contarte cómo lo logré.

Mascotas vs. Ganado

Tu código es ganado, no mascota.

Si me conoces, sabes que me encanta usar modelos mentales (en alguna ocasión incluso hablé sobre esto en un podcast), y me emociono cada vez que me encuentro uno nuevo para entender el mundo.

Resulta que la comunidad de DevOps tiene un modelo mental apto para este problema: Mascotas vs. Ganado (Pets vs. Cattle). Cabe aclarar que en el mundo de DevOps, la unidad atómica de información no es una línea de código, sino un servidor, pero la analogía aún aplica para nuestro propósito. Te explico cómo aplicaría este modelo mental para desarrollo de software.

DevOps Código
Mascotas Un servidor que no se puede caer. Tiene que estar siempre disponible, y no tiene redundancia. Código que es indispensable y único, y no puede ser eliminado.
Ganado Clústeres de servidores preparados para fallar y ser descartados si se necesita. Están diseñados con el manejo de fallas en mente, y su despliegue está automatizado. Código resiliente que está diseñado con flexibilidad en mente, y preparado para cuando inevitablemente falle o tenga que ser eliminado.

La idea central, obviamente, es que una mascota tiene un lugar especial en tu vida. A una mascota la cuidas, nutres, procuras su bienestar, y te devastaría perderla. Por el contrario, el ganado está para cumplir un propósito en específico, ya sea trabajar o proveer de alimento, y no reparas en usarla para su propósito. Con la mascota te encariñas. Con el ganado, no.

Es así como, aprendiendo de la experiencia de la comunidad DevOps, podemos entender que tenemos que ver el código que escribimos como ganado, y no como mascotas.

El trabajo de un desarrollador de software es resolver problemas, no escribir código

¿Por qué nos es tan sencillo encariñarnos con el código que escribimos?

Mi hipótesis es que, como desarrolladores, estamos acostumbrados a usar la lógica para resolver nuestros problemas, y nos es muy sencillo establecer una correlación directa entre la tarea mecánica de escribir código y nuestro valor como profesionales. Creemos que se nos paga por escribir código, cuando no es así.

Puede sonar contra intuitivo. Después de todo, muchas personas iniciamos en esta industria porque nos gusta escribir código. Pero la realidad de tener una carrera en esta industria es que la única razón por la que alguien estará dispuesto a pagarnos el sueldo tan alto que nos hemos acostumbrado a esperar es porque amos a resolverles un problema, a ellos o a sus usuarios — que lo hagamos a través del código que escribes es otra cosa.

Si tu única medida de valor es el código que escribes, no los problemas que resuelves, suena lógico que lo sientas como un ataque personal con carga emocional cuando alguien decide eliminar o modificar tu código.

Matt Basta en su newsletter aborda un punto tangencial, pero igual de relevante, para el tema del que estamos hablando:

A menudo escucho a gente bastante joven decir cosas como “Estoy aquí para crecer como ingeniero”. Crecer como ingeniero es mutuamente excluyente con cuánto duran tus contribuciones. “Crecer como ingeniero” significa convertirte en un mejor ingeniero, y convertirte en un mejor ingeniero (directa o indirectamente) significa mejorar en el uso de tus habilidades para crear valor. Al principio de tu carrera, el trabajo que realices probablemente tendrá mucha menos longevidad que el trabajo que realices más adelante, simplemente porque ganas madurez con el tiempo y aprendes a crear herramientas que tienden a ser útiles por más tiempo.

A veces, el valor que generas se traduce en resultados técnicos. A veces, es la forma en que trabajas con las personas que te rodean (colaborando, asesorando, etc.). A veces, se trata de cómo apoyas al resto del equipo. Hay muchas formas de crear valor.

Este es el verdadero aprendizaje: el código que escribes es únicamente una de las formas en las que se manifiesta el valor que agregas a tu equipo. ¿Por qué habríamos de darle un lugar tan prominente a algo que es inherentemente volátil, y que representa solo una de las muchas maneras en que nuestro valor profesional es manifestado?

No te encariñes con tu código

Como alguien que lo hizo profesionalmente por más de una década, reconozco lo satisfactorio que es escribir código que me gustaría viviera por siempre. Al mismo tiempo, como alguien que pasó por un arduo proceso de separar mi identidad personal de mi experiencia como desarrollador, reconozco que fomentar un apego emocional al aspecto técnico de nuestro trabajo no es una manera sostenible de llevar una carrera en esta industria.

Sobre todo, si lo que quieres hacer es trabajar en lo que te gusta por mucho tiempo.

Al final del día, tu impacto no son las líneas de código que escribes. Lo que realmente se queda es el problema que resolviste y cómo eso mejoró la experiencia del usuario o facilitó el trabajo de tu equipo. En ese sentido, tu trabajo es tan sustentable como los problemas que resuelves. Así que, la próxima vez que sientas un apego emocional hacia tu código, recuerda: no eres tus líneas de código; eres las soluciones que ofreces.

 

Elon Musk tiene un estilo de liderazgo que no deberías copiar

La semana pasada salió la esperada biografía de Elon Musk, por Walter Isaacson

Si me conoces, sabes que de mis principales intereses son la psicología y liderazgo. Esta es una rara oportunidad de descubrir lo que sucede en privado con una de las personas con más influencia en la industria de la tecnología. Sus modos (lo que se ve en público) no me encantan, pero el resultado a gran escala de sus esfuerzos es innegable.

Compré la biografía porque quiero conocer los matices de su personalidad y estilo de liderazgo.

Elon Musk Biography

En el pasado ya ha habido libros que intentan contar una historia para prevenir a otras personas de seguir caminos que llevan a situaciones indeseables que tienen el efecto contrario.

La pregunta es: ¿será que algunas personas van a leer esta biografía buscando justificación para ser igual de assholes que Elon?

En el minuto 14 de la entrevista que le hicieron a Walter Isaacson sobre el libro abordan este tema, y su respuesta es bastante clara: nadie debería de intentar emular a Elon Musk; una biografía no es un libro de recetas. Sin embargo, no dudo que muchos vayan a leer esta biografía y sentirse validadas en sus modos hostiles de tratar a la gente que trabaja con ellas. Si a Musk le funciona, a mí debería funcionarme también.

Saber venderte como desarrollador no es echar mentiras

¿Alguna vez has intentado venderte, hablar sobre tus logros y habilidades, y te sientes inadecuado o incómodo? Si tu respuesta es que no, déjame entonces preguntarte: en tu currículum, ¿compartes ejemplos de cómo le ayudaste al negocio con tus habilidades de desarrollo, o simplemente tienes una lista de tecnologías como JavaScript, HTML y CSS?

Ahí está.

Es hora de enfrentar este problema.

Auto-Sabotaje Técnico: por qué no sabes cómo venderte

Muchos ingenieros, programadores y profesionales técnicos están alérgicos a la idea de “venderse”. Preferimos hablar en lenguajes de programación, no en el lenguaje del valor humano o del impacto en el negocio. Desde un punto de vista psicológico, es una forma de auto-sabotaje. Minimizamos nuestro valor al no saber comunicarlo de manera efectiva.

Recuerdo una conversación con uno de mis mentores que cambió mi perspectiva. Me preguntó: “¿Por qué le tienes tanto miedo a venderte bien en la industria?” Mi respuesta fue rápida: “Porque no quiero echar mentiras.” Sin embargo, él me mostró que hablar de mis habilidades técnicas y el valor que agrego a los equipos, en términos que los responsables de presupuestos entienden, no es echar mentiras, sino traducción.

Naturalmente, como yo no estaba acostumbrado a hablar en esos términos, cuando hablaba de “valor agregado” y en vez de “arquitectura de aplicaciones” sentía que estaba echando mentiras. Pero no: estaba hablando de exactamente lo mismo, solamente que desde otra perspectiva.

Aprender a hablar el Lenguaje del Valor

Traduce tu valor. Como desarrolladores de software, tenemos que comenzar a ver que vender nuestras habilidades no es manipulación, sino adaptación. No es cambiar lo que hacemos, sino cómo lo comunicamos. La clave aquí es entender que en una organización se hablan diferentes lenguajes, y que aprender a hablarlos aumenta nuestro valor y nos permite colaborar de manera más efectiva.

Dominar el lenguaje del valor es esencial para tu desarrollo profesional. Esta habilidad no solo te beneficia diariamente como desarrollador de software, sino que se convierte en un factor decisivo al buscar un aumento, un nuevo trabajo o un rol más avanzado. Hablar en términos de valor puede ser la llave que abre la puerta a oportunidades que transformarán tu carrera.

Consejos prácticos para venderte mejor

Aquí hay algunos consejos prácticos para que comiences a perderle el miedo a venderte.

Identifica y lista tus habilidades: Antes de poder traducir tus habilidades a un lenguaje más accesible, primero debes saber exactamente qué estás ofreciendo. Esto va más allá de las habilidades técnicas; piensa también en las habilidades blandas que has desarrollado. Por ejemplo, si eres bueno resolviendo conflictos dentro de tu equipo, eso es algo que también tiene gran valor.

Consejo: usa el método STAR (Situación, Tarea, Acción, Resultado) para describir situaciones específicas donde demostraste tus habilidades, sea de liderazgo, trabajo en equipo o resolución de problemas.

Encuentra un Traductor de Valor: Este puede ser un mentor, un colega de otra área o incluso un amigo que tenga habilidades para comunicar y entender tanto el mundo técnico como el empresarial. Ellos pueden ayudarte a encontrar las palabras y conceptos que transmitan tu valor de una manera comprensible para todos.

Ejemplo: Si eres un experto en optimización de bases de datos, un “Traductor de Valor” podría ayudarte a describir esta habilidad como “mejorar la eficiencia operativa reduciendo los tiempos de espera para los usuarios”.

Practica con Escenarios Reales: No basta con saber cómo traducir tus habilidades; debes practicar. Ya sea en entrevistas de trabajo, conversaciones con stakeholders o incluso en tus interacciones diarias con tu equipo, toma la oportunidad de hablar sobre tu valor. La próxima vez que tengas una revisión de desempeño o una conversación similar, intenta usar este nuevo lenguaje de “valor”. Prepara antemano cómo vas a describir tus contribuciones de manera que resuenen con tu audiencia, y después evalúa cómo fue recibido.

Por ejemplo, la próxima vez que hables con un gerente de proyecto, un cliente o modifiques tu currículum, en lugar de decir que “implementaste un algoritmo de búsqueda eficiente,” podrías explicar que “mejoraste la experiencia del usuario al hacer que la búsqueda de información en la aplicación sea más rápida y precisa.”

Recibe Retroalimentación y Ajusta: Después de cada intento de vender tu valor, busca retroalimentación. ¿Fue efectiva tu comunicación? ¿Hubo algo que pudiste haber dicho de una manera más clara? Utiliza estos aprendizajes para ajustar tu enfoque en el futuro.

Aquí hay una oportunidad de ejercer la Mentalidad de Crecimiento: La habilidad de “venderse” es como cualquier otra habilidad: se puede aprender y mejorar. Mantén una mentalidad de crecimiento y estarás vendiéndote como un profesional en poco tiempo.

Conclusión

En definitiva, aprender a comunicar tu valor es mucho más que una técnica de negociación; es una inversión en tu crecimiento profesional y bienestar emocional. Al dominar el lenguaje del valor, no solo incrementas tus oportunidades para conseguir un mejor salario o avanzar a roles más prominentes. También ganas una nueva capa de autoconfianza, un sentido de propiedad sobre tu carrera que se traduce en un mayor cumplimiento personal y profesional.

Así que no lo postergues; empieza hoy a traducir tus habilidades técnicas en términos de valor.

No es solo un cambio de vocabulario; es una transformación completa que puede elevar tu carrera a nuevas alturas.