Not actually a devlog #12

Unknown — Sat, 04 Jul 2026 00:00:00 +0000

Hey! Summer's here and side-projects are still on pause, but the reading list isn't. Here's what caught my eye recently.</p>

Reads 📖</h2>

🇬🇧 How I estimate work</a>. Sean argues estimates are political tools for non-engineers more than technical exercises, and honestly I live that every day. Most of the time isn't spent on the known work, it's spent on the unknowns you can't see yet, and the estimate ends up defining the scope rather than the other way around.</li>
🇬🇧 Clock Synchronization Is a Nightmare</a>. A great refresher on why there's no such thing as a global clock once you have thousands of independent machines. Takes me right back to studying distributed systems: NTP, TrueTime, Lamport timestamps, hybrid logical clocks, all the way down to accepting that perfect synchronization just isn't on the table and you pick your trade-off instead.</li>
🇬🇧 How kotlinx.serialization generates code: a compiler plugin deep dive</a>. Not my day-to-day stack, but compiler internals are always a fun rabbit hole. The two-pass IR generation and the "golden masks" bitmask trick for required-field validation are the kind of details that make you appreciate how much work goes into making reflection-free serialization fast.</li>
🇬🇧 Your Engineers Aren't Lazy, Your Codebase Is Punishing Them</a>. This one hit close to home. Fighting codebase drag has been my day-to-day struggle since I stepped into the Tech Lead Platform Android role. Inflated estimates, deployment anxiety, the untouchable corners nobody wants to touch, tests that lie about coverage, painful onboarding: I recognize every single signal, and the audit framework is a good way to turn "it feels slow" into something you can actually act on and justify investing in.</li>
🇬🇧 3 constraints before I build anything</a>. A one-page vision doc, a separable core technology, and one defining constraint to shape the whole product. It's close to how I try to operate before starting anything myself: force the idea into something short enough to survive scrutiny, keep the reusable part reusable, and pick the one constraint that will do the work of preventing feature bloat later.</li> </ul>

ADRs as a personal tool, then a team one

Unknown — Sat, 23 May 2026 00:00:00 +0000

Notes on a habit that kept changing audiences.</em></p>

Over a decade ago, I read an article by Michael Nygard</a> about Architecture Decision Records and decided to try one. I wrote it on a project I no longer work on, about a problem I no longer remember, for a future version of myself who would eventually forget — which, looking back, was the entire point.</p>

I've been writing ADRs ever since. What's strange is that the document has barely changed across those years, but my reasons for writing it have changed almost beyond recognition. This is a post about that shift, and about what an ADR turned out to be — once I stopped writing it just for myself, and later, once I started writing them with something other than humans in mind.</p>

