Preguntas frecuentes.

Encajo bien donde hay complejidad técnica real y decisiones que importan: sistemas con años de historia que necesitan evolucionar sin romperse, equipos que necesitan dirección técnica sin perder velocidad, o situaciones donde algo está fallando y hay que resolverlo con cabeza fría.

No estoy ligado a un sector concreto. He trabajado en entornos muy distintos — turismo, delivery, gestión de residuos, archivos documentales, entretenimiento — y en todos el punto de partida es el mismo: entender el negocio haciendo las preguntas correctas antes de tocar nada. Esa capacidad de involucrarme rápido y orientarme en terreno desconocido es una de las cosas que más valoro de mi forma de trabajar.

También me desenvuelvo bien bajo presión. He gestionado situaciones de crisis técnica en producción y he trabajado tanto en equipos con Scrum bien implementado como en entornos sin metodología clara, donde parte del trabajo es aportar estructura mientras el producto sigue funcionando.

En backend, Java y .NET como principales, con integración de sistemas usando Apache Camel. En bases de datos, PostgreSQL y SQL Server en producción. En frontend, React con TypeScript y Astro para sitios donde el rendimiento y el SEO importan.

Mi stack no es rígido. Me oriento rápido con tecnología nueva porque me interesa entender qué sucede por debajo, no solo cómo se usa la herramienta. Esa curiosidad por los internals es lo que hace que el aprendizaje sea real y no superficial.

El mundo de infraestructura cloud — Kubernetes, AWS, Azure, pipelines de CI/CD — es un área que estoy conociendo progresivamente. No es mi zona de dominio actual y no tiene sentido presentarlo como tal. Lo que sí tengo sólido es la capa de aplicación: arquitectura, integración de sistemas y decisiones técnicas con impacto real en el producto.

He trabajado en sectores bastante distintos: turismo y hospitalidad (booking engines, integraciones con GDS y channel managers), delivery multi-municipio, gestión de residuos, archivos documentales y entretenimiento infantil.

La diversidad no es casualidad. Lo que me resulta cómodo es entrar en un negocio desconocido, hacer las preguntas correctas y orientarme rápido en la lógica que lo mueve. Eso es lo que permite tomar decisiones técnicas que tienen sentido para el contexto real, no solo para el stack.

No busco proyectos en un sector concreto. Busco problemas con complejidad técnica real donde la arquitectura y las decisiones de diseño tengan impacto directo en el resultado del negocio.

Con mucha precaución ante la reescritura total. En la mayoría de los casos, una reescritura completa tarda el doble de lo previsto, rompe cosas que el sistema original resolvía sin que nadie lo documentó, y destruye conocimiento acumulado que estaba en el código aunque no se viera.

Mi enfoque es incremental: identificar primero los límites reales del sistema — no los que están en los diagramas, sino los que aparecen cuando algo falla — y empezar a extraer y reemplazar por partes, con cada cambio desplegado en producción antes del siguiente.

He trabajado con código legacy complejo y he llegado a un conocimiento profundo de áreas críticas en plazos cortos, incluyendo la resolución de fugas de memoria y cuellos de botella que llevaban tiempo sin identificarse. El objetivo no es llegar a una arquitectura ideal, sino mejorar la capacidad del equipo para cambiar el sistema de forma sostenida.

Más que dar respuestas, intento enseñar a hacer las preguntas correctas. La diferencia entre un desarrollador junior y uno senior no es cuántas cosas saben, sino con qué criterio evalúan las opciones.

En la práctica: code reviews donde explico el razonamiento detrás de cada decisión, no solo el qué sino el por qué; sesiones donde analizamos diseños juntos antes de implementarlos; y feedback directo pero siempre desde el respeto. Priorizo el trato humano por encima de cualquier otra cosa, y eso incluye cómo se da el feedback cuando algo no está bien.

Prefiero la mentoría en contexto de proyecto real, donde hay presiones concretas y decisiones con consecuencias. Si te interesa este tipo de acompañamiento, escríbeme y vemos si encaja.

La IA es parte de mi flujo de trabajo diario, no una novedad que pruebo puntualmente. La uso para asistencia de código (Copilot, Cursor), revisión y comprensión de código legacy, redacción de documentación técnica y, sobre todo, como interlocutor para debatir decisiones de arquitectura.

Lo que más me aporta es usarla como fuente de debate. Puedo pasarme horas haciéndole preguntas, explorando ángulos distintos de un problema o indagando en cómo funciona algo por debajo. No para que me dé la respuesta, sino para pensar mejor.

Mi postura es clara: es una herramienta de productividad que amplifica el criterio, no lo reemplaza. El criterio sobre qué construir, cómo diseñarlo y qué compromisos asumir sigue siendo una decisión humana.

El remoto no es una preferencia, es mi modo de trabajo. No es una adaptación al contexto actual, es cómo trabajo bien desde hace años: comunicación escrita clara, documentación de decisiones y reuniones con propósito concreto para que el tiempo de todos valga la pena.

