Más allá de las líneas de código: Un cambio de chip necesario
Si me hubieras preguntado hace ocho o nueve años qué era lo más importante para ser un desarrollador senior, te habría soltado una retahíla de frameworks, patrones de diseño ultra complejos y probablemente te habría hablado de la última librería de gestión de estado que acababa de salir en Twitter. En aquel entonces, mi mundo empezaba y terminaba en el editor de código. Para mí, un buen día era aquel en el que conseguía una abstracción tan elegante que ni yo mismo la entendía del todo a la mañana siguiente. Sentía que si dominaba la herramienta, dominaba el mundo.
Mi experiencia con la obsesión técnica
Recuerdo perfectamente un proyecto en el que me empeñé en montar una arquitectura de microservicios para una aplicación que, sinceramente, no iba a tener más de cien usuarios concurrentes. Me pasé semanas configurando Docker, Kubernetes y una mensajería entre servicios que era una auténtica obra de arte de la ingeniería. ¿El resultado? El cliente estaba frustrado porque no veía avances en la funcionalidad que realmente necesitaba, y yo estaba agotado intentando mantener una infraestructura que nos venía tres tallas grande. Estaba tan centrado en el "cómo" que me olvidé por completo del "para qué".
Ese fue el primer bofetón de realidad. Me di cuenta de que a nadie (fuera de mi círculo de amigos devs) le importaba si usaba Clean Architecture o si mi código era el más purista del mundo. Lo que el cliente necesitaba era que su proceso de facturación dejara de fallar los lunes por la mañana. Punto. Ahí empecé a entender que nuestro trabajo no es escribir código, sino resolver problemas usando el código como herramienta.
¿Por qué me parece importante levantar la cabeza del teclado?
La diferencia entre un picacódigo y un desarrollador de software real reside en la capacidad de entender el contexto. Cuando entiendes de dónde viene el dinero en la empresa para la que trabajas, o cuáles son los puntos de dolor reales de los usuarios que usan tu app, tus decisiones técnicas cambian por completo. Ya no eliges una tecnología porque sea la más popular en GitHub, sino porque es la que mejor se adapta a los tiempos y necesidades del negocio.
Entender el negocio te da una superpotencia: la capacidad de decir "no". Y decir que no a una funcionalidad innecesaria o a una complicación técnica que no aporta valor es, a veces, mucho más valioso que escribir mil líneas de código impecable. Te vuelves un aliado estratégico, no solo un recurso que transforma tickets de Jira en funciones de JavaScript. Y créeme, esa transición te hace sentir mucho más valorado y, sobre todo, mucho más tranquilo.
Lo que he aprendido en este viaje
He aprendido que la empatía es una habilidad técnica. Sí, como lo oyes. Empatía con el usuario, pero también con el dueño del negocio que está arriesgando su capital. Si entiendes que cada hora que pasas refactorizando algo que ya funciona es una hora que no estás aportando valor directo, empiezas a priorizar de otra manera. No digo que haya que escribir código basura, ni mucho menos. Lo que digo es que hay que buscar el equilibrio entre la excelencia técnica y la viabilidad del producto.
Otra lección importante ha sido mejorar mi comunicación. Antes me frustraba cuando alguien de marketing me pedía un cambio "sencillo" que técnicamente era un mundo. Ahora, en lugar de soltar un sermón sobre la deuda técnica, trato de explicar el impacto en el negocio: "Si hacemos esto ahora de esta manera rápida, en tres meses nos costará el doble sacar nuevas funcionalidades". Hablar el mismo idioma que el resto del equipo lo cambia todo. Dejas de ser el "raro del ordenador" para ser alguien que empuja el barco en la misma dirección que los demás.
Reflexiones finales y un consejo de amigo
Hoy en día vivo mucho más tranquilo. Ya no sufro si no estoy a la última en el framework de moda cada semana. Me enfoco en entender el dominio del problema, en hablar con la gente y en construir soluciones que duren. Mi código actual es probablemente más aburrido que el de hace cinco años, pero es infinitamente más útil y fácil de mantener. Y eso, al final del día, es lo que te permite cerrar el portátil a tu hora y disfrutar de la vida sin tener la cabeza dando vueltas a un bug en una arquitectura excesivamente compleja.
Si estás empezando o si llevas tiempo sintiéndote quemado, te invito a que hagas el ejercicio de preguntar en tu próxima reunión: "¿Cómo ayuda esta tarea exactamente a que el negocio crezca o el usuario sea más feliz?". Te sorprenderá cómo esa simple pregunta puede cambiar tu perspectiva y tu forma de programar. Al final, somos solucionadores de problemas, y el código es solo el lenguaje en el que escribimos las soluciones.