Writing decisions before anyone else read them</h2>
For the first few years, I wrote ADRs alone, for myself. There was no template, no review process, no audience beyond the version of me who would inevitably forget. Most weren't even in shared repositories — they lived in personal notes, side-project folders, scratch directories on machines I no longer own.</p>
The format was whatever I felt like that day. Sometimes a few paragraphs. Sometimes just the question, the answer, and a quick note about what I'd considered and rejected. Nygard's structure was somewhere in my head, but I rarely followed it strictly — I was writing for an audience of one, and that audience already knew the project.</p>
What surprised me was how often I came back to those notes. Sometimes weeks later, sometimes months. A choice about how to structure a small library, made in twenty minutes on a Tuesday, would resurface when I started something similar later. Without the note, I'd have remade the same decision from scratch, probably worse. With the note, I had a starting point — and a record of what I'd already rejected.</p>
Most introductions to ADRs skip this phase. They start with teams, stakeholders, alignment — which is fair, because that's where the practice has the most impact. But I notice now that the habit, for me, started earlier and quieter than that. Before I ever wrote one for someone else, I'd been writing them for myself.</p>
At some point I suggested to the team that we adopt the practice together. The reasoning wasn't dramatic — I'd been writing these notes for myself for years, they'd been useful, and I'd started to notice that some of the discussions we kept rehashing in PR reviews were discussions I'd already resolved on paper, just not on shared paper. Without a written decision, an argument in a review easily turns into a clash of preferences — I'd rather we did it this way</em>. With one, the discussion has an anchor. "We decided this in ADR-X" doesn't end the conversation, but it changes its shape: instead of relitigating the choice in every PR, the discussion either accepts the existing decision or makes a deliberate case for revisiting it.</p>
Writing an ADR meant for the team turned out to be a different exercise than writing one for myself. The reasoning had to be explicit, not just remembered. The alternatives I'd considered and rejected needed to actually appear on the page, because the reader couldn't see them in my head. The tone shifted too — the notes I wrote for myself were sometimes terse to the point of being cryptic, but a shared note needed to make sense without me there to explain it.</p>
On the surface, the document hadn't changed much. Underneath, it was now answering to a different reader.</p>
A practice that worked, until it didn't</h2>
The team practice deepened over several years. I wasn't in a formal lead role at the time — I was a senior developer, and ADRs had become a natural part of how I worked with the rest of the team. The format I used became more disciplined, the cadence more regular, and the kinds of decisions worth documenting shifted — fewer small library choices, more architectural calls, more cross-cutting concerns. What surprised me most about that period wasn't how I used ADRs myself, but how the ADRs I didn't write started to matter. A colleague drafting a decision and bringing it to review was no longer a curiosity; it was the goal.</p>
Decisions also started to live longer than I'd anticipated. ADRs from a year earlier showed up in design discussions; "superseded" became a status I used regularly. The document was no longer just a record of what we'd decided — it was a record of how our thinking had moved.</p>
When I changed teams and joined a larger organisation, I came in as a developer, not as a lead. The team I joined had its own way of documenting decisions — a custom format that had been there long before I arrived, and that I won't get into here. For the first couple of years, I made a soft case for switching to standard ADRs — more direct, more recognizable, less idiosyncratic. I didn't push harder than that; I wasn't in a position to, and the existing format still mostly worked. The case never landed.</p>
Some time later I moved into a tech lead role, but the format question didn't immediately resurface. By the time it did, the situation had changed: the existing format was visibly struggling, decisions were getting harder to track, and a significant new architecture project was about to put real pressure on the system. I brought up ADRs again — this time addressed to the engineering managers and tech leads, since the conversation was about how we documented decisions across the organisation. The pitch was less about my preferences and more about preferring a recognized standard over maintaining yet another custom artefact.</p>
The first ADR I wrote in this new context was a cross-platform architecture proposal, co-written with my counterpart on the iOS side. We had pseudocode, architecture diagrams, and what we thought was a clear case. Between us, we had years of experience writing this kind of document. I thought I knew what I was doing.</p>
Not everything in those years went the way I'd have wanted. There's a specific ADR that left me with a lot to chew on — too recent to write about cleanly here, and the people involved deserve more distance before I do. But what I took from it, in the end, was less about the specific decision than about a set of conditions that I've come to recognize since, in my own work and in conversations with others.</p>
The first condition is that ADR review processes rarely define how closure actually happens. A document is drafted, comments accumulate, the comments eventually slow down — and the ADR is marked accepted. But "comments slowing down" can mean two very different things. It can mean people have converged on a shared answer, or it can mean people have run out of energy to keep objecting. The status field doesn't distinguish between the two. From outside the conversation, they look the same.</p>
The second condition is that an ADR doesn't have full control over where the conversation actually happens. The official channel is the document — comments, suggestions, structured review. But the real conversation has a habit of migrating: into DMs, hallway exchanges, side meetings, Slack threads the author isn't in. From inside the ADR, this migration is invisible. The document looks like it's calming down, when in fact the disagreement has simply moved somewhere the author can't see. And when an ADR can't close on its own — when the comments keep going or the author keeps redrafting — the organisation tends to invent another channel to force closure: usually a meeting, often run by someone higher up. The decision that emerges from that meeting isn't really the ADR's decision. It's a separate decision, recorded into the ADR after the fact. The document captures the outcome, but it didn't produce it.</p>
The third condition is subtler, and I think it's the one I underestimated most. A document several people have read appears to produce a shared understanding. In practice, each reader fills the document's ambiguities with their own assumptions, and those completions can diverge significantly without anyone noticing. Two engineers can walk away from the same approved ADR with different mental models of what was decided. The disagreement doesn't show up during review — it shows up later, in the implementation.</p>
What ties these conditions together, I think, is that they all blur a distinction the ADR format implicitly relies on but doesn't enforce: the distinction between approval and decision. Approval is a state of the document. Decision is a state of the people — and the people sometimes decide elsewhere. The ADR format is good at recording the first. It assumes the second has happened, but it can't tell.</p>
The question of formats came up again later, in a different team and a more formal role. The context was complicated — there was already a custom way of documenting decisions in place, with its own history and its own users, and I found myself proposing standard ADRs once more, with no clear outcome yet. That part of the story is still unfolding, and I won't pretend I've resolved it. It deserves more space than I can give it here. I plan to come back to it in another post.</p>
When the readers stopped being only human</h2>
The most recent shift came from somewhere I hadn't expected. Over the last couple of years, large language models have changed two things about how I work with ADRs — and they've changed them in opposite directions.</p>
The first change is in how I write them. I've gotten into the habit of running a draft past a model before sending it to human review — first to clean it up, then to push back on it. The model isn't a particularly imaginative reviewer, but it's reliably available, it doesn't carry social cost, and it's perfectly happy to argue with my reasoning without taking anyone else's time. What I've found, mostly, is that the document that goes to human review is better than what I'd have produced alone — not because the model wrote it, but because it disagreed with me first. The humans who review it afterwards spend their attention on the real points of contention, not on the gaps I could have closed myself. I plan to come back to this workflow in more detail in another post.</p>
The second change runs the other way. Once you have a project with a meaningful set of ADRs in its repository, those ADRs stop being just a memory aid for humans — they become context for the models you work alongside. An agent reading the codebase reads the ADRs too, and the suggestions it produces start to take into account decisions that wouldn't be visible from the code alone. On personal projects in particular, I've started using ADRs as explicit checkpoints in an LLM-assisted workflow: less code generated, more documentation produced through dialogue, each significant step pinned down in an ADR before the next one begins. It might look like a slowdown. It hasn't been one. I plan to come back to this workflow in more detail in another post.</p>
What strikes me, looking at these two shifts side by side, is how little the document itself has changed. The same template, the same structure, the same kinds of decisions worth recording. The ADR I write today for an LLM-assisted side project looks remarkably like the ADR I'd have written a few years ago for a team — and not very different from the notes I scribbled to myself a decade earlier.</p>
Still writing them</h2>
Across all of this, the document itself has barely changed. The same template, the same kinds of decisions worth recording. What's changed is what writing one costs, who reads them, and what they're for. Three different phases of the same habit, with the audience shifting each time — first myself, then a team, now sometimes a model — and the document quietly adapting underneath.</p>
The first ADR I wrote is gone, and I still couldn't tell you what it was about. I keep writing them anyway. Not because I think I've figured out what they're for — I don't think the answer holds still long enough to be figured out — but because every version of me that's tried them so far has been glad to have them around. That's a thinner argument than I'd have given ten years ago. It's also one I trust more.</p>

