La parte lenta del sistema

Uso la IA de forma intensiva en mi día a día como ingeniero. Es capaz de analizar problemas muy rápido, proponer soluciones y escribir código en minutos que a mí me habría llevado bastante más tiempo.

Pero hay algo que no ha cambiado. El responsable del resultado sigo siendo yo. Y eso introduce una sensación nueva: ahora soy la parte lenta del sistema.

La IA genera en minutos. Pero entender, revisar y decidir sigue llevando tiempo. Mi tiempo.

Y ahí aparece una tentación sutil. Leer algo, que parezca razonable… y seguir. No porque no me importe la calidad, sino porque revisar bien cuesta. Y porque si me paro demasiado, siento que pierdo esa ventaja de ir más rápido.

Y vuelve el eterno debate interior. La sensación de que podría hacer más cosas a la vez. Si un agente puede avanzar solo, ¿por qué no lanzar varios? ¿por qué no paralelizar más tareas? Pero en mi caso, al menos en desarrollo y análisis, eso tiene un límite claro.

El cambio de contexto sigue siendo caro. Mi atención sigue siendo finita. Y llevar varias cosas en paralelo no siempre es avanzar más rápido, aunque lo parezca.

Hay algo curioso en todo esto. Durante años he aprendido que no se puede ir al 100% todo el rato. Que la multitarea degrada la calidad. Que pensar bien lleva tiempo.

Con la IA, muchas de esas ideas vuelven a ponerse a prueba. No porque hayan dejado de ser ciertas, sino porque ahora es más fácil saltárselas.

Cada vez tengo más claro que la IA no me hace más rápido a mí. Hace más rápida la parte del trabajo que no soy yo. Igual que un tractor permite labrar más rápido que una azada, pero no cambia quién decide por dónde ir, qué sembrar o cuándo parar.

Así que una parte importante de mi trabajo ahora es otra. Gestionar el ritmo. Saber cuándo acelerar… y cuándo frenar. No dejarme arrastrar por la velocidad de la herramienta. Seguir dedicando el tiempo necesario a entender lo que se está construyendo, a revisar con criterio y a asumir la responsabilidad del resultado.

Porque la velocidad ha cambiado.

Pero el criterio sigue siendo el cuello de botella.

Cómo afrontar el 2026 con equilibrio y propósito

Estos días he terminado de decidir cómo voy a afrontar este 2026, y no va a ser un año de cambios de paradigma ni de giros espectaculares. Va a ser un año en el que pensaré y mediré muy bien cada paso que dé.

No porque las cosas vayan mal —al contrario, muchas van muy bien— sino porque estoy en una etapa especialmente densa, con muchos frentes importantes abiertos al mismo tiempo.

Quiero estar presente para Irene y cuidar la relación sin darla por hecha ni descuidarla ni un momento.
Quiero estar cerca de Mauro y acompañarlo, pues con sus dos años está en una etapa intensa y fundamental.
Quiero seguir creciendo profesionalmente, hacer bien mi trabajo, aportar y sentirme alineado con lo que hago.
Quiero seguir construyendo hogar, poco a poco, sin vivir la casa como un proyecto infinito que nunca se cierra.
Quiero estar presente para mi familia, para mis amigos, para la gente que quiero.
Quiero cuidarme, moverme, dormir mejor y no perderme a mí mismo en el proceso.

Todo eso me importa de verdad.
Y precisamente por eso, no todo puede ir a máxima prioridad al mismo tiempo.

Durante los últimos años he hecho bastante trabajo consciente: elegir bien las batallas, enfocarme en lo importante, ajustar rutinas, crear hábitos razonables, reducir ruido, renunciar a cosas que me gustaban y aceptar cierto desorden. No vivo en piloto automático ni desde la inconsciencia.

Y siendo honesto conmigo mismo, creo que mi sistema actual está bastante afinado para la etapa vital en la que estoy. Habrá pequeñas mejoras, seguro, pero el retorno de seguir apretando ahí es cada vez menor.

Lo que empiezo a entender —y no siempre es cómodo— es que hay momentos en la vida en los que simplemente hay demasiadas cosas importantes ocurriendo a la vez. No caprichos. No ruido. Cosas reales, elegidas y valiosas.

Y en esos momentos, aunque hago lo mejor que puedo, no llego a todo como me gustaría. No al nivel ideal que mi cabeza, mi exigencia o mi identidad me piden. Y eso no significa que esté fallando. Significa que estoy en una etapa intensa.

Quizá 2026 no vaya de crecer más, hacer más u optimizar más. Quizá vaya de dejar de pelearme con los límites de esta etapa. De vivirla con un poco más de amabilidad interna. De no convertirme en mi juez constante.

