Ese momento en el que el ego del programador choca con la realidad
Si me hubieras preguntado hace cinco o seis años qué era lo más importante en un proyecto de software, te habría soltado un discurso de media hora sobre la Clean Architecture, el desacoplamiento extremo, la cobertura de tests al 100% y por qué usar ese framework de moda que acababa de salir era de vida o muerte. En aquel entonces, mi mundo empezaba y terminaba en el editor de código. Me sentía un artesano, alguien cuya misión era construir catedrales digitales de código impecable. Pero claro, había un pequeño detalle que solía ignorar: nadie vive dentro de una catedral si no tiene puertas para entrar o si está construida en mitad del desierto.
Mi experiencia: La catedral que nadie visitó
Recuerdo perfectamente un proyecto en el que puse toda mi alma. Era una herramienta interna para una empresa de logística. Me pasé semanas —y no exagero— diseñando un sistema de estados ultra complejo y modular. Estaba orgulloso. El código era una delicia, las abstracciones eran tan elegantes que casi daban ganas de enmarcarlas. Cuando por fin lo lanzamos, me senté a esperar los aplausos de los usuarios. ¿Sabes qué pasó? Que los operarios del almacén no entendían nada. La interfaz era confusa porque yo me había centrado en que el state management fuera perfecto, no en que ellos necesitaban pulsar un botón gigante con guantes puestos mientras conducían una carretilla.
Ese fue mi primer gran bofetón de realidad. Me di cuenta de que había gastado un tiempo precioso de la empresa y mi propia energía en resolver problemas de ingeniería que yo mismo me había inventado, mientras ignoraba por completo el problema real del usuario. Había construido un motor de Ferrari para un carrito de la compra. Fue frustrante, me sentí un poco tonto, pero fue el inicio de mi transformación.
¿Por qué me parece vital este cambio de mentalidad?
A ver, no me malinterpretes: escribir código limpio sigue siendo fundamental. No estoy diciendo que ahora debamos picar código basura y tirar para adelante. Lo que digo es que el código es solo un medio, nunca el fin. Como desarrolladores, a veces caemos en la trampa de pensar que nos pagan por escribir TypeScript o Go. La realidad es que nos pagan por solucionar problemas. Si puedes solucionar un problema con un formulario de Google en lugar de una SPA compleja que tarda tres meses en desarrollarse, a veces esa es la decisión técnica correcta.
Entender el producto significa entender el negocio. Significa preguntar "¿Por qué estamos haciendo esto?" antes de preguntar "¿Qué librería usamos?". Cuando te preocupas por el producto, dejas de ser un mero ejecutor de tickets de Jira para convertirte en un motor de valor. Y te aseguro que cuando empiezas a proponer mejoras que afectan positivamente a los usuarios, tu valor como profesional se multiplica por diez.
Lo que he aprendido en este viaje
He aprendido a amar la simplicidad. Antes, si un problema era sencillo, yo lo complicaba para que pareciera "profesional". Ahora, si puedo evitar escribir código, lo evito. He adoptado el principio YAGNI (You Ain't Gonna Need It) como si fuera mi religión. ¿Para qué vamos a implementar un sistema de permisos basado en roles ultra dinámico si de momento solo hay dos usuarios? Mejor hagamos algo sencillo, validemos que el producto funciona y ya evolucionaremos el código cuando el éxito nos obligue a ello.
Otra lección importante ha sido la comunicación. Ahora paso mucho más tiempo hablando con los Product Managers, con los diseñadores y, si puedo, con los usuarios finales. Escuchar sus frustraciones me da mucha más información sobre cómo estructurar mi base de datos que cualquier hilo de Twitter sobre las bondades de las bases de datos vectoriales. He aprendido que un bug en la lógica de negocio es mucho más costoso que un pequeño error visual, y que la mejor arquitectura es aquella que permite que el producto cambie rápido sin romperse.
// Mi mentalidad de antes:
function crearUsuario(datos) {
// 200 líneas de validaciones, eventos, logs y patrones de diseño complejos
// porque "quizás en el futuro necesitemos escalar a un millón de usuarios"
}
// Mi mentalidad de ahora:
function crearUsuario(datos) {
// Lo mínimo para que el usuario pueda empezar a usar la app HOY.
// Si mañana escalamos, ya sé cómo refactorizar esto sin dramas.
}
Reflexiones finales
Si estás empezando o si llevas años sintiendo que tu trabajo es solo "picar", te animo a que levantes la cabeza del teclado. Pregunta para qué sirve esa funcionalidad que estás programando. Intenta entender cómo gana dinero tu empresa o cómo ayuda tu software a la gente. Te prometo que ver el impacto real de lo que construyes es mucho más gratificante que conseguir que una función sea un 5% más rápida. Al final del día, los frameworks van y vienen, pero la capacidad de entender un problema y traducirlo en una solución útil es lo que realmente nos define como desarrolladores senior. Menos ego de programador y más empatía con el usuario, ese es mi nuevo mantra.