CODE

Writing about the bleeps and the bloops

RSS

Not actually a devlog #12

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

Reads ๐Ÿ“–

  • ๐Ÿ‡ฌ๐Ÿ‡ง How I estimate work. 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.
  • ๐Ÿ‡ฌ๐Ÿ‡ง Clock Synchronization Is a Nightmare. 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.
  • ๐Ÿ‡ฌ๐Ÿ‡ง How kotlinx.serialization generates code: a compiler plugin deep dive. 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.
  • ๐Ÿ‡ฌ๐Ÿ‡ง Your Engineers Aren't Lazy, Your Codebase Is Punishing Them. 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.
  • ๐Ÿ‡ฌ๐Ÿ‡ง 3 constraints before I build anything. 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.