Rubén Zamora

Software Crafter

Sobre mí

Soy un friki de la tecnología desde que tengo memoria. De pequeño me fascinaban los ordenadores y construir cosas, lo que me llevó a estudiar mecatrónica y robótica. El problema del mundo maker es que la infraestructura cuesta dinero: si quieres construir algo físico, necesitas materiales, herramientas, espacio. La informática me abrió otra puerta: puedes crear y destruir proyectos a coste casi cero, y el límite está en la imaginación. Eso fue lo que terminó de engancharme (y sigue siendo lo que más me gusta del trabajo) automatizar algo que antes hacía alguien a mano tiene impacto real, aunque nadie se dé cuenta de quién lo hizo.

Esa obsesión por automatizar y facilitar el día a día no se queda en el trabajo. En casa tengo bastantes cosas domotizadas, sigo de cerca el mundo blockchain —creo en el potencial de la tokenización para que más personas puedan participar en proyectos en los que antes no llegaban— y siempre tengo algún proyecto personal cocinándose en segundo plano.

En Lean Mind desde 2020, con base en Tenerife. Se me da mejor organizar al equipo que organizarme a mí mismo, y llevo años trabajando con sistemas en producción que nadie quiere tocar. Ese tipo de reto, más que cualquier proyecto nuevo desde cero, es donde creo que puedo aportar más.

¿En qué puedo ayudarte?

Trabajo acompañando a equipos y organizaciones en:

Desarrollo de software con foco en calidad, mantenibilidad y sostenibilidad
Trabajo con código legado: caracterización, refactorización y evolución controlada
Mejora de prácticas de desarrollo (TDD, BDD, XP, testing, clean code)
Observabilidad: porque un sistema que no puedes medir es un sistema que no puedes mejorar con confianza
Acompañamiento técnico y mentoring de equipos
Integración de IA en el ciclo de desarrollo (AI-assisted & AI-driven development)
Dinámicas de equipo y team building técnico
Automatización de procesos y productividad: si algo se puede automatizar, merece la pena hablarlo

Y si en algún momento quieres debatir sobre domótica, blockchain, inteligencia artificial o por qué la mecatrónica te acaba llevando a la programación, también estoy disponible para eso.

Desarrollo de software con IA

Es uno de los focos en los que más estoy invirtiendo ahora mismo. Mi interés no está tanto en las herramientas en sí como en usarlas con cabeza: preparar bien el contexto que se le da al modelo para que las respuestas sean útiles, saber qué modelo encaja mejor con cada tipo de tarea, delegar en agentes las partes adecuadas sin perder el hilo de lo que está pasando, y no malgastar recursos donde no hace falta.

También me preocupa el lado humano de todo esto:

Cómo mantener las prácticas de calidad (TDD, diseño, revisión de código) cuando la IA entra en el flujo
Qué problemas resuelve realmente y cuáles sigue sin resolver
Cómo evitar que el equipo pierda comprensión de su propio sistema por delegar demasiado

El objetivo es que la IA amplíe lo que el equipo puede hacer, no que lo sustituya sin que nadie se dé cuenta.

Una combinación que encuentro especialmente relevante ahora mismo es la de IA aplicada a código legado. Las empresas no están tirando sus sistemas heredados, están intentando modernizarlos más rápido. Usar IA para entender un sistema legacy, generar tests de caracterización o acelerar el análisis de dependencias puede ahorrar semanas, pero requiere a alguien que entienda los dos lados: cómo funciona el legado y cómo guiar a la IA para que no genere más deuda técnica de la que ya hay.

También hay un ángulo de negocio que pocas veces se habla: el coste. Las empresas están invirtiendo en APIs de modelos sin mucho criterio, y eso se nota en las facturas. Elegir el modelo adecuado para cada tarea, estructurar bien el contexto para no desperdiciar recursos y delegar en agentes de forma eficiente no es solo una decisión técnica, también es una decisión económica. Tener ese criterio marca la diferencia entre usar IA de forma sostenible o quemarse el presupuesto sin saber muy bien por qué.

Trabajo con código legado

Gran parte de mi trayectoria ha transcurrido en sistemas que llevan años en producción. He aprendido que estos sistemas suelen tener más valor del que aparentan, y que la clave no es reescribirlos sino entenderlos bien antes de moverlos.

