Cyril Mottier

Cyril Mottier

@cyrilmottier.com

Leadership, Engineering & Product amo.co. ex Zenly (Snap), CapitaineTrain.

648 followers115 following369 posts

We’ve been running with Gradle’s Isolated Projects for a few months now, and it’s been a game changer for our build times 💥. An unexpected benefit: because modules are much cheaper now, we’ve completely rethought how we modularize our app.

Cyril Mottier reposted

I published vibrance-0.1.0 on Maven, now with support for Compose for Desktop (JVM). The APIs let you mix colors yourself, or draw gradients as modifiers or Compose brushes. Next steps: refine the model training to improve some color transitions, better alpha support. github.com/romainguy/vi...

I often describe engineering leadership as choosing "the least flawed decision." There are no perfect trade-offs in software. Every choice has a cost. The job is to understand those costs, make them deliberately, and slow system entropy better than competitors.

"Software engineering is programming integrated over time" has never resonated more. Programming is getting close to free. The hard part is building systems that can live, change, and remain reliable over time.

A strong signal that your feature was designed well: it has clear boundaries. So clear that removing it feels like using a scalpel: delete a single directory, not start an excavation.

AI isn’t changing the job of engineering leadership. It’s amplifying it. Our job has always been to turn raw contributions into reliable systems. Before, that meant juniors & new hires. Now, it also means agents & AI-augmented engineers. What changed is the throughput.

Divide and conquer still wins. Separation of concerns still wins. Modularity still wins. Why? Because complexity is expensive. For humans (cognitive load, pace, quality) and for AI (reasoning depth, latency, token burn). Fighting complexity still pays off.

Compile-time flagging is a game-changer for large codebases. Just be sure to expose these variants only at the highest level of your build. If you don’t, you’ll end up with combinatorial complexity leaking everywhere in your code.

Join us with @ParisAndroidUG at @amoamoamo HQ on Jan 13, 2026! 🚀 On the agenda: generating videos off-screen and off-main thread from Composables, why & how we switched from Hilt to Metro DI, and how to build your own Kotlin compiler plugin.

Hidden perk of Metro DI over Dagger: no more wrestling with naming binding functions. We’ve migrated nearly our entire codebase to @Contributed* annotations cutting thousands of lines of code in the process.

Websites like apilevels.com are useful, but nothing beats analyzing your own data. At amo, we see a radically different Android versions distribution. It completely shifts our decision process regarding usage of AGSL, AVIF, HEIC, and more.

Tooling helps manage the complexity of large codebases. We built tools to track important metrics: ‘unused-modules’ to find deletable modules via DFS, ‘longest-path’ to calculate the longest dependency path - highlighting potential critical paths and more.

I love enums/sealed classes/union types. I really do. They give exhaustivity at compile time ❤️. But they just don’t scale. I always end up making the painful choice of trading compile-time safety for scalability. It hurts, but it’s necessary.

They don’t teach you this enough in CS school: graph data structures and algorithms are everywhere. Maps, social networks, build systems, object graphs, page ranking, you name it. Master them, and you’ll unlock superpowers in problem-solving. 🚀

Personal today's example: searching for the longest dependency chains - hence potential critical paths - in a build system-based directed acyclic graph and being 😲 by the result.

> During an investigation, your job is not to fix issues, it is to understand root causes. @p-y.wtf says (and does) it all…

P-Y@p-y.wtf

I turned a leak investigation into a post on the Block eng blog to share a method that works well! It's a bit long... I had to show how to encode code knowledge to automate leak investigations, and dig even deeper with YourKit Java Profiler. engineering.block.xyz/blog/the-lea... #AndroidDev

A vital rule for scalability: every compilation unit must build in <15s (our threshold). Though build time ≠ LOC, tracking it reveals bloat, enforces discipline, and keeps your project fast as it scales. Speed is non-negotiable.

For example, here’s today’s snapshot from our project: only 4 modules are massive in LOC—and surprise, they all build in >15s on CI. Now that we’ve measured, we can target fixes and optimize! Data drives action.

In a highly modularized codebase, typing full Gradle task names can be tedious. Gradle supports task name abbreviation: just type the shortest unique prefix. If ambiguous, Gradle suggests candidates. ⚠️ Use locally for speed, but keep codebase references explicit for readability!

5 ways motion elevates your product: 1️⃣ Emphasize information hierarchy Guide attention effortlessly. 2️⃣ Add delight Make interactions feel magical. 3️⃣ Provide feedback & status Keep users informed in real time.

Jeudi 16 octobre à 12h, je serai en direct avec Mathias de The Product Crew (TPC pour les intimes) pour parler engineering et produit ! Hâte d’échanger avec vous et de répondre à vos questions. À très vite !

We built a custom animatable, collision-aware, collapsible annotation system on Google Maps. Huge UX improvement but we lost tilt support along the way. We finally cracked the math and extended our projection calculations adding a whole new dimension to the map. Just gorgeous.

In the age of AI agents, a monorepo isn’t just a dev setup. It’s a competitive edge. Everything in one place means agents can explore, analyze, and act across your entire codebase, seamlessly.

Cyril Mottier reposted

🚀 Introducing OpenZL, a new #opensource, format-aware compression framework! It uses a unique “graph model” for compression, enabling modular, high-performance codecs and a universal decoder - perfect for structured data at scale Link: https://loom.ly/z09xoNw #DataCompression

engineering.fb.comIntroducing OpenZL: An Open Source Format-Aware Compression FrameworkIntroducing OpenZL: An Open Source Format-Aware Compression Framework

Software engineering is evolving fast thanks to AI. At amo, we built a team dedicated to leveraging AI across our stack. Our experience so far is pretty clear. AI isn’t (yet) great at building features to our craft standards. 1/2

But it excels at: 🥇 Reviewing PRs & catching subtle bugs 🥈 Code archeology finding commits that introduced regressions or deep behaviors 🥉 Large-scale codebase refactors AI as a force multiplier, not a replacement. 2/2

Great animations should always add value. But if they also bring delight, that’s a win 🏆. Instead of a generic 'Search', explicitly specify what’s searchable and animate each character individually. It subtly guides users, catches the eye, and feels uniquely crafted.

One of the most underrated parts of my job is "chaos management". Turning disorder into order, and slowing down entropy before it speeds up. It’s the invisible work that keeps everything running smoothly.