De hacer lo mejor que pueda con el ancho de banda que tenga… y permitirme que eso sea suficiente.

Seis años en Cabify: de la plataforma al producto

Hoy cumplo seis años en Cabify.
Y aunque el tiempo ha pasado volando, la sensación es que cada etapa ha sido una escuela distinta.

Durante los últimos años he formado parte de Middleware, un equipo de plataforma centrado en crear tecnología para que otros equipos puedan avanzar más rápido. Allí aprendí a pensar en términos de infraestructura, calidad y escalabilidad; a resolver problemas complejos que no siempre se ven, pero que sostienen todo lo demás.

Hace poco he cambiado de rumbo y me he unido al equipo de Own Fleet, un entorno más cercano al producto, donde las decisiones impactan directamente a las personas que usan la tecnología.
Este movimiento me está permitiendo aplicar todo lo aprendido en la plataforma a un contexto muy diferente, donde la incertidumbre es alta y casi todo está por construir.

Valoro especialmente que Cabify fomente este tipo de movimientos internos. Pasar de un equipo maduro, con procesos bien asentados, a uno de reciente creación —más parecido a una start-up dentro de la compañía— es una oportunidad de crecimiento enorme.

Seis años después, sigo aprendiendo cada día.
Y aunque el contexto cambia, hay algo que se mantiene constante: la sensación de formar parte de un proyecto con propósito, rodeado de personas brillantes y cercanas.

Maze Adventure v0.7.8 — Music, Patrollers… and a Collector’s Edition?!

After a short break, Maze Adventure is back with a juicy new version: v0.7.8. And this one doesn’t just bring gameplay changes — it comes wrapped in a retro-styled box, backed by a fictional publisher, and launched with its own 1980s-style commercial. Yes, really.

Let’s unpack it all 👇

🕹️ What’s new in v0.7.8

Gameplay-wise, this version lays a few strong foundations for what’s coming next. Here’s what’s new:

🎵 Background music finally arrives! A looping chiptune track now plays during gameplay. It’s the first time I’ve recorded the game with music.
👻 Patroller NPCs have been added — moving enemies that damage you on collision. They bring life and danger to the maze.
🧭 A level selection screen now exists, mainly for easier debugging (and for people who want to skip around).
🧠 Maze generation has improved with multi-path layouts, making each level more strategic and replayable.
📦 And perhaps most exciting for me: automatic multiplatform builds via GitHub Actions, providing downloadable binaries for:
- Linux (amd64)
- macOS (arm64)
- Windows (amd64)

🧪 I’ve tested the binaries on macOS and Windows — both work fine. I haven’t tested Linux yet 😅, but feel free to report any issues.

📦 The (fake) Collector’s Edition

To celebrate this release, I let myself go full nostalgic — and ended up designing a fictional box art for Maze Adventure, as if it were a 1980s video game.

🖼️ Here’s the box cover (yes, it’s ridiculous, and I love it):

It features:

A mysterious astronaut exploring a colorful maze
A label by the legendary (and entirely made-up) publisher Maurotron
My childhood dream fulfilled: “Designed by Juanan Cid”

📺 The TV Ad (yes, really)

To complete the time-travel experience, I created an 8-second TV commercial, inspired by the fast-paced, hype-heavy ads from the 80s and 90s.

It has nothing to do with the actual game.
It’s just pure joy.

🎥 Watch the ad here →

🎬 And the real gameplay?

Of course. This is the actual gameplay update (v0.7.8) and what the game really looks and sounds like now:

▶️ Devlog 7 — Watch Maze Adventure with Music for the First Time:

💾 Download the game

You can find precompiled binaries for all major platforms (macOS arm64, Windows amd64, Linux amd64) on the GitHub Releases page.

If you’re on another architecture or OS and want a build — just open an issue or ping me on X.

🔧 Behind the scenes

This version took a surprising amount of effort — not just because of the features, but because of all the invisible pieces:

Setting up GitHub Actions to build, test, and publish binaries per platform
Fixing weird cross-platform bugs (especially Linux builds, which required a deep dive into libasound and X11)
Finding the right balance between nostalgia and nonsense for the fake assets 😄

But hey — now Maze Adventure has:

Platform-specific binaries
A (fake) cover
A (fake) TV ad
And real momentum for future updates

💬 Final thoughts

This project started as a fun playground to explore game development with Ebitengine and Go — and it still is. But somehow, it’s starting to feel like a real game.

If you’re enjoying the journey, follow me on X @juanancid — I post updates, screenshots, devlogs, and occasional nonsense there.

