Cómo Trabajo
Más de tres décadas de experiencia han forjado una metodología clara: diseño orientado al propósito, arquitectura limpia y calidad sostenible. Estos son los principios que guían cada línea de código que escribo.
Por motivos de confidencialidad, no puedo compartir el código de la mayoría de mis proyectos en producción. Sin embargo, te invito a explorar mis repositorios públicos donde comparto herramientas open-source, experimentos y contribuciones a la comunidad de desarrolladores.
Ver en GitHubAntes de escribir una línea, defino qué significa el éxito (objetivo de negocio, riesgos, usuarios, métricas) y traduzco eso a lenguaje de dominio: conceptos, invariantes, procesos, excepciones y reglas. Cuando el dominio es complejo, aplico DDD para que el modelo sea una herramienta de comunicación y decisión, no un diagrama decorativo.
La UX no es "ponerlo bonito": es reducir carga cognitiva, anticipar errores, guiar decisiones, y hacer que el usuario avance con confianza. Diseño flujos, estados y estados vacíos, permisos, latencias, errores y "happy paths" con el mismo rigor que una API. La experiencia debe ser predecible, accesible y consistente en todas las pantallas.
La interfaz se construye como un sistema: componentes reutilizables, tokens, variantes, estados y composición jerárquica. Con Atomic Design mantengo orden, escalabilidad y coherencia visual/funcional (átomos → moléculas → organismos → plantillas → páginas). Esto reduce coste de cambio y evita el "spaghetti UI".
Separar responsabilidades no es dogma, es velocidad sostenible. Defino límites (dominio, aplicación, infraestructura, presentación), contratos estables y dependencias correctas. Cuando conviene, aplico arquitectura hexagonal para desacoplar el core de bases de datos, mensajería, proveedores externos y frameworks, y así poder cambiar piezas sin reescribir el sistema.
Uso principios como SOLID y patrones (Repository, Strategy, Factory, Adapter, Facade, CQRS cuando procede) para controlar complejidad real: testabilidad, extensión segura, reducción de acoplamiento, y comprensión del código. Los patrones son herramientas; el objetivo es que el sistema sea legible, predecible y fácil de evolucionar.
La seguridad no se "añade al final". La convierto en un requisito de arquitectura: autenticación, autorización, aislamiento, trazabilidad, cifrado, gestión de secretos, rate limiting, hardening y validación en límites. Me apoyo en estándares y checklists para no dejar huecos: por ejemplo, verificaciones tipo ASVS y enfoque Secure-by-Design de OWASP.
No optimizo por intuición: mido, perfilo y vuelvo a medir. Diseño pensando en rendimiento extremo cuando hace falta: caching, colas y asíncronía, paginación real, "backpressure", uso correcto de índices, minimización de payloads, y estrategias de consistencia. La meta: experiencia fluida, estabilidad y coste controlado bajo carga.
En frontend y backend, el estado se modela explícitamente (no se "esconde" en efectos laterales). Diferencio estado local frente a estado de aplicación, defino fuentes de verdad, y uso Facades para aislar frameworks y evitar que la UI conozca detalles internos. Resultado: menos bugs "fantasma", más previsibilidad, refactors más baratos.
La calidad no se negocia; se automatiza. Aplico pirámide de pruebas (unitarias, integración, e2e cuando aporta valor), contratos estables, linters, CI, y "definition of done" real. Además, incluyo observabilidad: logs útiles, métricas, trazas, correlación y alarmas. Y documento lo mínimo imprescindible, pero siempre accionable y mantenible: ADRs, diagramas, README operativos, guías de despliegue y runbooks.
Construyo en vertical: pequeñas piezas completas que llegan a producción con confianza. Trabajo con cadencia, feedback y adaptación, alineado con principios de Scrum: iteración, inspección y adaptación para controlar riesgo y maximizar valor. La arquitectura acompaña al roadmap y evoluciona sin bloquear al equipo.
Notas sobre software empresarial, agentes de IA y la práctica de ingeniería que hay detrás.
1 min de lectura
La inspección robótica recoge más datos, y más precisos, que nunca. Pero recogerlos es solo la mitad del problema. La otra mitad es convertirlos en algo sobre lo que se pueda decidir.
2 min de lectura
No suelo recomendar soluciones de software. Este caso es de los especiales: resuelve un problema de base que veo generalizado en pymes y también, lo que es más grave, en empresas realmente grandes.
3 min de lectura
"La IA nos va a quitar el trabajo." "La IA es consciente." "La AGI ya ha llegado." ¿En serio? Tras 30 años en ingeniería de software, el hype se nos está yendo de las manos.
Me encantaría conocer tu proyecto y estudiar juntos cómo puedo ayudarte a hacerlo realidad con la calidad y profesionalidad que merece.
Contactar
