El peso de la perfección en mis hombros
Recuerdo perfectamente aquellas noches de café frío y ojos irritados, allá por mis primeros años como desarrollador. Me obsesionaba la idea de que mi código debía ser una obra de arte. Si una función tenía un par de líneas más de lo que yo consideraba 'elegante', o si no aplicaba el último patrón de diseño que había leído en un libro de arquitectura limpia, sentía que estaba fracasando como profesional. Me pasaba horas refactorizando código que ya funcionaba perfectamente, solo por el placer estético de verlo 'limpio'.
Cuando el Clean Code se convierte en una jaula
No me malinterpretéis, el Clean Code y los principios SOLID son herramientas maravillosas, pero durante mucho tiempo los convertí en mi propia jaula. Me frustraba si el equipo de negocio me pedía un cambio rápido para probar una idea en producción. Para mí, ese cambio rápido 'ensuciaba' mi preciosa arquitectura. Estaba más preocupado por la pureza del código que por el valor que ese código estaba aportando a la empresa o a los usuarios finales.
Esa mentalidad me llevó a un estado de ansiedad constante. Cada vez que abría un repositorio antiguo, sentía una mezcla de vergüenza y ganas de borrarlo todo para volver a escribirlo 'bien'. No disfrutaba del proceso de crear; solo sufría por no alcanzar un ideal de perfección que, sinceramente, solo existía en mi cabeza y en algunos hilos teóricos de Twitter o blogs de gurús que nunca parecen tener plazos de entrega.
El día que todo cambió: Valor vs. Estética
Hubo un momento de inflexión en mi carrera. Estaba trabajando en una startup donde el ritmo era frenético. Teníamos una funcionalidad crítica que debía salir en dos días para no perder una ronda de inversión. Yo quería implementar un sistema de eventos desacoplado, con sus suscriptores, sus interfaces y una inyección de dependencias de manual. Mi responsable, un tipo con mucha más experiencia y menos ego técnico que yo, se me acercó y me dijo: 'Roberto, al inversor no le importa si usas el patrón Observer o un simple switch/case. Lo que le importa es que el usuario pueda registrarse y pagar sin errores el lunes por la mañana'.
Fue como un jarro de agua fría, pero tenía toda la razón. Pasé esos dos días escribiendo código funcional, robusto, pero quizás no 'hermoso'. Y lo más sorprendente fue que, una vez lanzado, no pasó nada malo. El sistema funcionó, la empresa consiguió la inversión y yo no me sentí como un impostor. Al contrario, me sentí útil por primera vez en mucho tiempo. Había entregado valor real en el tiempo necesario.
¿Por qué el pragmatismo me hizo mejor?
Al soltar la carga de la perfección, empecé a notar cambios increíbles en mi forma de trabajar y en mi bienestar. En primer lugar, mi productividad se disparó. Ya no me quedaba bloqueado decidiendo si un método debía ser privado o protegido durante veinte minutos. Aplico la regla del 80/20: el 80% del valor suele venir del 20% del esfuerzo.
Además, mi relación con el equipo mejoró. Ya no era el 'policía del código' en las Code Reviews que criticaba cada detalle insignificante. Empecé a centrarme en lo que realmente importa: la seguridad, el rendimiento y la legibilidad básica. Si el código se entiende y funciona, muchas veces es suficiente. El código perfecto es aquel que se entrega a tiempo y soluciona el problema del cliente, punto.
// Un ejemplo de lo que antes me quitaba el sueño
// Antes: Quería una abstracción genérica para cualquier tipo de notificación
// Ahora: Escribo lo que necesito hoy, no lo que sospecho que necesitaré en dos años
function sendNotification(user, message) {
if (user.preferredMethod === 'email') {
return emailProvider.send(user.email, message);
}
// Si mañana añadimos SMS, ya lo meteremos aquí.
// No necesito una NotificationStrategyFactoryInterface ahora mismo.
}Lo que he aprendido en este viaje
He aprendido que el código tiene fecha de caducidad. El software es algo vivo y cambiante. Ese código 'perfecto' que escribas hoy, dentro de seis meses probablemente será obsoleto porque los requisitos habrán cambiado. Por lo tanto, obsesionarse con una arquitectura hiper-flexible suele ser una pérdida de tiempo. Es lo que llamamos Over-engineering o 'Gold Plating'.
Hoy en día, priorizo la simplicidad sobre la elegancia técnica. Prefiero un código que cualquier compañero pueda entender en cinco minutos a uno que requiera un doctorado en patrones de diseño para ser modificado. He aprendido a aceptar la 'deuda técnica' como una decisión de negocio consciente, no como un pecado capital. Si sé que estoy cortando camino para llegar a una fecha, lo documento, lo asumo y sigo adelante.
Reflexiones finales: Programar para humanos
Si estás pasando por esa fase de frustración donde sientes que tu código nunca es lo suficientemente bueno, respira. Nadie escribe código perfecto. Los mejores desarrolladores que conozco son aquellos que saben cuándo ser estrictos y cuándo ser pragmáticos.
Al final del día, programamos para humanos: para el usuario que usa nuestra app y para el compañero (o nuestro 'yo' del futuro) que tendrá que leer ese código. Ser mejor desarrollador no va de memorizar todos los patrones de la banda de los cuatro, sino de entender qué problema estás resolviendo y cómo hacerlo de la manera más sencilla y efectiva posible. Desde que acepté esto, disfruto muchísimo más de mi día a día y, curiosamente, mis proyectos tienen mucho más éxito. Menos ego, más valor.