Archivos de la categoría Psicología

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.

Reactancia: así se llama lo que sientes cuando te hacen micromanagement

Es probable que hayas experimentado una reacción emocional particular, aunque tal vez no sepas cómo se llama. Se llama reactancia, y es una reacción emocional que ocurre cuando sientes que tu libertad está siendo amenazada.

La reactancia puede surgir en una variedad de contextos, pero en el mundo de la ingeniería de software, aparece cuando alguien en una posición de autoridad, como tu manager o líder de equipo, te dice exactamente cómo hacer tu trabajo. En nuestra industria, a esta práctica se le conoce coloquialmente como micromanagement. Seguramente habrás escuchado el término.

Imagina que estás trabajando en un proyecto de software complejo. Has estado trabajando en él durante semanas, y has desarrollado un plan sólido para su implementación. Pero entonces, tu gerente, sin previo aviso, te dice que cambies tu enfoque y sigas un camino diferente sin una razón aparente. En lugar de considerar sus sugerencias de forma templada, sientes una ola de resistencia, frustración, o hasta enojo. Esto es la reactancia en acción.

La reactancia es una respuesta natural a la amenaza percibida a nuestra autonomía. Como ingenieros de software, valoramos nuestra habilidad para resolver problemas y diseñar soluciones. Cuando alguien intenta imponer su camino, puede sentirse como una invasión a nuestra libertad para innovar y crear.

De forma práctica, la reactancia se puede manifestar de diferentes maneras. Comúnmente, si estás experimentando reactancia, puede que sientas una fuerte resistencia a acatar las instrucciones y te sientas frustrado o hasta enojado. Puede también que comiences a procrastinar y dejar que el trabajo se apile. En casos extremos, la reactancia se puede manifestar como rebeldía, al sentirte obligado a hacer exactamente lo opuesto que te dijeron.

Es importante recordar que todos experimentamos esta reacción emocional de manera diferente. Al ser consciente de cómo se manifiesta en ti, puedes aprender a manejarla de manera más efectiva.

Entonces, ¿cómo puedes manejar la reactancia?

  • 1. Reconoce tus emociones: Primero, tienes que ser consciente de que estás experimentando reactancia. Si te sientes frustrado o resistente después de recibir instrucciones, es posible que estés experimentando este fenómeno.
  • 2. Comprende la intención: A veces, las personas que nos dan instrucciones tienen buenas intenciones. Intenta entender por qué te las están dando. ¿Tienen experiencia que tú no tienes? ¿Están tratando de evitar un problema que han visto antes?
  • 3. Comunícate abierta y honestamente: Si sientes que tu libertad está siendo amenazada, habla con la persona que te está dando instrucciones. Explica cómo te sientes y propón alternativas que te permitan mantener tu autonomía. Recuerda que tú también puedes dar feedback a tus líderes. Si sientes lo contrario, analiza si es momento de cambiar de ambiente de trabajo.

Si lo ves de esta manera, el estar consciente de la existencia de, y saber cómo manejar la reactancia es una cualidad importantísima en un desarrollador de software senior. Significa que son capaces de prevenir conflictos innecesarios, facilitar la implementación de nuevas ideas y mantener un alto nivel de motivación tanto en ellos mismos como en su equipo.

En resumen, la reactancia es una reacción emocional que todos hemos experimentado, especialmente cuando sentimos que nuestra libertad está siendo amenazada. En el ámbito de la ingeniería de software, esta amenaza puede presentarse cuando alguien en una posición de autoridad, como un gerente, nos dice exactamente cómo hacer nuestro trabajo, un fenómeno conocido como micromanagement. La reactancia puede manifestarse de varias formas, desde resistencia y frustración hasta procrastinación y rebeldía. Sin embargo, al reconocer estas emociones, comprender las intenciones detrás de las instrucciones que recibimos y comunicarnos de manera abierta y honesta, podemos manejar efectivamente la reactancia.

Para un desarrollador de software, la capacidad de manejar la reactancia puede prevenir conflictos innecesarios, facilitar la implementación de nuevas ideas y mantener un alto nivel de motivación, tanto personalmente como dentro del equipo. Por lo tanto, entender y manejar la reactancia no solo te permitirá recuperar u sentido de autonomía, sino que también te equipa con las herramientas necesarias para prosperar en tu campo.