Thanks for playing — see you in the maze.

— Juanan

Trabajar en remoto con un bebé en casa

Hace poco, Mauro cumplió un año y medio. Y un amigo me preguntó qué tal llevaba eso de trabajar en remoto con un bebé (o un no-tan-bebé) en casa.
Le respondí lo más sinceramente que pude:

Es más difícil que antes, pero también más maravilloso que nunca.

Con un bebé en casa, todo es más difícil.
Mi vida profesional.
Mi vida sentimental.
Mi vida personal.
Todo.

A veces lo oigo llorar al otro lado de la puerta, o reírse, o jugar… y no estoy ahí.
A veces tengo que salir corriendo porque hay una emergencia.
A veces simplemente me cuesta estar presente mentalmente porque sé que, muy cerca de mí, hay alguien que me necesita. O está golpeándolo todo.

Y sí, trabajar desde casa también se hace más cuesta arriba en esos momentos.

Pero también hay otra cara

También es cierto que, gracias al trabajo en remoto, he podido estar más cerca de mi hijo que nunca.

Puedo empezar a trabajar temprano y parar un rato cuando él se despierta, sin que eso suponga un drama organizativo.
Puedo acabar a las 17:30 y, un segundo después, estar con él. Sin atascos. Sin trenes. Sin esperas intermedias.
Puedo estar presente cuando pasa algo importante.
Y todo el tiempo que se dedica en el desplazamiento al trabajo, se lo dedico a él. Y eso se nota.

No quiero idealizar nada.
El trabajo remoto no lo es todo.
Lo que lo hace posible es una combinación de flexibilidad real y confianza mutua, tanto por parte de la empresa como por parte mía.

Soy celoso de mi tiempo (todo mi tiempo)

Algo que intento mantener muy claro es el respeto por el tiempo.
No solo por el tiempo personal, sino también por el tiempo laboral.

No quiero trabajar fuera de mi horario, pero tampoco quiero resolver asuntos personales dentro de mi jornada.
Si hay una urgencia, desconecto, aviso, y ese día acabo más tarde.
Si ese día me toca recogerlo de la guarde, empiezo un poco antes.
Y así, en ese equilibrio imperfecto, consigo que las piezas encajen.

Y sí, mi rendimiento se mantiene

Una de las cosas que más me ha sorprendido es que, pese a todas las dificultades, mi rendimiento no ha bajado.
De hecho, mi última evaluación de desempeño dice que incluso ha mejorado.
(Lo digo sin querer presumir; me gusta pensar que estoy aprendiendo a enfocarme mejor, quizás porque ahora el tiempo vale aún más).

En resumen

Sí: trabajar en remoto con un bebé en casa es más difícil.
Pero también, gracias a eso, puedo estar más presente, más conectado, más agradecido.

Y hoy, más que nunca, me alegro de haber apostado por un trabajo que no solo me permite trabajar desde casa, sino también vivir desde casa.

Maze Adventure y el placer de aprender con IA

A principios de año me entró curiosidad por entender cómo se programa un videojuego retro, como los que jugaba de pequeño. No soy gamer, no conozco la industria, ni tenía tiempo para complicarme la vida con un hobby exigente. Pero algo hizo clic.

Recordé aquellos títulos de principios de los 90 —Prince of Persia, Loom, Indiana Jones and the Last Crusade— que jugaba en mi viejo 286 con pantalla EGA y MS-DOS. Y me pregunté: ¿cómo funcionaban por dentro? ¿Cómo se hacían esos juegos desde cero?

No quería usar Unity ni motores gráficos modernos. Quería entender lo básico. Desde abajo.

Así nació Maze Adventure.

Aprender desde cero, pero no solo

Nunca había hecho nada parecido. No sabía por dónde empezar. Pero ahí entró en juego la IA.

Uso herramientas como CursorAI o GitHub Copilot a diario en el trabajo. Y tengo suscripción personal a ChatGPT. Uso la IA para un sinfín de opciones. Pero si tuviera que quedarme con un solo uso que me aporta valor real, sería este: aprender.

La IA me permite ir directo a lo que necesito. No sustituye el aprendizaje, lo acelera. Le puedo preguntar justo lo que no entiendo, pedir que me resuma algo a mi nivel, debatir entre varias opciones. Es como tener un mentor siempre disponible. Un compañero de pair programming que no se cansa, que responde a tus preguntas sin juicio y que además te ayuda a pensar.

IA como amplificador del foco

Maze Adventure no es un proyecto ambicioso. De hecho, es muy modesto. Pero tiene algo que otros side projects míos no tuvieron: continuidad.

