Sobre mí

Trabajo con tecnología desde una posición bastante transversal.

A lo largo de mi carrera he desarrollado aplicaciones, trabajado con datos, gestionado servidores e infraestructura, diseñado integraciones, automatizado procesos y participado en la construcción y evolución de productos digitales.

No porque haya intentado acumular tecnologías o especialidades, sino porque los problemas reales rara vez respetan esas fronteras.

Cuando te haces responsable de que algo funcione de verdad, la conversación puede empezar en una aplicación y terminar en una base de datos, una API, un servidor, un proceso interno o una decisión de producto. Con el tiempo, esa forma de trabajar ha acabado definiendo bastante bien mi perfil.

Me interesa entender el problema completo, no solo la parte que encaja dentro de una etiqueta profesional.

Aprender lo necesario

Mi formación reglada fue Desarrollo de Aplicaciones Informáticas. Me dio una base importante, pero muy pronto entendí que dedicarme a tecnología implicaba seguir aprendiendo de forma permanente.

Gran parte de lo que utilizo hoy lo he aprendido después y de una manera bastante pragmática: aparece un problema, necesito comprender una tecnología o un área que hasta ese momento no dominaba, estudio, pruebo, me equivoco y termino incorporando ese conocimiento al trabajo.

Ese patrón se ha repetido durante años.

No intento conocer todo de antemano. Prefiero aprender a partir de un problema concreto, incorporar lo necesario y asumir la responsabilidad de que ese conocimiento funcione en condiciones reales.

Hace años, en una entrevista de trabajo, me preguntaron dónde estaba mi límite. Respondí que, obviamente, no podía garantizar que fuera capaz de realizar cualquier encargo porque desconocía de antemano su alcance, pero que hasta aquel momento había terminado resolviendo todos los retos que se me habían presentado en mi profesión.

Con el tiempo añadiría un matiz: casi todos ellos me han obligado a aprender algo que no sabía cuando empecé.

De desarrollar software a hacerse responsable del sistema

Una parte importante de mi trayectoria profesional ha estado ligada al desarrollo de software y, especialmente, a sistemas en los que el software convive con datos, infraestructura y procesos reales.

Trabajar con soluciones GIS y datos geoespaciales me llevó a profundizar en aplicaciones web, bases de datos espaciales, servicios, procesamiento de información, automatización, rendimiento y producción. En ese tipo de sistemas, que una funcionalidad esté bien programada es solo una parte del problema: también tiene que manejar datos reales, integrarse con otros componentes, mantenerse estable y seguir funcionando cuando algo falla.

Con CodeStack Solutions esa responsabilidad se amplió todavía más.

El trabajo dejó de estar delimitado únicamente por el desarrollo. Servidores, infraestructura, integraciones, certificados, servicios internos, soporte, incidencias o decisiones técnicas empezaron a formar parte del mismo contexto. En una empresa pequeña no siempre existe un especialista diferente para cada capa, y muchas veces lo importante es ser capaz de entender cómo se relacionan todas ellas y decidir dónde merece la pena intervenir.

Tecnología que convive con empresas y productos reales

Algunos proyectos me han llevado especialmente hacia la integración y la automatización.

En uno de los proyectos profesionales en los que trabajo, por ejemplo, buena parte del reto consiste en hacer evolucionar una operativa que ya existe: conectar sistemas, automatizar procesos que antes eran manuales y añadir nuevas capacidades sin interrumpir el trabajo diario.

Eso obliga a pensar de una forma distinta a cuando se construye algo desde cero. La solución técnicamente más elegante no siempre es la mejor si ignora las herramientas existentes, a las personas que las utilizan o las restricciones del negocio.

TorrijosToday me ha enseñado otra cara del mismo problema. Allí tecnología, contenido, SEO, analítica, publicidad, automatización y operación diaria forman parte de un único producto. No tiene demasiado sentido optimizar una de esas piezas sin entender qué ocurre con las demás.

Y en Chuletas de Inglés esa visión se amplía de nuevo. Estoy trabajando en un producto educativo donde desarrollo, arquitectura, experiencia de usuario, contenido y modelo de aprendizaje tienen que evolucionar juntos. Es probablemente uno de los ejemplos más claros de cómo entiendo actualmente el trabajo tecnológico: no como una sucesión de capas independientes, sino como un sistema.

Son proyectos muy diferentes entre sí, y precisamente por eso me interesan. El hilo que los conecta no es una tecnología concreta. Es la necesidad de entender un contexto, tomar decisiones y construir una solución que pueda vivir dentro de él.

El criterio importa tanto como la herramienta

Con los años me interesa cada vez menos empezar una conversación preguntando qué tecnología vamos a utilizar.

Prefiero empezar por qué problema estamos intentando resolver, qué restricciones tenemos y qué coste introduce cada decisión.

A veces la respuesta es construir algo nuevo. Otras veces es integrar mejor lo que ya existe. Automatizar una tarea. Simplificar un proceso. No instalar una herramienta. Mantener una tecnología menos moderna porque sigue siendo la opción sensata. O detener un experimento cuando deja de aportar información.

Me gustan las herramientas nuevas y sigo dedicando bastante tiempo a aprenderlas, pero intento no confundir novedad con utilidad.

Por eso también me parece importante documentar los errores, los cambios de criterio y las cosas que finalmente decido no utilizar. Una decisión técnica solo resulta interesante de verdad cuando se entiende qué problema intentaba resolver y qué alternativas se dejaron fuera.

Lo que estoy explorando ahora

En los últimos años la IA, la automatización y, más recientemente, los agentes han empezado a ocupar una parte creciente de mi trabajo y de mi aprendizaje.

Me interesa especialmente qué ocurre cuando dejamos de tratar la IA como una aplicación aislada y empezamos a incorporarla a herramientas, procesos de desarrollo y sistemas reales.

Para explorar ese territorio he creado un laboratorio personal en el que monto entornos, pruebo herramientas, comparo modelos, construyo pequeños experimentos y documento las decisiones que voy tomando.

No pretende ser un banco de pruebas infinito ni una colección de benchmarks.

Su función es mucho más práctica: poder construir y probar algo antes de formarme una opinión sobre ello o decidir si merece incorporarse a un proyecto real.

Algunas pruebas terminan en una herramienta útil. Otras demuestran que una idea no merece seguir adelante. Las dos cosas me parecen buenos resultados.

Esta web nace también de ahí.

Es el lugar donde quiero reunir proyectos, experimentos y artículos para explicar no solo qué construyo, sino también por qué tomo determinadas decisiones, qué salió mal y qué aprendí durante el proceso.

Trabajo profesional

Parte de mi actividad profesional la desarrollo a través de CodeStack Solutions, donde trabajo en desarrollo, integración, automatización, sistemas y proyectos tecnológicos para empresas.

En esta web prefiero centrarme en cómo pienso, qué construyo y qué aprendo. Para la trayectoria profesional completa está LinkedIn; para código, repositorios y material reproducible, GitHub; y para proyectos y servicios orientados a empresas, CodeStack Solutions.