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

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.