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.

Cómo convertí mi hobby en una obligación: lecciones de escritura

A principios de 2022 empecé a escribir en LinkedIn de manera regular. La motivación era simple: escribía porque me gustaba. Por el placer de ordenar ideas, de compartirlas, de construir algo pequeño y personal.

Con el tiempo, los artículos empezaron a funcionar: más recomendaciones, más contactos, más impresiones. Ver cómo mis palabras conectaban con otros era bonito. Así que decidí profesionalizarlo.

Planifiqué una estrategia siguiendo el modelo hub, help, hero. Definí temas principales, marqué una frecuencia, empecé a medir métricas y documentar el progreso. Quería crecer de forma orgánica. Quería hacerlo «bien».

¿El resultado? Acabé saturado.

Lo que había nacido como un refugio se convirtió en una obligación. Mi afición dejó de ser un placer y se volvió otra tarea más en una lista infinita. Y dejé de escribir.

Estos días he estado reflexionando sobre ello. Un hobby debe nacer desde la libertad: lo haces porque quieres, porque te llena. Pero sin darme cuenta, convertí un refugio en otro frente de batalla. La energía pasó de explorar a demostrar. Lo que me calmaba empezó a agotarme.

La buena noticia es que con el tiempo esta presión se ha disuelto. Y es que cuando no mides, no planificas y no te exiges, las ganas vuelven. Poco a poco. Hoy escribo esto porque me apetece. Porque disfruto. Sin objetivos, sin métricas, sin planes. Simplemente por el placer de hacerlo.

Es curioso. Era algo que ya sabía, pero la vida me lo ha vuelto a recordar:

  • Un hobby no es un proyecto.
  • El placer no tiene que ser útil.
  • Las aficiones no se optimizan.
  • Negocio es negación de ocio.

Esta es la razón principal por la que he estado tanto tiempo en silencio. Pero hay otras. Durante estos meses me he sumergido en otros proyectos ilusionantes, que ya os iré compartiendo poco a poco.

Gracias por leerme.

Antes de proponer un cambio, pregúntate esto

A lo largo de los años he visto sugerencias que revolucionan un proyecto para mejor, y debates que solo generan desgaste sin ningún beneficio real. Proponer un cambio puede ser una herramienta poderosa, pero sólo si aporta valor real y mejora de manera significativa el trabajo.

Sugerir cambios no debería ser algo automático, sino una decisión reflexiva. Antes de proponer una modificación, es útil preguntarse:

1️⃣ ¿Ayuda a cumplir el propósito del trabajo?
Un cambio debe contribuir directamente a que el resultado esté más alineado con su objetivo. Si la propuesta no tiene un impacto claro en el propósito del proyecto, quizás no sea necesaria.

2️⃣ ¿Añade un valor claro y tangible?
Un cambio relevante debe sumar algo significativo al resultado final. Si la propuesta no mejora sustancialmente la calidad o el impacto del trabajo, puede que no sea prioritaria.

3️⃣ ¿Corrige un problema crítico y objetivo?
Cuando un cambio corrige errores, elimina fricciones o mejora la experiencia de usuario, es esencial. Estos son los cambios que no debemos dejar pasar.

4️⃣ ¿El esfuerzo del cambio justifica el impacto que generará?
Hay cambios que pueden ser técnicamente correctos pero poco prácticos. Si la implementación requiere mucho esfuerzo sin un beneficio proporcional, probablemente no merezca la pena.

Es natural tener preferencias sobre cómo hacer las cosas, pero un cambio relevante debe ir más allá de los gustos personales. El verdadero valor de proponer un cambio está en su impacto positivo y su alineación con los objetivos del proyecto.Antes de sugerir un cambio, hazte esta pregunta clave: ¿es realmente necesario?