Not actually a devlog #11

Unknown — Tue, 27 Jan 2026 00:00:00 +0000

Hey! Is that still possible to say "Happy New Year"? If so, let's celebrate it!</p>
Reads 📖</h2>

🇬🇧 Architectural Debt is not just Technical Debt</a>. By nature technical debt is not just saying "we don't have the time" or "let's do this later". It's a trade we're doing with our later selves, and it's important to understand the consequences of that trade. It's intracted in many layers of our teams and organizations</strong>. This article is exactly about that and help us understand those choices are not just our own.</li>
🇬🇧 Mission, vision, poTAYto, poTAHto</a>. A really nice article about what is mission and vision. It gives us a lot of insights about how to communicate those concepts and how to make them resonate with our audience. And also the scale of each of those concepts.</li>
🇬🇧 Traits of a Good Tech Lead</a>. Becoming a good tech lead is not easy. You need to be conscious of your own limitations and be able to delegate tasks to others who are better suited to handle them. The author tries to give us specific traits to help us differentiate between EM and TL. He also provides a list of behaviors creating confidence for your team and the stakeholders.</li>
🇬🇧 The PERFECT Code Review: How to Reduce Cognitive Load While Improving Quality</a>. Code reviews are fun. Checklists are fun. Acronyms are fun. Go read it.</li>
🇬🇧 Three Ways to Solve Problems</a>. I like the clarity of this article and the straight forward approach. I read it not so long before Why Senior Engineers Let Bad Projects Fail</a> and I find them really complementary.</li> </ul>

Not actually a devlog #10

Unknown — Fri, 28 Nov 2025 00:00:00 +0000

Hey! Still not much concerning the side-projects so here are the articles! Have a good read!</p>
Reads 📖</h2>

🇬🇧 30 Fundamental Techniques for Software Architects</a>. Sharing vision and strategy when creating (or refactoring) a new architecture is not simplest thing to do. It's especially hard when many actors are involved and having multiple frameworks to be understood by specific audiences is critical. In this article you have a plethora of choices to do to so.</li>
🇬🇧 Top 5 Communication Frameworks for Engineers You Must Remember</a>. Like the one before having the best toolset to communicate is crucial, here you'll have ways to oganizare how you communicate and orchestrate your thoughts when presenting.</li>
🇬🇧 Collaboration sucks</a>. I've always tried to promote democracy and open room thinking when trying to create. And I've started working in a bigger team (like x4 times bigger). It was hard to move forward and a bit frustrating. Then I got to orchestrate the choices, well yeah collaboration sucks AND that's exactly when you understand that "divide and conquer"</em> is not necessarily bad. Giving less ownership to the whole team and delegate to people capable to have a better expertise (or can learn to get it) is like unlock a superpower.</li>
🇬🇧 Invert, always invert</a>. I loved the way this article presents a simple technique to totally change POVs about challenges. Will try.</li>
🇬🇧 To get better at technical writing, lower your expectations</a>. A good reminder to keep the things simple, even when you think they should be complex, especially when you think they are complex.</li> </ul>

