Cuando nos enfrentamos a un problema de programación, a menudo escuchamos frases tranquilizadoras pero limitantes:
"Esto ya ha sido resuelto por [insertar nombre de gurú aquí], solo sigue las mejores prácticas."Lenguaje del código: JSON / JSON con comentarios (json)Por un lado, estas palabras deberían tranquilizarme: mi problema ya ha sido decodificado y resuelto por mentes iluminadas. Por otro lado, me hacen sentir inadecuado, como si fuera un hereje incapaz de ver la «luz» de la solución perfecta, repitiendo errores superados desde hace cientos de años de historia informática.
Frases así nos llevan a creer que la informática es una ciencia exacta, como las matemáticas, donde 2+2 siempre es 4. Sugieren que si el proyecto está en el caos, si la deuda técnica nos asfixia o si el cliente está furioso, la culpa es exclusivamente nuestra: no hemos aplicado correctamente «La Receta». Pero después de años de teclados desgastados, empiezo a hacerme una pregunta incómoda: ¿y si las recetas de los Gurús fueran una estrella polar, útil para navegar, pero peligrosa si se confunde con el puerto de destino?
Para parafrasear al contador Ugo Fantozzi:
"Después de tres meses de lecturas malditas, Fantozzi vio la verdad y se turbó ligeramente, o mejor dicho, se cabreó como una bestia. ¡Entonces siempre me han tomado el pelo!"Lenguaje del código: JSON / JSON con comentarios (json)No se trata de menospreciar a los gigantes de la TI, sino de entender que ellos describen la excelencia en condiciones ideales. Nuestra misión, en cambio, es la ingeniería de lo posible. Un Senior no es quien sobrevive al barro, sino quien diseña la forma de sanear el terreno, un paso a la vez.
El espejismo del «Greenfield» y la estrategia en el «Brownfield»
Los «libros sagrados», desde Extreme Programming hasta Clean Code, florecen en el «Greenfield»: praderas verdes donde se construye desde cero, con equipos de alto nivel, presupuestos elásticos y cultura del fracaso. Kent Beck, Martin Fowler, Dave Farley y Robert C. Martin (Uncle Bob) son mentes brillantes, pero sus teorías asumen un contexto que en la realidad es más único que raro. Memes como
"Tiene que estar listo para ayer"Lenguaje del código: JSON / JSON con comentarios (json)no son solo bromas, son los límites de nuestro campo de juego. La realidad de la mayoría de nosotros es el Brownfield: monolitos estratificados desde 1995, bases de datos con campos llamados campo1, campo2, campo3 (con un manual que explica el significado de cada uno) y documentación «en la cabeza» de ex colegas.
Recuerdo un proyecto en el que un hilo de sangre me salía de los ojos cada vez que tenía que entender qué estaba pasando en la base de datos. A menudo trabajamos en sistemas que no se pueden tocar porque «nadie sabe qué pasa si borras esa columna». La seniority aquí no es resignación, es estrategia. Decir «el problema está resuelto» citando un libro es como sugerir el láser a un cirujano bajo bombardeos. El verdadero profesional sabe que el objetivo no es solo salvar al paciente hoy, sino mejorar las condiciones del hospital de campaña para que mañana la intervención sea más sencilla.
El impuesto sobre la Complejidad
El Test Driven Development es una herramienta poderosa, pero si se usa acríticamente genera arquitecturas retorcidas, saturadas de interfaces inútiles usadas por una sola clase y mocks frágiles que se rompen solo porque ha cambiado el funcionamiento interno del programa, que permanece consistente, pero el mock no.
El riesgo es un código «testeable», pero ilegible. Para los juniors esta pirámide de abstracciones es a menudo motivo de orgullo: «¡Guau, qué arquitectura fantástica!». Para un Senior, en cambio, existe la amarga conciencia de que quien escribió ese código podría haber dejado la empresa antes de que sea necesario pasar las noches en producción depurando un bug incomprensible. Es el momento de la fuga: el código fue escrito para mejorar el CV, no para ser mantenido.
¿Y el Clean Code? La obsesión por las funciones de tres líneas puede convertirse en una pesadilla. He trabajado en proyectos donde para entender un envío tenías que abrir 18 archivos diferentes constituidos en un 60% por comentarios heredados como este tomado del código base del núcleo de Linux:
FIXME: this function is never used, whyLenguaje del código: JavaScript (javascript)La esperanza aquí reside en la calidad como eficiencia: 50 líneas de código secuencial son a menudo más mantenibles que un rompecabezas de micro-funciones abstractas dispersas por todas partes, cada una con un nombre tan largo como una frase y un test que simula tres niveles de dependencias. El cliente no paga por la elegancia, paga para que funcione.
Continuous Delivery vs. Oficina de Compliance
Dave Farley nos enseña que deberíamos lanzar a producción varias veces al día. El despliegue no debería ser un evento, sino un «no-evento» libre de estrés. Hermoso. Pero luego intente decirle eso a la oficina de cumplimiento de un banco o al responsable de seguridad de una empresa que gestiona datos sensibles.
Ah, ¿quisieran hacer despliegue cada hora?
Aquí está el pase A-38 para completar por cada lanzamiento, firmado por el jefe de departamento, el CISO y el DPO.
Se necesita un plan de rollback validado y la ventana de despliegue es el martes entre las 2 y las 4 de la madrugada.El Gurú te dirá que es un problema cultural. Pero el desarrollador no tiene el poder de reescribir las leyes bancarias europeas o de convencer al auditor de que «nuestros tests cubren todo». Esas reglas nacieron de la sangre de desastres reales: alguien hizo un despliegue un viernes por la noche borrando los datos de diez mil clientes. La seniority estratégica acepta estos muros de goma e intenta automatizar lo que es posible, sin ignorar las restricciones de la realidad burocrática.
Microservicios: Escalabilidad vs Simplicidad
«Los monolitos no escalan». Y así dividimos sistemas eficientes en 47 microservicios que se comunican entre sí con siete protocolos diferentes (o llamadas directas a la base de datos ajena porque no había tiempo para la API). El gráfico de dependencias parece el dibujo de mi hijo en la guardería cuando «le gustaba hacer círculos».
La depuración se convierte en una búsqueda del tesoro entre logs desincronizados en múltiples contenedores, donde tail y grep se consideran cosas de pobres. Pero en mi empresa tenemos 100 usuarios concurrentes: CIEN. Un volumen de tráfico que incluso un monolito en Visual Basic 6 gestionaría sin sudar. Hemos creado una complejidad inmensa para resolver un problema que no teníamos, solo porque «Netflix lo hace así». Tú no eres Netflix; no tienes 10.000 ingenieros. La seniority es saber decir «no» a la complejidad inútil.
Agile: de manifiesto a burocracia
"Individuos e interacciones sobre procesos y herramientas".Lenguaje del código: JavaScript (javascript)
Luego te encuentras en daily standups de 45 minutos donde nadie empieza a hablar, y cuando te toca a ti inventas una «supercazzola» (palabrería sin sentido) porque te avergüenza decir que has perdido ocho horas de vida por una codepage de la tabla de la base de datos no alineada. Hemos transformado un manifiesto de libertad en una industria de certificaciones, Scrum Master, SAFe y KPI.
La agilidad se transforma en burocracia con un vocabulario diferente. La esperanza es que la esencia del Agile resida en el equipo que se habla de verdad, protegiéndose de las «features ad personam» dictadas por gerentes que piden estimaciones basadas en la nada (o en el nombre de la propia feature). La agilidad es una actitud, no un tablero en Jira.
Gestionar la Deuda: Más allá del síndrome del TODO
"Deja el código mejor de como lo encontraste"Lenguaje del código: JSON / JSON con comentarios (json)Una regla de oro, pero que no debe convertirse en una justificación para refactorizaciones infinitas que retrasan los plazos. El Senior sabe que añadir un «if feo» no es una derrota si se hace con método. No basta con escribir un TODO que nadie leerá nunca.
Gestionar la deuda significa negociarla: se inserta el parche para respetar el plazo, se abre un ticket de refactorización y se acuerda que el «préstamo» técnico debe ser devuelto. Quizás en agosto, cuando tienes tiempo para razonar porque todos están en la playa (y tú irás en septiembre). Esta es la diferencia entre un Senior y un aficionado: el primero contrae una deuda consciente, el segundo crea un desastre involuntario.
La Metáfora del Tavernello: Scope vs Calidad
Una vez me dijeron:
"Si tienes 3 euros en el bolsillo compras un Tavernello, no un Barolo."Lenguaje del código: JSON / JSON con comentarios (json)Es una analogía poderosa. En TI, usar un producto que no cubre correctamente los requisitos puede causar problemas más grandes que los que se tendrían comprando un producto de gama alta. El verdadero compromiso no debe referirse a la calidad intrínseca (el código debe ser correcto, seguro y probado), sino al alcance (qué hacemos). Si tienes poco presupuesto, no cocines un almuerzo de bodas mediocre: prepara una excelente pasta con tomate. Simplifica los requisitos, no el cuidado con el que escribes las líneas de código.
Recuerdo un video donde Luca Mezzalira hablaba de DAZN: para cambiar el año en el pie de página de los sitios, editan a mano 4 archivos. ¿Solución sucia? Tal vez. Pero en 5 minutos está hecha, riesgo cero e impacto bajísimo. Si lo hacen los Gurús de los microservicios, tal vez no sea tan incorrecto. Ese código «feo» a menudo sobrevive años generando valor, mientras que el código «bonito» hiper-ingenierizado se reescribe después de seis meses porque nadie sabe cómo tocarlo.
Los Gurús venden libros, nosotros vendemos soluciones
Los Gurús son chefs con estrellas que compran ingredientes de primera calidad. Nosotros somos los cocineros que deben alimentar a 200 personas en una hora. Si intentas replicar la receta del Tiramisú de Iginio Massari sin tener tiempo para los bizcochos caseros, terminarás con las personas yéndose a casa molestas por la espera. Usa las galletas del supermercado y concéntrate en una crema decente.
Debemos crear soluciones basadas en la realidad. Los Gurús señalan la cima, pero somos nosotros los que debemos trazar el sendero entre las zarzas. La excelencia es proporcionar la máxima calidad posible dentro de las restricciones dadas, no quejarse de las restricciones mismas.
¿Pero entonces somos viejos o senior?
La diferencia es que el viejo ha dejado de aprender, el senior ha dejado de ser un fanático. El senior ha estudiado las reglas tan bien que sabe exactamente cuándo romperlas para salvar el proyecto, transformando esa excepción en un acto consciente de ingeniería.
Ha aprendido que «depende» es la respuesta más honesta. Que el código perfecto es enemigo del código que funciona. Que entregar el 90% a tiempo es mejor que el 100% con retraso. Y si esto significa pasar por alguien que «vive en la zona de confort» a los ojos de quien hace vibe coding con el último framework publicitado en X: me haré a la idea.
Nos vemos en la trinchera. Chapoteamos en el barro, mantenemos en pie monolitos y construimos puentes. Porque al final, la culpa no es de los Gurús que nos hicieron creer en la perfección, sino nuestra si dejamos de buscar la excelencia posible para perseguir la imaginaria.