¿Por qué? Porque he podido centrarme en lo que me interesa —la parte técnica, la programación a bajo nivel— y dejar que la IA me cubra en las partes que no me motivan tanto, pero que igualmente necesito: historia, gráficos, sonidos, referencias, etc.

En el pasado, muchos de mis proyectos se estancaban porque requerían demasiada energía en frentes que no me interesaban. Ahora, puedo apoyarme en la IA para resolver justo esos frenos. Eso no los hace menos valiosos: simplemente los enfrento con ayuda.

Con poco tiempo, pero mucho aprendizaje

Con un bebé de año y medio en casa, tener tiempo libre es casi una quimera. Apenas puedo dedicarle un par de horas cada dos semanas al proyecto. Pero gracias al multiplicador de velocidad que supone la IA, he podido avanzar.

No para sacar algo espectacular. Sino para aprender más de lo que habría aprendido en meses, y pasarlo bien en el proceso.

Ese es el valor real de este experimento: he aprendido un montón. He podido iterar sobre mis ideas. Reescribir. Preguntar. Entender. Cambiar de rumbo. Volver a preguntar. Y disfrutar del camino.

Código abierto y proyecto disponible

Todo el código está disponible en GitHub, por si a alguien le apetece curiosear, descargarlo o adaptarlo:

🔗 https://github.com/juanancid/maze-adventure

También he grabado un pequeño vídeo para mostrar cómo se ve en acción:

📺 https://www.youtube.com/watch?v=E4QhAwb9c0Y

Y si te interesa este tipo de proyectos o los detalles más técnicos, los suelo comentar en X (antes Twitter), donde comparto avances a mi ritmo, sin prisa y sin presión.

Cierre

Para mí, la IA no sustituye la creatividad ni el esfuerzo. Pero sí me permite hacer cosas que antes eran imposibles. No porque fueran técnicamente inalcanzables, sino porque me faltaba tiempo, energía o foco para mantenerlas vivas.

Y eso, en un hobby, lo cambia todo.

From Clean Code to Clear Models: My takeaways from Domain-Driven Design

I still remember how satisfying it was to finish Clean Code by Bob Martin. It gave me structure around the basics: good naming, readability, testability — the kind of habits that make code sustainable. It felt like collecting tools that every developer should carry.

But finishing Domain-Driven Design by Eric Evans hit differently.

It didn’t just give me tools. It gave me perspective.

The shift in mindset

Domain-Driven Design shifted my focus from “how do I write good code?” to “how do I build a model that represents the world we’re trying to understand and change?”

It’s not just about clean APIs or good object design. It’s about building a shared understanding — a model that reflects the domain clearly enough that everyone, from developers to domain experts, can speak the same language.

And that’s the key: ubiquitous language isn’t about consistency for consistency’s sake. It’s about ensuring the system reflects a language everyone understands and contributes to. Code becomes an expression of shared understanding — not just syntax, but semantics.

Concepts that hit home

There were several ideas that made me pause and think — some because they were new, others because they finally gave shape to things I’d sensed but hadn’t named.

Ubiquitous Language – Naming not just as a coding practice, but as a team-wide agreement.
Bounded Contexts – A clear reminder that not everything has to be universal. It’s okay (and healthy) for different parts of the system to use the same terms with different meanings — as long as the boundaries are explicit.
Model Evolution – The model must serve the present — and change as our understanding grows. Code that resists evolution will rot.
Distillation – The discipline of extracting the essential from the incidental. A model can do many things — but should focus on what matters most in the domain.

These ideas didn’t just explain how to build better systems. They explained why systems often drift into complexity — and gave tools to fight that drift.

Software as narrative

One of the ideas that stuck with me the most is this:

Software should tell a story about how it solves the problem.

Not just to machines, but to people.
A model is not just a mechanism — it’s a narrative. And that narrative is what helps the system stay coherent as it grows. It’s what allows people to join the project later and still make sense of it. It’s what keeps knowledge alive.

Without a clear narrative, systems decay. The why gets buried under the how.

Why it matters to me now

The systems I work on are not trivial. They involve complexity, collaboration, and constant change. And Domain-Driven Design gave me a way to step back — to see beyond the latest task or ticket, and think in terms of alignment.

Alignment between the code and the business.
Between the model and the reality it represents.
Between the people who build, use, and evolve the system.

Reading DDD felt like naming things I had been circling for a long time — and putting them on a mental map I can now use every day.

Final thought

I don’t think Domain-Driven Design is just a book about architecture. I think it’s a book about clarity.

If you’ve ever felt that the code you’re writing isn’t quite telling the story of the problem you’re solving — this book is worth your time.

