2025W51

A few interesting articles I read over the past few days

• How uv got so fast — This one hit different because everyone’s been saying “uv is fast because Rust” but the real story is way more interesting. It’s fast because of what it doesn’t do—no legacy .egg support, no bytecode compilation, no permissive spec violations. The timing was perfect: PEP 658 landed on PyPI in May 2023, giving direct access to package metadata, and uv launched February 2024. Honestly? Most of the speedups (parallel downloads, global cache, the PubGrub resolver) could be added to pip without touching Rust. The language helps with zero-copy deserialization and threading, sure, but the real win is having the courage to say “we’re not supporting that old stuff anymore.” It’s a reminder that sometimes architectural decisions matter way more than implementation language.
• My role as a founder CTO: Year Eight — Miguel got offered $500M for RevenueCat and turned it down. That decision alone makes this worth reading, but what I appreciate most is how raw he is about the oscillation between conviction and doubt. His wife told him to keep going, viewing it as their shared legacy, and that reframed everything. The rest is a founder CTO doing founder CTO things at scale—50 flights, still doing 40 interviews a year because hiring is “the highest leverage activity,” creating this Office of the CTO team for zero-to-one work. He admits his three biggest mistakes openly: wasting energy on a VP of Engineering search, letting hiring velocity stall mid-year, and moving people to new initiatives before stabilizing existing ones. What stuck with me though is that after all this growth and near-exit, he’s still fundamentally a builder who can’t imagine stopping. That kind of clarity about who you are is rare.
• Package managers keep using git as a database, it never works out — The pattern is almost comical at this point: use git as your package registry because it’s convenient and free, watch it break spectacularly as you scale, then quietly migrate to actual HTTP APIs. Cargo had users stuck on “delta resolution” forever, Homebrew’s .git folders hit 1GB, CocoaPods took minutes just to clone. The best part? They all solved it the same way—keep git internally for governance workflows, but serve metadata over HTTP/CDN to users. What I appreciate about this piece is how clearly it explains why git fails: it’s missing CHECK constraints, UNIQUE constraints, proper locking, query indexes, all the things actual databases have. Plus filesystem limits like Windows’ 260-character path restriction and case-sensitivity mismatches. It’s a textbook case of picking a tool that solves your immediate problem (version control + hosting) while ignoring what you actually need (a queryable database with performance guarantees).
• Maybe the Default Settings Are Too High — David Cain reads Lord of the Rings out loud at triple-slow pace, pausing after commas, and gets more out of it than speed-reading ever gave him. Same with eating—half speed, smaller portions, more pleasure. The insight that landed for me: when we rush to get to the “good stuff” faster, we actually guarantee we’ll miss it entirely. Our sensory systems need time to propagate the experience, but modern life has conditioned us toward empty, surface-level rewards because we treat everything as disposable. The paradox is brutal: we have infinite books and snacks available, so we unconsciously devalue each one by consuming it too quickly. Slowing down doesn’t just make experiences richer, it naturally redirects you toward substantive things because cheap chocolate and TikTok videos don’t reward patience. This meshes with something I’ve been feeling about how I read technical articles—scanning for bullet points instead of letting ideas settle.
• Faster Rust builds on Mac — I’ve been hitting this without realizing what it was. Every build script and test binary triggers XProtect’s malware scan the first time it runs, and since Rust compiles fresh binaries constantly, you’re basically waiting for a single-threaded security daemon to approve every executable. The author shows build scripts going from 3.88 seconds down to 0.14 seconds, and a test suite dropping from 9m42s to 3m33s, just by adding Terminal to the developer tools list. That’s a massive win for a one-time settings change. The honest trade-off discussion is what I appreciate here—this disables an OS security feature, so you’re choosing speed over protection. For personal dev machines where you control what code you’re running, that’s probably fine. For shared or work machines, maybe not. Either way, knowing this exists beats suffering through slow builds and blaming Rust.
• Write to escape your default setting — This connects to the previous article about slowing down, but focused on thinking instead of consuming. Our minds operate in “perpetual approximation mode”—jumping between shiny fragments, never settling long enough to go deep. Writing breaks that pattern by forcing you to create coherence on paper, which immediately exposes the gaps between what you think you know and what you actually understand. The Francis Bacon line hits: “reading maketh a full man… writing maketh an exact man.” What I appreciate is the permission to write fast and sloppy—the point isn’t polished prose, it’s getting the muddy bottom of your thoughts visible so you can examine it. This is why I keep coming back to writing notes and posts even when it feels inefficient. It’s not about producing content, it’s about extending my working memory beyond what I can hold internally and discovering what I actually believe.
• You’re Not Burnt Out. You’re Existentially Starving. — Neil Thanedar argues that burnout is often misdiagnosed—what we’re actually experiencing is Viktor Frankl’s “existential vacuum,” a profound absence of purpose despite material comfort. The argument cuts through the hustle culture vs. anti-hustle binary: working 100+ hours a week isn’t inherently problematic if those hours align with genuine purpose, but 40 hours of meaningless tasks will destroy you. What resonates is his challenge to reconnect with childhood dreams before self-doubt kicked in, then build your entire life around that direction rather than just optimizing leisure time. His own story—abandoning astronaut/president dreams in middle school, spending 15+ years in tech, finally embracing political engagement—shows this isn’t about sudden epiphanies but deliberate realignment. The “start small” advice matters: volunteer one hour weekly for something you believe in, don’t wait for perfect timing. Honestly? This reframes my own frustrations with leadership work as potentially a purpose problem, not a workload problem.
• You are not the code — Txus spent weeks building an elegant Clojure query language for power users, demoed it to his manager Manish, got told not to ship it, and then just… deleted the branch. The relief he felt in that moment revealed something profound: he’d been fusing his self-worth with his code output, making every criticism feel personal and every failure diminishing. The realization that “the code is an artifact, a byproduct of an ongoing process” freed him—the two weeks weren’t wasted because the learning remained even after the deletion. This hits hard for anyone who’s had technically brilliant work rejected for product/team alignment reasons. The maturity here is recognizing that being right about the technical solution doesn’t mean it’s the right solution. Your value comes from growth and capability, not from lines of code surviving in the repo. I’ve definitely struggled with this when features I built got deprecated or rewritten, feeling like it invalidated the work, when actually it just meant we learned enough to do something better.