Arquitectura

Yo construyo.

Llevo 20 años escribiendo código. No porque alguien me haya dicho que era una buena carrera, no porque hubiera un plan, sino porque a los 10 años abrí una terminal por primera vez y entendí algo que cambió todo: el mundo es editable.

Cada sistema que existe — cada app, cada plataforma, cada herramienta que usás sin pensar — empezó como una pantalla en negro con un cursor parpadeando. Alguien se sentó, pensó la arquitectura, y escribió la primera línea. Y después la segunda. Y después la milésima. Hasta que lo que no existía, existió.

Eso es ingeniería. No es magia. Es disciplina con visión.

Mi setup tiene tres monitores, un portátil abierto al lado, un teclado mecánico que suena como lluvia sobre techo de zinc, y un café que se enfría porque siempre se me olvida tomarlo. Desde acá construyo.

Pero el setup real no es lo que ves en la foto.

El setup real es el sistema completo: la rutina de las 6 AM, el desayuno a las 8, las clases de los niños a las 9, el bloque de deep work de 10 a 1, el almuerzo juntos, la tarde de tareas y actividades, la cena, los libros antes de dormir. Eso es arquitectura. Los monitores son solo la interfaz visible de un sistema que corre 24/7 en el background.

Un buen ingeniero sabe que la UI es lo de menos. Lo que importa es el backend. La lógica. La estructura de datos. Lo que nadie ve pero que sostiene todo.

La ingeniería me enseñó algo que aplico a todo: los sistemas bien diseñados corren solos.

No necesitan que alguien los esté revisando cada 5 minutos. No necesitan intervención manual constante. No necesitan que les metas mano cada vez que te da ansiedad. Un sistema bien hecho tiene sus reglas, sus validaciones, sus tests — y corre. Estable. Silencioso. Confiable.

Cuando algo se rompe, un buen ingeniero no grita. No culpa al hardware. No le echa la culpa a la versión anterior. Se sienta, lee los logs, encuentra el bug, y lo arregla. Sin drama. Sin público. Sin necesidad de que nadie lo vea hacerlo.

El drama es un bug, no un feature.

Hay una diferencia fundamental entre arquitectura y decoración. La arquitectura es estructura — cimientos, columnas, distribución de carga. La decoración es lo que ponés encima para que se vea bonito.

Podés decorar una casa sin cimientos. Se va a ver bien en la foto. Pero el primer temblor la tumba.

Yo prefiero construir los cimientos primero. Aunque nadie los vea. Aunque no salgan en ninguna foto. Aunque no sean glamorosos. Porque cuando el temblor llega — y siempre llega — lo que tenés que mostrar no es la decoración. Es si la estructura aguantó o no.

La mía aguantó.

En ingeniería de software hay un concepto que se llama refactoring: tomar código que funciona pero que está desordenado, y reorganizarlo sin cambiar lo que hace. Mismo resultado, mejor estructura. Más limpio. Más mantenible. Más elegante.

Los últimos meses de mi vida han sido un refactoring masivo. Misma persona, mismos valores, mismos hijos, mismo trabajo. Pero reorganizado. Más limpio. Sin dependencias innecesarias. Sin módulos que no aportan nada y consumen recursos. Sin código legacy que solo está ahí porque "siempre estuvo."

A veces el refactoring más importante es eliminar lo que sobra.

Un ingeniero sénior se reconoce no por la cantidad de código que escribe, sino por la cantidad de código que no escribe. Por lo que decide no incluir. Por las features que descarta porque añaden complejidad sin valor. Por los atajos que rechaza porque sabe que la deuda técnica se paga con intereses.

Aplico lo mismo en casa. No todo lo que se puede hacer se debe hacer. No toda batalla merece pelea. No toda provocación merece respuesta. A veces la decisión más poderosa es no hacer nada y dejar que el sistema haga su trabajo.

Los que no entienden ingeniería confunden inacción con debilidad. Pero el ingeniero sabe: si el sistema está bien diseñado, tu trabajo es monitorear, no intervenir. Intervenir sin necesidad es el error más caro que existe.

Mis hijos me ven trabajar todos los días. Ven las pantallas, el código, las videollamadas en inglés. Ven que su papá se sienta a las 6 de la mañana y construye cosas que no existían antes del desayuno. Y ven que después del trabajo, el mismo tipo que estaba debuggeando un microservicio se sienta con ellos a revisar fracciones o a leer un libro.

No les estoy enseñando programación. Les estoy enseñando la mentalidad de quien construye. Que los problemas tienen solución. Que las soluciones requieren paciencia. Que la paciencia produce resultados. Que los resultados hablan solos.

Uno construye, el otro dibuja todo lo que imagina, y yo estoy a dos pasos. Tres personas en silencio, cada una en lo suyo, compartiendo el mismo espacio. Sin necesidad de decir nada.

Los mejores sistemas corren en silencio.

Si estás leyendo esto y querés empezar a construir algo — lo que sea: una carrera, un proyecto, un hogar, una versión nueva de vos mismo — mi único consejo es este:

No le expliqués a nadie lo que estás haciendo. Hacelo.

El código compila o no compila. El deploy funciona o no funciona. El test pasa o no pasa. No hay argumentos. No hay interpretaciones. No hay narrativas. Solo resultados.

Y los resultados no necesitan abogado.

Build. Deploy. Repeat.

Atentamente.