El mejor regalo de cumpleaños

Hoy cumplo 47.

Como es mi cumpleaños, sólo he de trabajar media jornada. Y justo acabo de completarla.
Mañana es festivo local.
Pasado mañana, Recharge Day (el tercer viernes del mes es día libre para desconectar).

Así que en estos momentos estoy bajando la tapa del portátil… y no la volveré a abrir hasta el lunes.
Y lo mejor de todo: no he tenido que pedir ni un solo día de vacaciones.

Entre los beneficios de trabajar en Cabify, hay uno que valoro especialmente.
No es un cheque regalo.
Ni una bolsa de snacks.
Es algo mucho más difícil de regalar: tiempo.

Tiempo para disfrutar de los tuyos.
Para estar sin mirar el reloj.
Sin tareas. Sin notificaciones.
Libertad.

Y eso, a estas alturas de la película, vale oro.
Así que… menudo regalazo me ha caído este año.

Reseña de Hábitos atómicos: Transformación personal

Hace unas semanas entramos Irene y yo en La Casa del Libro, y vi en una estantería Hábitos atómicos. Le dije:
—Ese libro es famosísimo en el mundo del desarrollo personal.

Días después, el Día del Padre, apareció con él envuelto. Yo no había pedido nada, pero como soy difícil de regalar (y no suelo buscar cosas materiales), pensó que podía gustarme.

La verdad es que al principio no le hice caso. En mi vida he leído mucho sobre desarrollo personal. Estaba saturado. Y entre el nacimiento de Mauro y el trabajo, llevaba más de un año sin leer.

Hasta que un día lo abrí.
Y ya no lo cerré.

Sí, muchas cosas ya las conocía. O las intuía.
Pero el libro las ordena, las nombra, les da estructura.
Y me ha enseñado otras muchas que no sabía.

Me ha devuelto las ganas de leer.
He buscado huecos para seguir.
He subrayado. He anotado.
Y lo he disfrutado de principio a fin.

Ojalá se me quedara todo.
Siempre pienso en Cortocircuito pasando páginas a toda velocidad.
O en Matrix, aprendiendo kung-fu en segundos.

No funciona así.
Pero algo se queda. Algo cala.

Y con eso me basta.

The Coding Manifesto: Principles for clean, predictable, and maintainable code

There are hundreds of coding best practices out there. Books like Clean Code offer deep insights. Big tech companies publish detailed style guides. And countless articles explore every nuance of naming, formatting, testing, and structure.

But in day-to-day work—especially in fast-moving teams—we don’t always need more rules. We need clarity. We need alignment. We need a shared mindset.

That’s why I like working with manifestos. They help create a common language and set a north star for collaboration. Something that’s easy to remember, easy to teach, and easy to use in real conversations about code.

You can’t tell a new teammate: «Read this 200-page book to understand how we write code here.»

But you can give them this.

The Coding Manifesto

1. Readability comes first, always

Code is read more than it’s written.
Write for humans, not machines.
Choose clarity over cleverness.

2. Tests are first-class citizens

Every feature includes meaningful, reliable tests.
Tests document intent and catch regressions.
They deserve the same care as production code.

3. Functions should be small and focused

Each function does one thing well.
Operate at a single level of abstraction.
Extract helpers instead of mixing concerns.

4. Prioritize explicitness and clarity

Prefer explicit behavior.
Name things to reveal intent.
Keep key decisions close to the code.

5. Naming is part of design

Good naming is not cosmetic; it’s a design tool.
Names should be descriptive, not cryptic.
Follow consistent naming patterns.

6. Minimize dependencies; prefer the standard library

Add dependencies only with clear justification.
Don’t import a library to sort a slice.
Every dependency adds maintenance cost.

7. Handle errors explicitly

Catch errors where they can be meaningfully handled.
Never ignore them silently.
If skipped, document why.

8. Make side effects obvious

Reflect side effects in function names or signatures.
Avoid hidden behavior (like writing to a DB or sending emails).

9. Prefer explicit dependencies

Pass dependencies directly.
Avoid hidden access via globals or magic containers.

10. Consistency beats individual preference

Follow team conventions.
Avoid endless style debates.
Consistent code is easier to navigate, maintain, and onboard.

This isn’t a checklist. It’s a mindset.

In environments where people come and go, projects evolve, and speed matters, a shared philosophy is often more useful than rules.

This manifesto isn’t the only way to work well. But it’s a way I’ve found useful—one that teams can rally around and evolve over time.

Feel free to use it, adapt it, or fork it.

And if you or your team have your own principles you love, I’d love to hear them.