Not actually a devlog #9

Unknown — Sun, 16 Nov 2025 00:00:00 +0000

Hey! The sneezing season is here! I had a lot on my plate at work and really less time to continue all the side-projects (yeah sure...</em>). Anyway here are some articles!</p>
Reads 📖</h2>
🇬🇧 Implementing an Undo/Redo System in a Complex Visual Application</a>. Creating state machines especially in the context of UI applications is always something I've liked. When it comes to play</em> with the history of the actions that's always where I thrive even if it can be hard. This article is talking about the undo/redo</strong> couple and it goes quite deep in the implications of such a "simple" feature.</li>
🇬🇧 The Software Engineer Spectrum: Speed vs. Accuracy</a>. All the article is kinda obivous to whoever is working in the tech industry and have navigated between smaller and bigger companies. However I find it really useful to write it somewhere, maybe even everywhere. It's so obvious it could be misregarded by some engineers or managers. I love this article format which is quite straight to the point.</li>
🇬🇧 Rust in Android: move fast and fix things </a>. I'm bit frustrated to share Google articles when it comes to Rust because I love the language and the whole "true" opensourceness feeling we have in this community which sounds less and less (if it ever) Google. I think that's also why I like this kind of articles where a big player is injecting more and more of Rust in their codebase and promote the benefits you can grab from it.</li>
🇬🇧 Every Caching Strategy Explained in 5 Minutes</a>. Caching is hard, knowing how to name caching is also hard (pun intended). Here you'll have a quick article where you have names and the related caching strategies so you'll throw the right terms to the next architecture decision meeting.</li>
🇬🇧 Become the Consequence</a>. This one is a must read</strong>. Once again it's exploring how a "manager" or a tech lead has to handle the dreadful duality of quality vs shipping in growing teams. It resonates so well with my current challenges it breaks my brain for a while. Go read it.</li> </ul>

Not actually a devlog #8

Unknown — Mon, 27 Oct 2025 00:00:00 +0000

