2026W27
A few interesting articles I read over the past few days
This is the output of an automated process. Every Sunday, a script retrieves articles I've saved and read, uses AI to expand my quick notes into something more coherent, then publishes them. This post is one of those articles.
- Ten years of ClickHouse in open source — The detail that stuck is the monthly drill where they deliberately shut down a datacenter to force the system to survive it. Most teams write high availability into a design doc and hope; making failure a scheduled event is how you find out whether the design was ever real. I also liked Milovidov’s admission that removing code is now his favorite thing to do, coming from the person who built the whole thing starting with a first query pipeline that just printed numbers to TSV. Ten years in, the reflex has flipped from adding to subtracting, which feels like the honest endpoint of maturing on a codebase.
- How we scale PgBouncer in ClickHouse Managed Postgres — The core constraint is almost embarrassingly simple: PgBouncer is single threaded, so a 16 vCPU box runs one busy core and fifteen idle ones. Their fix, many processes sharing a port via so_reuseport, is the obvious move, but the part I hadn’t considered is what breaks once you do it. Postgres cancel requests arrive on a separate connection, and the kernel can route that cancel to a different process than the one holding your session, so they had to make the processes peer and forward cancellations to each other. That is the kind of second order detail that turns a clean idea into real infrastructure, and it took them from 87k to 336k TPS on identical hardware.
- Good Tools Are Invisible — The line I keep coming back to is that you cannot have an honest conversation about a tool with someone who has decided the tool is part of their personality. It reframes a lot of editor arguments as identity defense rather than actual disagreement about productivity. His test is blunt and useful: measure wall clock time and how many mistakes you made, not how clever the workaround felt. I’ve caught myself enjoying a fiddly vim macro that Sublime’s multiple cursors would have done in a tenth of the time, so this one landed a little too close to home.
- Finding a needle in a 4 GB haystack: from 0.75 GB/s to 49 GB/s in Go — The counterintuitive result is that parallel pread beat memory mapping, because copying data with the kernel’s tight loop turned out cheaper than eating a page fault per 4 KiB page. I would have bet on mmap and been wrong. The other lesson is that SIMD stopped mattering the moment the work went memory bound: making the CPU side 8x faster does nothing when the CPU is asleep half the time waiting on cache lines. Past a point you’re not optimizing code anymore, you’re optimizing against DRAM bandwidth, and the honest ceiling here was single channel DDR5 at around 48 GB/s.
- Half-Baked Product — This is a parable about an oven startup and it was the most uncomfortable thing I read this week, because I recognized every scene. The one that cut deepest: the rotating base was always the second highest priority, and the second highest priority never gets done. Nobody decides to abandon the core product, it just erodes one ticket at a time while the algorithm that burns bread 10% of the time sits untouched under twelve new buttons. The ending, where an identical fresh engineer signs on for the same dream and laughs off the rotating base warning from the forum, is the darkest part, because it says the problem was never a single person.
- Maybe you should learn something — The mechanism I hadn’t articulated before is that sleep is where the improvement actually happens, so the first session feels awful and the real progress only shows up the next day. That matches every instrument and language I’ve picked up and quit, usually right at the point where quitting felt most justified. I also liked the practical guardrail that sessions should stay in the 30 to 45 minute range, because practicing while tired just trains your mistakes in. The claim underneath all of it, that slowly learning a hard thing rebuilds your sense of agency, is really what the piece is about.
- 98% isn’t very much — The framing that stuck: 98% of the population is not 98% of your audience, and even that slice is real people staring at a broken screen. His concrete case is CSS nesting getting called widely supported in 2023 while actually working for only 70% of one client’s real visitors over a year. That gap between the caniuse number and your actual traffic is exactly where I stop trusting the green checkmark. It’s a good argument for graceful degradation over feature detection headlines, because the 2% stays invisible right up until it’s your customer.
- If you’re a button, you have one job – Unsung — Wichary’s test is tapping rotate eight times fast and watching what the phone does with the taps it can’t animate yet. The iPhone buffers them and plays catch up; the Nothing Phone gives you a haptic buzz and drops the input on the floor. The rule, never make the user wait for the animation to finish, sounds obvious until you notice how many interfaces treat the animation as the source of truth instead of the state. His situational power user point is the good bit: someone rotating fifty scanned documents is briefly a power user of a feature its designer assumed was casual.