Notas de un desarrollador.
Hola. Este blog es mi forma de documentar el camino que he recorrido: código, arquitectura, decisiones técnicas y algún que otro error del que salí más sabio de lo esperado. Lo escribo tanto para no olvidar lo aprendido, como para ahorrarte a ti parte del camino. Pero antes de entrar en materia, un poco de contexto sobre quién escribe esto.
Sobre Mí
Soy Consultor Tecnológico Senior en el sector financiero. Empecé mi carrera en ingeniería de campo, y hace más de 9 años di el salto al software — un salto del que nunca me arrepentí. En el camino me fui enamorando del desarrollo full-stack, moviéndome con soltura entre Angular en el frontend y Java con Spring Boot en el backend. Tuve mis primeras — y acaloradas — discusiones internas sobre cómo diseñar microservicios bien hechos, lo que terminó llevándome a apostarle a principios como DDD, SOLID y arquitectura hexagonal, no como teoría de libro, sino como la forma más honesta que encontré de escribir código que otros pudieran entender después. Y aprendí, muchas veces a la fuerza, a moverme en la nube con AWS: desplegando en EKS, orquestando con ECR y RDS, y armando pipelines de CI/CD en Azure DevOps que probaran de verdad lo que decían probar, no solo en papel. Justamente por eso empecé a escribir: para no dejar que estas lecciones se quedaran solo en mi cabeza.
El Blog
Este es el lugar donde vuelco todo eso. Aquí no vas a encontrar otro tutorial básico de "cómo instalar Spring Boot en cinco minutos" — es el registro honesto de alguien que trabaja en esto de verdad, con toda la incertidumbre que eso implica. Escribo sobre arquitectura de software y los patrones que uso (o descarto) según el problema real que tenga enfrente. Escribo sobre Java y Spring Boot, desde lo elemental hasta los rincones más complicados que solo se entienden a punta de errores. Escribo sobre DevOps sin filtro — Docker, Kubernetes, automatización — y sobre cómo se ve AWS cuando dejas la teoría y lo llevas a producción. Y escribo, también, sobre seguridad y rendimiento, porque esas son las decisiones que uno solo aprende a valorar cuando algo falla a las tres de la mañana. Y como todo lo que se aprende trabajando, tarde o temprano se traduce en algo concreto.
Proyectos
A lo largo de mi carrera he tenido la fortuna de construir cosas de las que me siento orgulloso: sistemas que hoy corren en producción, soluciones que resolvieron problemas reales y herramientas que usaron personas reales, no solo casos de estudio. Ahí está el portal financiero que sigue funcionando en producción, construido con Angular, Spring Boot y AWS sobre una malla de servicios con Istio, integrado con redes de pago internacionales como Amex, Visa y Mastercard. Ahí está también el micro-framework interno que terminamos usando todo el equipo, y que redujo el tiempo de desarrollo en un 40% — una de esas mejoras que uno construye pensando en los demás y termina beneficiándose él mismo. Diseñé de principio a fin un sistema de parqueaderos con hardware propio, hoy operando en más de 10 ubicaciones, y una plataforma de telemetría industrial con Grafana, InfluxDB y Node-RED, hablando MQTT y Modbus con máquinas que no perdonan errores. Y de fondo, ese mismo software propietario terminó desplegado en más de 20 proyectos de distintos clientes, cada uno con sus propias reglas del juego. De esos aciertos — y de los tropiezos que los acompañaron — nació también una forma particular de trabajar.
Mi Forma de Trabajar
Creo que el buen software no es el que funciona hoy, sino el que alguien más puede entender, mantener y mejorar mañana. Por eso el código limpio, SOLID y la arquitectura hexagonal no son para mí una moda pasajera, sino la base sobre la que construyo todo lo demás. Le doy el mismo peso a la documentación — no la que se llena por cumplir, sino la que de verdad alguien lee cuando la necesita — y a las pruebas que realmente prueban algo: unitarias, E2E y de performance, integradas al pipeline desde el primer día, no agregadas al final como una idea tardía. Trabajo con metodologías ágiles, pero con el foco puesto en el valor que se entrega, no en la ceremonia por la ceremonia. No los veo como rituales obligatorios; los veo como lo que realmente marca la diferencia cuando las cosas se ponen difíciles.