▴

Reads

A reading log that updates every Sunday (when I've read enough).

I save articles to my read-it-later app and write quick thoughts as I read. An automated task pulls everything I've read during the week, uses AI to review the content and expand my notes into something more coherent, then publishes them here.

#
  • Distinguishing yourself early in your career as a developer — Honestly? This hit different. Phil breaks down the job market into three tiers and the advice that stuck: start local, skip the FAANG obsession early on, and—here’s what I appreciate most—write consistently about niche technical stuff. Not for clout, but because it’s genuinely one of the most effective ways to build credibility over time. The 6-12 month job search reality check is brutal but refreshing. Also, the idea that support or QA roles can be legitimate entry points into dev? That’s the kind of pragmatic wisdom people actually need.
  • You Are NOT Dumb, You Just Lack the Prerequisites — I’ve definitely read this before, but revisiting it at the start of the year feels intentional. The premise is simple yet powerful: struggling with hard concepts doesn’t mean you’re intellectually incapable, it means you’re missing the foundational pieces. What resonates is the author’s journey—150 days of going back to basics in math, systematically rebuilding understanding. It’s the kind of humility and persistence we need more of. The analogy about jumping into a video game at minimum level? Chef’s kiss. This is the energy I want to carry into 2026.
  • The Prison Of Financial Mediocrity — This thread captures something unsettling about where we are right now. A whole generation is effectively locked out of traditional wealth-building paths—no homeownership, no stable pensions, wages that don’t match cost of living. So what happens? People turn to high-variance bets like crypto, prediction markets, and sports betting because it feels like the only way to gain some agency over their financial future. The platforms and “hope sellers” profit regardless. It’s a depressing feedback loop where desperation meets exploitation. Hard to read, harder to ignore.
  • How to add two vectors, fast — When Txus writes about low-level optimization stuff, you stop and pay attention. This is a deep dive into CPU vs GPU performance for vector addition—concrete benchmarks, memory-bound vs compute-bound problems, the whole deal. The best part? Learning that throwing fancy optimizations at a memory-bound kernel barely moves the needle because data movement, not computation, is the bottleneck. It’s a reminder that profiling and understanding hardware constraints beats clever code tricks. If you’re into performance engineering or just curious about why GPUs work the way they do, this is worth your time.
  • How We Lost Communication to Entertainment — This one stings because it’s true. We don’t have social networks anymore, we have entertainment platforms optimized for engagement, not connection. The shift is subtle but devastating: people now accept lost messages, multiple accounts, algorithmic feeds that prioritize virality over trust. The author draws this generational line—older folks expecting reliability, younger users treating platforms like content feeds. What I appreciate is the refusal to chase critical mass. Instead: email, RSS, mailing lists, offline-first tools. It’s a smaller community, sure, but one built on actual communication. I feel seen.
  • Designing remote work at Linear — Linear’s approach to remote work feels refreshingly intentional. It’s not just “we allow WFH,” it’s designed around freedom, trust, and deep focus. Small autonomous teams (2-4 people), rotating project leadership, zero-bugs SLAs, quality Wednesdays, feature roasts before shipping—these aren’t just rituals, they’re guardrails for maintaining quality without micromanagement. The goalie rotation for handling unplanned work is clever. And honestly? The 10-year equity exercise windows and sabbatical provisions show they’re thinking long-term about retention. This is what remote-first looks like when you actually commit to it, not just tolerate it.
  • Engineers who won’t commit force bad decisions — This called me out a bit. The argument is sharp: when senior engineers stay non-committal in technical discussions, they’re not being careful or humble—they’re shifting the burden to less-informed teammates. Either junior devs end up guessing, or the loudest voice wins by default. The root cause? Fear of being publicly wrong. But here’s the thing: managers expect some calls to fail, especially on genuinely hard problems. The threshold is simple—if you have more context than others in the room, speak up. Caveats and hedging just create friction. It’s uncomfortable but necessary: taking a position, even with uncertainty, moves the team forward.
#
  • 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.
#
  • Thin Desires Are Eating Your Life — This hit different. The distinction between thin desires (scrolling, checking notifications) and thick desires (learning something hard, building real skills) explains so much about why we feel empty despite having instant access to everything. What really stuck with me: tech companies have figured out how to extract the dopamine hit from meaningful activities while stripping away the transformation. Social media gives you the reward of connection without any of the depth. The best part? The author doesn’t prescribe some grand solution—just small acts of resistance like baking bread or writing actual letters. Things that refuse to be optimized, that force you to slow down. Honestly? That feels more achievable than trying to quit everything cold turkey.
  • Go ahead, self-host Postgres — I appreciate how blunt this is about the cloud narrative. The author’s been running self-hosted Postgres for two years, serving millions of queries daily, and spends about 30 minutes a month on maintenance. Meanwhile AWS charges $328/month for what’s basically vanilla Postgres with some operational tooling wrapped around it. What convinced me most? The actual numbers: migrating from RDS took 4 hours of work, performance was identical, and the operational burden is genuinely minimal if you’re comfortable with the basics. Not saying managed services are never worth it—startups moving fast or enterprises with compliance needs make sense—but for everyone else paying those cloud premiums? You might be solving a problem you don’t actually have.
  • This is not the future — This felt like someone finally saying what I’ve been thinking. The premise is simple but powerful: nothing is inevitable just because a tech company with billions says it is. We’ve been trained to accept every new “innovation”—AI features shoved into everything, unrepairable devices, surveillance masquerading as convenience—as if it’s the natural progression of technology. But it’s not. Every choice is political, every adoption is a vote. What I appreciate most is the refusal to be passive. The author gives you a whole list of things that aren’t actually necessary (internet-connected toasters, subscription car features, mandatory accounts for basic functions) and basically says: you don’t have to accept this. Choose tools that respect you. It’s a reminder that we still have agency, even when companies pretend we don’t.
  • Disks Lie: Building a WAL that actually survives — The title nails it: your storage stack is absolutely lying to you. This breaks down all the ways a naive write-ahead log will fail in production—data sitting in kernel buffers pretending to be persisted, silent bit flips, operation reordering, the works. What I found most valuable is the five-layer defense strategy: checksums to catch corruption, dual WAL files on separate disks (because latent sector errors are common enough that a single copy is “negligence”), O_DIRECT + O_DSYNC to bypass buffering entirely, io_uring with linked operations for ordering guarantees, and post-fsync verification reads because you genuinely cannot trust that your data made it to disk. It’s paranoid, sure, but production durability demands paranoia. The storage stack will not tell you the truth about whether your data is safe.
  • Lightweight Cardinality Estimation with Density — This is one of those pieces that makes you appreciate how much thought goes into query optimization. Density is just 1/ICARD (the reciprocal of distinct values), but it’s surprisingly useful for helping query planners decide which index to use. The insight that stuck: for uniformly distributed data, density tells you roughly how selective an equality predicate will be, and comparing densities across multiple columns reveals correlations in your data. What I appreciate most is the practicality argument—unlike histograms or other complex statistics, density is cheap to compute and maintain at scale, even using approximations like HyperLogLog. It’s not perfect, but it’s a valuable tool relative to its cost. Sometimes the simple heuristic that you’ll actually use beats the sophisticated one that’s too expensive to track.
  • Zed Is Our Office — The audacity of this vision is what gets me. They’re not just adding collaboration features to an editor—they’re arguing that the editor itself should be your office. Built from scratch with CRDTs for seamless real-time editing, zero-friction setup (just GitHub auth), built-in audio and screenshare that automatically follows who’s talking. What really sells it? They’re using Zed to run their own company. Not as a demo, but as their actual workspace—channels for company-wide discussions, projects, personal focus. The ambition here is that code, conversations, and context all live in the same place, accessible to both teammates and AI. Most collaborative editors feel bolted-on and end up forcing you back to Slack or Zoom. This feels like a genuine rethink of what a development environment could be if collaboration was fundamental, not an afterthought.
  • Leaving Meta and PyTorch — There’s something quietly powerful about leaving at the peak. Soumith led PyTorch from inception to 90%+ adoption across the AI industry, and now he’s walking away from “one of the AI industry’s most leveraged seats” to do something small and uncomfortable. What struck me most is the self-awareness: he couldn’t ignore the counterfactual regret of never trying something outside Meta. The reflection on institutional strength resonates too—PyTorch doesn’t need him anymore, the team can solve problems without him, and that’s actually the sign of success. It’s a reminder that sometimes the right move is stepping away precisely when you’ve built something that can thrive without you. The curiosity to start over, to be a beginner again, even when you’ve already won? That takes guts.
  • The Talent Machine — The core reframe here is brilliant: stop thinking of hiring as filtering applicants and start thinking of it as selling a product. Define what you’re actually offering—not just the tech stack, but the culture, the mission, the compensation structure—and position it to match what specific candidates want. What really clicked for me is the emphasis on transparency as a competitive advantage. Public employee handbook, fixed salaries instead of negotiable ranges, clear career paths. Most companies treat this stuff like trade secrets, but being radically transparent eliminates friction and self-selects for cultural fit. The tactical advice about targeting underserved demographics (experienced engineers in their 30s-40s looking for stability) and choosing less-saturated tech stacks to reduce competition? That’s the kind of strategic thinking most companies miss. Hiring isn’t about having the biggest budget, it’s about knowing exactly who you’re for and making it dead simple for them to say yes.
#
  • SQLite JSON Superpower: Virtual Columns + Indexing — This is one of those “why didn’t I know about this sooner?” moments. The idea is simple but powerful: dump your JSON into SQLite, create virtual columns that extract specific fields on the fly, then slap indexes on those virtual columns. Boom, you’ve got schemaless flexibility with relational performance. No backfilling, no migration headaches. You can literally add a new indexed column later without touching your data. The beauty is in how it solves the eternal “should I go schemaless or relational?” debate by just saying “both.”
  • Recortes 2025 — Javi’s year-end reflections hit different. It’s refreshing to read someone being this honest about the mental toll of being CEO while also celebrating running a 10k at 43. The quote about not being able to compete with someone having fun keeps bouncing around in my head. There’s something profound about acknowledging that working hard without questioning what you should actually work on is just lazy thinking with extra steps. Also, keeping a diary for his daughter to understand his life context later? That’s the kind of long-term thinking I respect.
  • Litestream VFS — This genuinely blew my mind. You can query SQLite databases sitting in S3 without downloading the whole thing. Just fetch the pages you need using S3 range requests and an LRU cache. Point-in-time recovery is just a SQL pragma away. The LTX format compacts page versions so you’re not storing redundant data. This solves so many “I just need to quickly check production” moments without spinning up a whole restore dance. The technical elegance here is top-notch.
  • Craft software that makes people feel something — Raphael built Boo, a code editor, mostly for himself because he wanted something with soul. His point about repetition killing creativity resonates hard. When coding becomes mechanical, you lose the spark that makes people go “wow.” What I appreciate most is his willingness to build something not commercially viable just because it matters to him. In an era obsessed with PMF and growth metrics, building for joy feels almost radical. The comparison to Lego is spot on too - the best software feels like play.
  • The Long Run — Miguel went from being a non-runner to completing a full marathon, running through 18 cities along the way. But this isn’t really about running. It’s about rewriting your internal script. Once you do something you thought was impossible, the ceiling lifts everywhere else. “Discipline compounds quietly, until suddenly you’re a different person” is the kind of truth you only understand after experiencing it. The best part? He doesn’t frame it as inspiration porn, just an honest account of how doing hard things changes what you think you’re capable of.
  • Transparent Leadership Beats Servant Leadership — The distinction here is subtle but important. Servant leadership can accidentally create dependency where you’re constantly clearing paths for people. Transparent leadership is about teaching people to clear their own paths. You coach, you connect folks directly, you explain the “why” so they can make good calls independently. The goal is to become redundant by leveling everyone up. I’ve seen too many managers become bottlenecks disguised as helpful. This framework gives language to why that feels wrong and what to do instead.
  • Why I Ignore The Spotlight as a Staff Engineer — Not all impact comes from high-visibility projects. Some of the most valuable work is being the long-term steward of critical systems nobody thinks about until they break. The trade-off is less external glory, but you get to build deep expertise and solve genuinely complex problems. The “shadow hierarchy” concept is fascinating - getting recognition through customer team endorsements rather than flashy launches. “The most ambitious thing you can do is stay put, dig in, and build something that lasts” flips the typical career advice on its head, and honestly? It’s probably right more often than we admit.
  • Delta Lake Atomicity — A solid technical breakdown of how Delta Lake gets atomicity without traditional WAL. Instead of page-level recovery, it uses copy-on-write: write new Parquet files, then atomically write a JSON log entry pointing to them. If something crashes mid-flight, the uncommitted files just sit there invisible since they’re not in the log. It’s clever because object storage guarantees single file write atomicity, so you piggyback on that rather than building your own transaction log infrastructure. Clean, simple, and it works.
#
  • Surviving Long-Running Projects — A nice reality check on how grueling big projects can be. The author basically says: expect them to drag on, plan for “boring” maintenance, and set up routines to keep your motivation and mental health intact. It’s more about staying sane than about technical tricks.
  • How we built it: Real-time analytics for Stripe Billing — This is a cool peek under the hood. Stripe walks through how they built real-time analytics on top of billing, mixing Kafka, Flink, and their own in-house magic. It’s a story about scaling data pipelines to billions of events and still keeping dashboards snappy.
  • 9 Things Every Fresh Graduate Should Know About Software Performance — Basically “performance isn’t magic.” It covers the usual suspects (memory allocation, cache, I/O, concurrency) but framed as a gentle guide for juniors. Solid reminders even for experienced devs.
  • A brief history of threads and threading — A fun historical tour of how we got to modern threading. From early OS days to today’s multicores, it’s an eye-opener on how messy and evolutionary concurrency really is.
  • Hired Through GitHub: Part 1 — The author tells how showing work on GitHub led directly to job offers. It’s a feel-good story about the value of public contributions and writing about your code.
  • In response to a developer asking about systems — This is like a mini-manifesto on what “systems” really means. The takeaway is: stop chasing trendy tools and learn fundamentals — OS, networks, distributed systems. That’s how you actually “get” systems.
  • From 19k to 4.2M events/sec: story of a SQLite query optimisation — Absolute banger. The author squeezes insane performance out of SQLite with indexing, batching, and clever SQL tweaks. Great reminder that small changes in schema/queries can be game-changing.
  • UTF-8 is a Brilliant Design — A love letter to UTF-8. The author explains why it’s elegant, backwards-compatible, and just plain clever. Makes you appreciate how much thought went into something we all take for granted.
  • Being good isn’t enough — A short but punchy post: skill alone won’t get you ahead. Communication, visibility, and timing matter too. Basically: don’t hide behind code.
  • Introducing Direct Compress: Up to 40x Faster, Leaner Data Ingestion for Developers (Tech Preview) — Marketing-y but interesting. A new ingestion tech promising 40x faster loads. The takeaway: data infra vendors are pushing more on-the-fly compression to cut storage and speed up analytics.
  • When more threads make things worse — A cautionary tale of over-threading. Past a point, adding threads doesn’t help — it can create livelocks, context switching overhead, and general sadness. A good read if you’ve ever said “let’s just throw more threads at it.”
  • You can try to like stuff — An odd but uplifting essay about cultivating taste. The author argues that liking things is a skill you can practice, not just something that happens. Kind of refreshing.
  • Reflections on Tinybird — A personal reflection from someone using Tinybird. They talk about what impressed them, what didn’t, and lessons learned from building real-time APIs. Interesting outsider’s perspective.
  • Do the simplest thing that could possibly work — Classic XP wisdom retold. The post champions simplicity over cleverness. Don’t over-engineer; just do the simple thing first and iterate.
  • Developer’s block — Like writer’s block, but for coders. Talks about burnout, procrastination, and ways to get unstuck. Feels relatable if you’ve ever stared at your editor unable to start.
  • The First Time I Was Almost Fired From Apple — Great storytime. An engineer recounts a near-disastrous mistake at Apple and what it taught them about responsibility and learning under pressure.
  • Linear sent me down a local-first rabbit hole — A cool piece about discovering local-first architectures (like CRDTs) after using Linear. Shows how design decisions in apps can spark curiosity about deeper tech.
  • Local-first search — Builds on that same local-first theme. Explains how search can work offline-first with sync happening in the background. Makes you rethink how “search” has to be architected.
Page 1 Next →