Lo que más valoro de este trabajo es poder acompañar al equipo en ese proceso: ganar confianza en el código existente, introducir pruebas donde antes no había y avanzar en pequeños pasos seguros en lugar de grandes cambios que generan incertidumbre.

En Holaluz, trabajamos junto al equipo extrayendo la lógica de recaudación de un ERP legacy. El proceso nos permitió dar visibilidad por primera vez a algo que estaba completamente enterrado y, en menos de dos meses, el negocio pudo actuar sobre esa información de forma efectiva.

Experiencia

En Lean Mind he trabajado en sectores y contextos bastante distintos entre sí:

Eventim (2026 – actualidad)

Proyecto actual. Trabajando en desarrollo de software para uno de los principales distribuidores de entradas de Europa, con Java sobre AWS.

Wolters Kluwer (2023 – 2025)

Más de dos años en uno de los mayores proveedores de software legal y fiscal del mundo. Trabajo en el equipo CORE con foco en calidad técnica y evolución de sistemas, principalmente con .NET y Azure.

Holaluz (2020 – 2023)

Casi tres años en la comercializadora de energía verde. Trabajo con sistemas PHP y Java sobre AWS en un entorno con múltiples equipos. Fue un proyecto donde aprendí mucho sobre observabilidad, coordinación en equipos grandes y cómo evolucionar sistemas complejos sin detener la entrega.

Cómo trabajo

Intento crear en los equipos con los que colaboro un entorno donde:

La calidad del código no sea una aspiración sino una práctica habitual
Las personas tengan autonomía para tomar decisiones técnicas
El aprendizaje continuo sea parte del día a día, no un extra
Las decisiones técnicas estén conectadas con el negocio

Utilizo BDD para definir los tickets de trabajo: antes de escribir código, me gusta que el equipo tenga claro el comportamiento esperado del sistema en lenguaje compartido. Es una forma de reducir malentendidos entre el negocio y el desarrollo, y de asegurarse de que lo que se construye es realmente lo que se necesitaba.

Con eso claro, practico TDD como herramienta de diseño, no como fin en sí mismo. Me apoyo en integración continua, refactorización constante y en avanzar en pasos pequeños y seguros.

Le doy mucha importancia a la observabilidad, y no solo porque quede bien decirlo. En sistemas distribuidos, sin trazabilidad no sabes qué está fallando ni dónde. En sistemas legacy, es muchas veces lo primero que hay que construir antes de poder tocar nada con seguridad. Un dashboard bien pensado puede ahorrarte días de debugging a ciegas. Complemento eso con pruebas de carga y estrés con K6 o Gatling: saber cómo se comporta un sistema cuando la cosa se pone seria es tan importante como saber que funciona en condiciones normales.

También le dedico tiempo a conocer bien mis herramientas. Con los IDEs de JetBrains intento ir más allá del uso básico: multicursor, live templates, el cliente HTTP integrado como sustituto de Postman para tener la documentación de la API centralizada en el propio proyecto, análisis de cobertura, gestión de Git desde el IDE... Lo mismo con la terminal: tener la shell bien configurada, con alias, funciones y prompts que te den información útil de un vistazo marca más la diferencia de lo que parece. La idea de fondo es la misma que en todo lo demás: si una herramienta existe para ayudarte, merece la pena aprender a usarla de verdad.

Más allá del código

Participo en la comunidad tecnológica siempre que puedo, en eventos como AdaLoveDev y Codemotion. Me gusta tanto aprender de otras personas como compartir lo que he ido descubriendo por el camino.

El team building técnico es algo que me tomo en serio: cómo hacer que un equipo funcione de verdad, más allá de los procesos en papel. He facilitado dinámicas de equipo y acompañado a personas con menos experiencia.

También sigo de cerca la ciberseguridad, especialmente desde que las herramientas de IA están reduciendo la barrera de entrada para crear exploits. Me preocupa cómo el vibe coding está acelerando eso, y prefiero entender lo que está pasando antes de que llegue a convertirse en un problema en los proyectos en los que trabajo.

Tecnologías

Mis puntos fuertes:

Java (Spring Boot), .NET (C#)
SQL y bases de datos relacionales
Docker, AWS, Azure

Con soltura también:

TypeScript, JavaScript, Node.js
PHP (Symfony)
React

Herramientas transversales:

Observabilidad: Grafana, ELK, Datadog
Pruebas de carga y estrés: K6, Gatling
IDEs JetBrains (IntelliJ, Rider...)