Sin tanto código que nos separe

Por casi dos años estuve realizando mantenimiento a una página personal que, en un primer momento, o al menos así fue pensado, debería haber sido un espacio en el que pudiera escribir con total facilidad: comentar rápidamente el tema que estuviera ocupando espacio en mi cabeza, durante el momento del día que fuera y en el lugar en el que me encontrase. Pero no fue así.

El viejo sitio comenzó con una idea honesta: hacer una página personal, simple, liviana y accesible. Pero tenía un problema en las bases. En ese entonces creía que el sitio de un “Desarrollador de Software” tenía que ser un sitio creado desde cero. Tiene sentido. Un programador sabe construir sitios; pasa horas construyendo para los demás, otras horas probando que todo funcione y más horas corrigiendo detalles de rendimiento; entonces, pensé en aquel entonces, el sitio que construyera debería ser la evidencia de mi destreza y conocimiento. Y así, empecé en el verano de 2024 a construir el viejo sitio, y lo terminé en el verano de 2025.

¿Por qué me llevó esa cantidad innecesaria de tiempo? Porque para que sea simple, lo construí en React y, para que me permitiera acceder desde cualquier lado, desarrollé el panel de administración en ASP.NET. Es decir, construí dos sitios, el que todos verían y el que solamente vería yo cada vez que quisiera escribir algo.

El sitio en React quedó bien, era limpio y escalable. Me preocupé por “componizar”, pensando que en algún punto me podría cansar del diseño y tener todo en orden me ayudaría a diseñar un nuevo espacio sin empezar desde cero. Para el diseño me “inspiré” en, Takuya Matsuyama, un programador que admiro por su sencillez y filosofía. El panel de administración en .NET fue una pesadilla. Tengo que admitir que soy una de esas personas que inician todo lo que hacen con una idea clara y, ¿por qué no?, realista, pero que a medida que avanzan en el proyecto les invaden las preguntas del tipo: “¿Y si un día quiero escribir, pero no publicarlo? Debería tener una manera de almacenar borradores.”, “¿Y si un día quiero crear una sección nueva? Debería tener una manera de que la nueva sección aparezca en la barra de navegación.”, “¿Y si un día quiero cambiar el orden de cómo se distribuye todo en el ‘home’? Debería tener un Layout que me permita establecer un orden de las secciones”. Intento abordar problemas que aún no existen, escenarios que quizá nunca ocurran y, a toda costa busco, ingenuamente, evitar tener que volver a tocar código alguna vez. Erróneamente confundo la intención de diseñar bien una solución (soluciones actuales, para problemas actuales) con la idea de que si surge una nueva necesidad, la solución original debería poder resolverla.

Los sitios y aplicaciones crecen. Surgen nuevas ideas y necesidades. Requieren cambios y mantenimiento. Es parte del trabajo. Y luego de dos años de mantener ese espacio, me pesaba tener que trabajar en un sitio que se suponía debía ser más simple.

Acá estamos hoy, a inicios del año 2026, con un sitio nuevo construido con Jekyll, usando Github como base de datos y customizado para que el diseño no compita con el contenido. Este sitio no tiene “componentes” ni “servicios”, pero se siente más honesto, más hogareño. Sin tantas líneas de código que separen el texto que en este momento escribo con quienes lo quieran leer. Escribo en Neovim, guardo archivos en Markdown, aplico los cambios y el texto se publica. ¡Eso es todo! Es algo que puedo hacer en mi computadora de escritorio o desde mi notebook mientras espero en el auto; incluso sin internet (excepto la parte de aplicar los cambios) y en cualquier momento del día.

No quiero que este texto sea mucho más largo. Concluyo diciendo que el sitio aún está con una personalidad en construcción. No es un “porfolio” en su totalidad (aunque un poco sí) y tampoco es un sitio para aprender a programar (aunque un poco sí). Es lo que soy, muestro lo que hago y comparto lo que me apasiona.