El trabajo presencial tiene sentido solo cuando hay una razón de peso que lo justifica — no como norma ni como requisito de control. Estoy en Mallorca, pero si la oportunidad lo merece estoy abierto a valorar la presencialidad fuera de Baleares e incluso una reubicación a nivel internacional. Todo depende del proyecto y de que la propuesta tenga sentido real.

Actualmente estoy empleado, pero sigo abierto a conversaciones bien enfocadas. Si necesitas contraste técnico, puedes reservar directamente desde la página de disponibilidad de esta web.

He separado el proceso en dos formatos. El café virtual sirve para ponernos cara, entender el reto a grandes rasgos y ver si tiene sentido avanzar. La sesión de descubrimiento está pensada para entrar con más profundidad en cuellos de botella, arquitectura, equipo y siguientes pasos.

Donde más puedo aportar en colaboraciones puntuales es en auditorías de arquitectura, sesiones de diseño técnico, acompañamiento en fases concretas de transformación o decisiones con presión de tiempo.

Sí. Está disponible directamente en marcjoan.es/cv — puede exportarse como PDF desde el navegador con el botón de imprimir.

Si necesitas algo específico o adaptado a un proceso concreto, escríbeme directamente y lo vemos.

La forma más clara ahora mismo es pasar por la página de disponibilidad de esta web y elegir el formato de sesión que mejor encaje. Desde ahí puedes reservar directamente en Cal.com.

Si prefieres empezar por escrito, también puedes usar el email de la sección de contacto. LinkedIn sigue siendo una alternativa válida si ese canal te resulta más cómodo.

No hace falta que llegues con todo cerrado, pero sí ayuda traer contexto real sobre el problema, el equipo o el momento del producto.

Trabajo con fluidez en español, catalán e inglés — los tres en lectura, escritura y conversación. El español y el catalán son mi lengua materna. El inglés lo uso con comodidad en entornos profesionales: documentación, reuniones, comunicación con equipos y clientes internacionales.

Dado que estoy abierto a oportunidades fuera de España, incluyendo reubicación internacional, el inglés no es una limitación.

Ser el punto de conexión real entre lo que el negocio necesita y lo que el equipo puede construir de forma sostenible. No solo tomar decisiones de arquitectura, sino asegurarse de que esas decisiones se entienden, se discuten y se revisan cuando la realidad cambia.

En la práctica: me involucro en las conversaciones de producto antes de que el diseño técnico esté cerrado. Tengo experiencia como analista funcional y técnico, lo que me permite entender el problema de negocio y traducirlo a requisitos concretos sin intermediarios. Hago code reviews que explican el razonamiento, no solo señalan el error.

El componente humano es parte central de mi forma de liderar. Sé gestionar momentos de tensión con calma, y priorizo siempre el trato honesto y empático — especialmente cuando algo falla. Un buen liderazgo técnico crea equipos más autónomos con el tiempo, no más dependientes de quien lidera.

La diferencia principal está en el alcance de las decisiones y en quién vive con sus consecuencias a largo plazo, no necesariamente en la profundidad técnica.

Un senior resuelve problemas dentro de un contexto que alguien más definió. Un arquitecto define ese contexto: qué partes del sistema existen, cómo se comunican, qué compromisos se asumen y por qué. Pero para que esas decisiones sean realistas y no solo elegantes en un diagrama, el arquitecto tiene que estar suficientemente cerca del código y del negocio.

Parte de ese trabajo es funcionar como analista: entender el problema de negocio en profundidad, traducirlo a requisitos técnicos concretos y diseñar la solución sin perder el hilo de lo que el equipo puede sostener. Sin ese puente, la arquitectura queda desconectada de la realidad.

Límites claros antes que patrones elegantes. Puedes tener un monolito limpio o microservicios completamente acoplados — la diferencia está en qué tan claros son los contratos entre módulos, no en el nombre de la arquitectura que eliges.

No creo en arquitecturas de referencia que se aplican igual a todos los contextos. Creo en entender primero cuáles son los cambios que el negocio va a necesitar hacer con más frecuencia, y diseñar el sistema para que esos cambios sean baratos. Todo lo demás es optimización prematura.

El objetivo es que el sistema sea fácil de cambiar dentro de un año por el equipo que lo mantiene, no que se vea bien en el diagrama de hoy.

La curiosidad técnica es algo que tengo desde los 13 años y nunca he parado. No es una práctica que adopto para mantenerse al día, es simplemente cómo funciono.

Leo bastante — artículos técnicos, repositorios donde alguien resolvió algo que me parece interesante, release notes de herramientas que uso. Pero lo que más me enseña es entender qué sucede por debajo: no solo cómo se usa algo, sino por qué está diseñado así y qué tradeoffs implica.

Escribo en el blog sobre lo que estoy pensando y aprendiendo. Es una forma de consolidar ideas y de exponer el razonamiento a otras personas que pueden discrepar — que es cuando el aprendizaje de verdad se pone a prueba.