Hello everyone! What a summer! I don't know about you but mine was full of surprises. For example I've finally launched back my photography website</a> and played a bit with all the (not so anymore) cool kids, like Preact</a>, Tailwind</a>, Compose Multiplatform</a>, deno</a> and Netlify</a>. It was great! The timing however is quite bad due to the fact I sold my camera around the same time (but you know sometimes stuff don't have to make sense I guess 🤷‍♂️). And now the articles!</p>
Reads 📖</h2>

🇬🇧How Core Git Developers Configure Git</a>. Git is probably the dev tool I'm using the most and I always look to have a better user experience with it so this article was definitely a tease for me. And without surprise I felt like a caveman at the end of it. So many good stuff to add to your config!</li>
🇬🇧UI layer architecture for persistent UI elements</a>. This one is for my Android UI dev peeps! It articulates really well how and why we should be persist UI elements per-screen or in a whole layout. Spoiler both are not easy and are critical choices.</li>
🇬🇧The valley of engineering despair</a>. Ooh Sean, why are you like that? So keen to let you articles found me right at the best time. During the summer I had a point where a project seemed less clear everyday and to quote the article "The trick is to recognize that the feeling is temporary - you can always work through it - and to make sure you don’t do anything stupid in the meantime"</em>. A quick but a must read.</li>
🇬🇧The Perfect Commit</a>, Software engineering practices</a> and Writing better release notes</a> are three articles I found during my constant goal of improving our processes in my day-to-day job. Nothing really new here but they are good reminders.</li>
🇬🇧Write the most clever code you possibly can</a>. I won't spoil you this one. It's a quick read and I was personnally outraged when seeing this title, ready to comment with some clean code or equivalent book quotes AAAAND nope :p.</li>
🇬🇧Exploring PausableComposition internals in Jetpack Compose</a>. I'm not a huge fan of pixel perfect tasks and stuff like that however I LOVE reading about UI frameworks internals. This article explores the PausableComposition</code> API in Jetpack Compose and it's a blast!</li>
🇬🇧How JavaScript Works Behind the Scenes</a>. I haven't touched Javascript outside of personal pet projects for long and it's always good to learn the basics :)</li> </ul>
Not actually a devlog #7 Unknown — Tue, 22 Jul 2025 00:00:00 +0000 Hello everyone! Time to share some articles with you!</p> Reads 📖</h2> 🇬🇧 Refining strategy with Wardley Mapping</a>. Before reading this I didn't know this Wardley person however I like maps! I haven't tested them in a real-life example however it seems really convenient to use.</li> 🇬🇧 Don't Unwrap Options: There Are Better Ways</a>. I agree a lot with this article forcing us to go forward than just using unwrap()</code> and I would say it's almost always the case when encountering that kind of unwrapping mecanism in any languages. When you have types and pattern matching we should use it, or a similar approach to avoid any ambiguous code.</li> 🇬🇧 Kotlin inline, reified to Solve Type Erasure and a Practical Guide on noinline, crossinline, and More</a>. Well the title is so long but it's fair. The subject is important when using Kotlin extensively and this article succeed to give a nice approach to something complex.</li> 🇬🇧 My Approach to Building Large Technical Projects</a>. There are some projects which are simpler than others implying less new knowledge and less guessing parts. There are others which are just small and capable to be shipped quickly. And we have the last ones where almost everything is new and we have no clue how to split the work. Mitchell Hashimoto was someone I followed a lot back when I was intersted in HashiCorp etc. I totally forgot about him, then I started to use Ghostty</a> just to find he was the main developer. The article gives so many vibes why I was following him before. It's concise but have a lot of informations and succeed to give some leads on how to actually split any new large technical project.</li> 🇬🇧 Kotlins's Builder Functions: A Better way to Create Lists, Maps, Strings & Sets</a>. Pretty useful functions helping us create common types where we want to have customized initliazers.</li> 🇬🇧 Rust Case Studies</a>. Lessons from people who've migrated to Rust succesfully or not.</li> 🇬🇧 10 Jetpack Compose UI Tricks You Probably Don't Know</a>. Exactly what you're expecting and hopefully you'll grab some interesting knowledge :).</li> </ul> Not actually a devlog #6 Unknown — Tue, 15 Jul 2025 00:00:00 +0000 Hello everyone! Not much in side-projects in the last months. I've only managed to fix a bit the blog's CSS. So here are four articles about programming (and related subjects 🫣)</p> Reads 📖</h2> 🇬🇧All Projects are Business Projects</a>. I've never been somewhere where THIS</strong> is not a subject. Sometime it's frustrating causing dev fatigue and sometime teams succeeds to handle it gracefully (jk never heard of something like that). So I hope this article could help convince people on the other side of the fence 😁.</li> 🇬🇧Deep dive into annotations in Jetpack Compose</a>. I've been doing less and less UI code recently. However when I discovered React</a> around 2020, I was hooked</strong></em> (pun intended). was waiting for stable releases of Jetpack Compose</a> and secretly wishing for something as easy to use. It was or at least it was WAY easier to produce reactive prototype than the ol' XML way. Now recomposition (and knowing when to do it) is an interesting problem for every framework in every language. Having nice API to make it even smarter is also a challenge. This article is directly talking about these kinds of little optimizations available in Jetpack Compose and when they can be really useful. A must-read for every Android developer.</li> 🇬🇧"You need to be more strategic."</a>. Some frameworks about strategies we can apply as devs to help us having a direciton.</li> 🇬🇧 How projects fail at large tech companies </a>. Interesting takes on projects failures.</li> </ul> Garbage Logger - Devlog#0 Unknown — Wed, 14 May 2025 00:00:00 +0000 Hello everyone! This one is finally a real devlog!</p> A while ago I asked myself what if I add one more side-project I will never finish? The obvious answer was yes. For this one the goal would be to be capable to monitor my family garbage production</strong> based on common, recycling and "green" bins. It could be a simple sheet shared between my partner and I. However I'm a mobile application developer and I haven't published one myself for a long time. The plethora of frameworks I can work with now is quite overwhelming but I like native development and wanted to extend what I do daily so I chose Kotlin Multiplatform</a></strong>. It's totally arbitratry and it could have make more sense to choose something web related but hey that's my thing not yours!</p> 🎯 One step at a time</h2> With these real devlog I should keep you updated about the progress. For now this this the theorical roadmap:</p> 1.0.0 - Foundations</strong> It should provide a nice dev environment for myself (meaning CI/CD, linters etc).</li> It should let the user registers/creates bins with their types (which are opiniated for now)</li> It should let the user updates bins</li> It should let the user delete bins</li> It should let the user adds a log to a bin</li> It should let the user updates a log to a bin</li> It should let the user deletes a log to a bin</li> Everything is local within the device</li> </ul> </li> 2.0.0 - Sharing is caring</strong> It should allow a user to create a home</li> It should allow a user to update a home</li> It should allow a user to delete a home</li> It should allow a user to invite another user to a home they're administrator</li> It should allow a user to kick another user from a home they're administrator</li> </ul> </li> 3.0.0 - Glowing up</strong> It should provides a nicer UI and UX</li> It should provides graphs</li> </ul> </li> </ul> 🚀 Show me what you got</h2> I'm obviously not putting dates behind them because I can't and want to keep it as a pet project without any real stress. The main targets are iOS and Android</strong>, however thanks to KMP I want to freely target desktops (through JVM app for now). So for now, I'm creating the test cases and basic usecases without any UI to share. I'm still struggling to orchestrate the CI/CD thing even if I consider it as a main goal to reach 1.0.0</strong>. I also didn't precise but this project won't be open-source (or at least publicly available) before 1.0.0</strong> (or a bit later).</p> Not actually a devlog #5 Unknown — Wed, 30 Apr 2025 00:00:00 +0000 Hey everyone! I'm finally assuming those are not real devlogs because I paused my side-projects a while ago. However here are some links I found nice recently.</p> Reads 📖</h2> 🇬🇧 How many threads does your network client use?</a> A really nice article about Kotlin network clients and how they handle concurrency under the hood.</li> 🇬🇧Pitfalls of Safe Rust</a> A nice to keep for people like me not working every day in Rust. Some error are trivials and easily avoidable however I found it nice to have them aggregated in a small article.</li> 🇬🇧Exploring for strategy</a> Now that the serie is completed getting back to the first part was really needed at least for me. It's a must read for anyone working in a tech environment.</li> 🇬🇧What would happen if we didn't use TCP or UDP?</a> A fun experiment about avoiding TCP/UDP. It brings me back in time when studiying OSI model and everything.</li> 🇬🇧The Best Programmers I Know</a> I couldn't agree more. A must read for everyone willing to know how "best programmers" operate.</li> </ul> Devlog #4 Unknown — Mon, 14 Apr 2025 00:00:00 +0000 Hey everyone! Nothing new but here are the articles and shows I found the most articles during the last 4 months(WTF).</p> Reads 📖</h2> 🇬🇧Location location location, revised</a>. A podcast episode where the team behind the Location API and related stuff explains many choices they had to take and strategy behing the diffent APIs.</li> 🇬🇧Is engineering strategy useful</a>. Another great article from Will Larson about the cost of writing an engineering strategy and why it's so impactful.</li> 🇬🇧How to Think About Time</a>. A good read to remember it's hard to work with time (and to start me with distributed</strong> clocks...).</li> 🇬🇧Debts, Tech and Otherwise</a>. Because tech debts articles are everywhere, it's hard to avoid talking about the other debts in a tech team. This article tries to summarize it.</li> 🇬🇧All pretty models are wrong, but some ugly models are useful</a>. Holy shot this one was good. I won't spoil it much but you should read it if you have to design API or do any modelization.</li> 🇬🇧"Vibe Coding" vs Reality</a>. A nice reality check about what's AI is capable of for the moment in the programming context.</li> </ul> Devlog #3 Unknown — Wed, 08 Jan 2025 00:00:00 +0000 Hello everyone! Have a great year! I've started a new side project (AGAIN) to work with Kotlin Multiplatform</a> more. Apart I read a bit during those last months.</p> Reads 📖</h2> 🇬🇧How to become a more effective engineer</a>. The title could seem a bit presumptuous but it's a nice read focusing on soft skills to acquire when starting in a new company or at least the ones needed to have a better understanding in your work environment.</li> 🇬🇧How and Why I Stopped Buying New Laptops</a>. This one is a bit old but still really relevant. I like how the author put it as a story with a context without blaming everyone not doing that immediately. Bonus point it's available in multiple languages.</li> 🇬🇧 How to fork: Best practices and guide</a>. Doing a fork can be intimidating, this article gives nice tips to do it nicely.</li> 🇬🇧 Using Rust in Non-Rust Servers to Improve Performance</a>. Sometimes I like when people take time to explain how they replace X by Y. Here the author is going step by step to do so with a Express application to a Rust powered server.</li> 🇬🇧How atomic Git commits dramatically increased my productivity - and will increase yours too</a>. Another good one about atomicity for Git commit. I'm hoarding those ones.</li> 🇬🇧I am tired of AI</a>. I don't like AI or at least not as we're promoting it right now. This post neither and it resonates a lot with my feelings.</li> </ul> Tools 🛠️</h2> DISCLAIMER I'VE NOT TESTED ANY OF THESE</strong> but they seem pretty cool</em></p> tummychow/git-absorb</a>. I'm a huge fan of rebase -i</code>. I like making surgery in my Git history however I also like being efficient about it and shipping quick fixes and going the whole process bothers me a bit. I really want to try this port and check how good (or bad) it is!</li> Introducing Kotlin Money</a>. It's been a while since I had to manage currency in a project. It's a tedious task and this library seems to make it easy.</li> </ul> Devlog #2 Unknown — Tue, 29 Oct 2024 00:00:00 +0000 Hey! Not much to show today, as planned nothing moved on my personal projects side 😅. However some great news and reads from the outside internets! First things first FOSDEM Devrooms</a> have been announced and I should go back to this edition \o/.</p> Reads 📖</h2> Bye Bye Google</a>. A great story (in French) about the erg</a>, a belgian school of arts and how they free themselves from Google Accounts system.</li> Paying down tech debt: further learnings</a>. I love reading about tech debt. It's a critical tool we have as developers (and product teams) to leverage legacy technologies (or choices) without compromising too much with newer techs (or specs changes). It's also a pragmatic way to have an empirical history of architecture decisions and could even help us to look back to the past when trying to understand product delivery rythm. Long story short, this article is a great read and you may want to read it if you any interest about the subject.</li> Basic Things</a>. An older one about what a project should implement or provide at the most basic level especially for bigger projects.</li> Why is language documentation still so terrible?</a>. A rant about language documentations and what they should look like. Not sure about the author tone but I totally share their opinion about Rust documentation. I would add even if Java "official" documentation is a mess, Kotlin is quite pleasant to browse!</li> </ul> Devlog #1 Unknown — Wed, 09 Oct 2024 00:00:00 +0000 Long time no see! Like a lot of blogs, I had no actual stuff to post about... And that's gonna change for a while! However writing is still something I like to do and sharing links is almost a daily practice for me. That's why I will try to post every two weeks or so. Most of my pet projects being currently "paused", I'll probably list contents from other places on the internet I found interesting. I secrectly hope this will motivate me to get back to work to those projects and share with you my bugs and fixes!</p> Reads 📖</h2> Jack Danger, the blog</a>. I discovered Jack Danger a month ago. His articles clicked so much with my feelings about how my previous (and current) engineering orgs are wokring I almost immediately shared it to most of direct coworkers with a simple question: "Do you feel the same way?". I'm a huge fan of Will Larson</a> and Jack Danger's work is somehow even closer to my experiences and my feelings when speaking about engineering orgs.</li> </ul> Tools 🛠️</h2> cocogitto</a>. Since a few months I'm using more and more standardized conventions to commit and automate most of my workflow around git. When I found about cocogitto</strong> I was a bit skeptical about what it could bring to my day-to-day experience especially because it asks to use "another" tool to git. My hooks were here and they seemed to be enough to cover all of my needs. However after a few weeks I'm quite happy about it. It creates a dedicated context switch to craft nice commit messages and helps me respect the conventions I try to use.</li> </ul> Snippets 🧩</h2> A simple script to enforce Conventional Commit</a>. Best used in the commit-msg</code> hook</a> :)</li> </ul> #!/bin/sh # Regex to validate the type pattern REGEX="^((Merge[ a-z-]* branch.*)|(Revert*)|((build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test)($.*$)?!?: .*))" FILE=`cat $1` # File containing the commit message echo "Commit Message: ${FILE}" if ! [[ $FILE =~ $REGEX ]]; then echo >&2 "ERROR: Commit aborted for not following the Conventional Commit (https://www.conventionalcommits.org) standard." exit 1 else echo >&2 "Valid commit message." fi </code></pre> Interesting content from Sept/Oct 2022 Unknown — Thu, 03 Nov 2022 00:00:00 +0000 What would be a blog without an article saying "hey cool what's up, I've not been here for so long so here a new article ouf of nowhere!". So here's my take on it, I'll try to keep this blog active with all the stuff I'm reading/watching/listening online I found useful. I'm already hoarding everything here</a>. However I also think it makes sense to have a quick sumup every now and then so here it is!</p> To Read</h2> The Verge - Android and iOS take big steps toward launching Matter smart home compatibility</a></li> Skamille.Medium - Debugging Teams: Groundhog Day</a></li> Twitchard - Be good-argument-driven, not data-driven</a></li> Smashing Magazine - Designing Better Error Messages UX</a></li> KtAcademy - Type modelling in Kotlin</a></li> Johannes Foufas.Medium - Why Rust is actually good for your car.</a></li> Piwai on Twitter about SQLite and Dispatchers</a></li> 47 Degress - Functionnal Domain Modeling in Kotlin</a></li> Dave Leeds on Kotlin</a></li> </ul> To Watch</h2> Youtube - Rust Linz, Jan 22 - Error Handling in Rust - A Pragmatic Approach by Luca Palmieri</a></li> </ul> To Test</h2> CyberChef</a></li> ffmepg.guide</a></li> </ul> Why Using Clean Architecture For Side Projects? Unknown — Tue, 02 Jun 2020 00:00:00 +0000 Hey everyone. As expected it took me some time to write the second article. I won't hide behind those curious times, I was lazy 😅.</p> I hope all your relatives and yourself are fine and safe.</p> Today I wanted to share with your my very own perspective about making side-projects. Let's start!</p> The Crappy Projects and The Never Ending To-Do List</h2> Let's settle something right here. Most of my side-projects are never finished crap rotting on GitHub, waiting to be deleted before the next ones. At the same time, I have that an ever growing To-Do List where some of the old items are about technologies not even maintained anymore. That, my fellow readers, was the sad record I've made at the end of every year since I've started programming. Obviously, some of the items from the list found a place in the crappy rotten projects and some of those ones succeed to be used a bit by myself. However shipping things is fun, maintaining very less.</p> Alas the boring parts would always be the same.</p> Clean Architecture Hammer Savior</h2> Some years back, Android (my day-job programming context) faced a wave of architecture revelations and illuminations. Every other talk and article were about how Clean Architecture could save developer lives and removing spaghetti from the codebase menu. It took me about one article to be drowned and start to cry about how bad I was at programming. However I tried, maybe not for the good reasons (yup sometimes hype is attracting). Coding was even harder than all the articles read and the videos watched. At the time I was almost fully dedicated to the subject (trying to migrate to this in my day-job project and implementing the plenty of examples found on the internet).</p> It definitely took me years and some aha moments</em> to start to understand the advices some very nice people gave me to use it correctly. The Clean Way™ was not an illumination, it's a slow path where putting all the parts together is taking a certain amount of time. I'm starting to feel almost enough confident to help people with it and talk about the subject. However I won't cover the what and the how to implement here :).</p> It also gives me a new perspective about what I was expecting when programming. Working with it everyday at my day-job and porting some spaghetti code I wrote before gives me new slow and steady goals.</p> Safety When Sharing</h2> One of those goals is being able to share my work with confidence even if I don't code very well. It's impressive to share your own little program on the vast ocean of marvelous projects on the Internet. Most of the time no one notice your errors and even if they do they'll probably help you. Even so, it's frightening.</p> Clean Architecture is focused on what you want to do with your project. The core</code> part is very abstract and are just definition for your use cases. Sharing it quickly, can help for feedback before even starting to install that Mongo instance (without speaking about the last trending driver) or pushing the actual server on a hosting machine.</p> It validates your domain. It can also let people talk you about their expectations. It's way easier to write some abstract code (with unit tests because you're someone nice) than trying to implement the whole stack needed for an experiment.</p> People can also join the project faster and PRs can be related only to pure features, letting other writing the implementations later (or never 😅).</p> It helps proving your point and let people safely interact with it.</p> Learning</h2> If all you have is a hammer, everything looks like a nail.</p> </blockquote> The other thing who struck me recently is how using Clean Architecture can help to have a quick overview about the core structure of a language. It was so obvious that it gave me this blog post idea.</p> Every language tends to have its own idiomatic way of writing/structuring things. However when creating a new project we tend to go straight to the working code and forget about it until the next one. Putting abstraction first helped me to go a bit deeper, especially when the language is not in a paradigm I use a lot.</p> My last two examples are Gutenborg (the program transforming my markdown to HTML for this blog) in Rust and stack-bingo</a> in Go. Coming from object oriented programming languages as Java or even Kotlin, it was a bit difficult to implement something with the same structure at the beginning. All the constraints I faced actually helped me a lot to understand if not the ideas behind the language at least the syntax and some of its grammar.</p> It won't be a silver bullet to be the rockstar developer in the targeted language. It still gives a good constraint to force you to avoid rushing the implementation and missing helpful concepts.</p> Keeping Your Own Pace</h2> As discussed before, decoupling the codebase helps to work in parallel and let you make evolution without breaking anything. Implementations being a totally different part, if someone is eager to use one of the feature planned on the roadmap but you don't have the time to work on the implementation right away that's okay. Any new contributor should be able to get it and start develop something.</p> I think that's also why decoupling stuff is so satisfying. Your core</code> is now your To-Do List with every new feature you would create and all the implementations are branches in the project where anyone can push their marvelous or crappy things.</p> Conclusion</h2> I'm probably a bit biased here. I like Clean Architecture a lot. I like Domain Driven Design a lot. Maybe I'm just an hostage of practices I've struggled with for so many years.</p> However it can be a powerful tool to manage new project, learn new language and/or keep sanity when working on the side! It's also tedious to implement but that's part of the fun. I haven't go deeper in the details but I would totally discuss about it. If interested don't hesitate to ping me on Twitter or by email me (at) jobo.to.</p> A huge warning here.</strong></p> Sometimes it can be useful to have this kind of overview, it doesn't mean we have to trash project from someone else just for the sake of Clean Architecture. The hammer, the nail etc. Languages and communities have their own philosophy and we should respect them. When contributing please take care about it.</p>