The editorial frames PHK as 'the rarest thing in tech media: a working systems engineer talking honestly about working systems, without a product to sell or a conference keynote to promote.' His farewell represents the end of a distinctive era of grumpy, hands-on long-form commentary in ACM Queue from someone who actually built the infrastructure he wrote about (FreeBSD internals, GBDE, phkmalloc, Varnish Cache).
PHK argues in his farewell that he's leaving not from fatigue with writing, but from watching 'the same argument, in new outfits, for a quarter century.' Revisiting his 1999 freebsd-hackers email — where a trivial sleep(1) patch generated more traffic than importing a new filesystem — he shows that Parkinson's 1957 Law of Triviality still governs how engineers allocate attention, from mailing lists to modern Slack channels.
By submitting PHK's farewell to HN where it drew 143 points and 143 comments, the submitter surfaces the piece as culturally significant — a recognition that the bikeshed concept remains as operationally useful for staff engineers today as it was for FreeBSD committers in 1999.
Poul-Henning Kamp — known universally as PHK — has filed his final column for ACM Queue. The title, *Goodbye, and Thanks for All the Bikesheds*, is a Douglas Adams nod stacked on top of the term he dragged into the engineering lexicon in October 1999, in a now-legendary email to freebsd-hackers with the subject line "A bike shed (any colour will do) on greener grass...".
For readers who came up after the fact: PHK is a longtime FreeBSD committer (he wrote the Beastie disk-encryption layer GBDE, jails-adjacent tooling, the memory allocator phkmalloc, and large chunks of what your BSD-flavored infrastructure quietly relies on), the creator of Varnish Cache, and, for the last decade-plus, one of ACM Queue's most reliably grumpy long-form columnists. His writing has been the rarest thing in tech media: a working systems engineer talking honestly about working systems, without a product to sell or a conference keynote to promote.
The farewell piece revisits the original bikeshed email — the one where a trivial patch to `sleep(1)`'s argument handling generated more list traffic than the actual decision to import a new filesystem — and traces how the metaphor escaped the FreeBSD list, colonized Wikipedia, and eventually ended up in the mouth of every staff engineer trying to shut down a color-of-the-button debate in a Slack channel. PHK's point in leaving is not that he's tired of writing. It's that he's tired of watching the same argument, in new outfits, for a quarter century.
Parkinson's Law of Triviality — the original idea PHK was riffing on — dates to 1957. Parkinson noticed that a committee approving a nuclear reactor would rubber-stamp the reactor in minutes and then argue for an hour about a bike shed for the staff, because everyone had an opinion about bike sheds and nobody had an opinion about reactors. PHK's contribution was giving working programmers a two-syllable weapon they could deploy in code review: "this is a bikeshed." It ended more pointless threads than any style guide ever written.
The reason the term stuck for 25 years is that the pattern is structural, not cultural. Any technical decision has a difficulty gradient: some parts are hard, some parts are easy. Engineers are, on average, conflict-averse about the hard parts (where being wrong is expensive and public) and combative about the easy parts (where being wrong costs nothing). The result is that group attention flows *away* from the decisions that matter. Tab-vs-spaces is not the pathology — tab-vs-spaces is the *symptom* of a group that has already tacitly agreed not to fight about the load balancer.
Read the original 1999 email now and it lands differently than it did then. PHK wasn't just complaining about a sleep(1) argument. He was describing what happens when a mailing list optimizes for participation over outcome — a problem GitHub Discussions, Slack, and every AI-coding-agent Discord have inherited and made worse. The bikeshed doesn't scale down with team size; it scales up with the number of people who feel entitled to an opinion, which in 2026 is effectively everyone with a keyboard and a Claude subscription.
There's a second, quieter thing worth noticing about PHK leaving. ACM Queue is one of the last places on the internet where a working engineer can publish 3,000 words on a systems problem without a marketing team rewriting the headline. The genre — call it the practitioner essay — is thinning out. Julia Evans still does it. Dan Luu still does it. Fabien Sanglard still does it. But the pipeline that produced people like PHK — mailing lists, USENIX, long-form journals, decades of the same commit access — isn't producing replacements at the rate it used to.
If you run code review, the most useful thing you can steal from PHK's exit is a diagnostic question, not a rule. When a PR discussion has more than five participants and more than twenty comments, ask: *what's the reactor here, and what's the bike shed?* If the thread is 90% about naming, formatting, or which existing utility to reuse, and 10% about the actual invariant the change is trying to preserve, you have a bikeshed. Kill the thread, ship the reactor, name the bikeshed a bikeshed in the merge commit if you have to.
The same test works for architecture review, RFC comments, and the increasingly common ritual of arguing about your team's Cursor rules or Claude Code instructions. If your AGENTS.md file has been touched more times this quarter than your database schema, congratulations: you've built a very sophisticated bike shed. The LLM tooling wave has produced a new class of bikeshed that PHK couldn't have anticipated in 1999 — arguments about prompt style, tool budgets, and model routing that feel technical, generate strong opinions, and rarely affect the shape of the system being built. Notice them, name them, move on.
One thing PHK himself has been consistent about, and worth internalizing: the answer to bikeshedding isn't authoritarianism. It's ownership. The reason the sleep(1) thread went sideways in 1999 was that no one owned sleep(1). The reason your button-color thread goes sideways in 2026 is that no one owns the design system. Give the bikeshed a single owner with veto power, tell everyone else the decision is delegated, and the thread evaporates. This is boring management advice, which is exactly why engineers avoid it.
PHK is 59, still committing to FreeBSD, still running Varnish's commercial arm, and has been clear he isn't retiring — just retiring from the Queue column. The bikeshed will outlive him, the column, and probably the ACM. That's the joke embedded in the farewell title: he didn't invent the phenomenon, he just gave it a name catchy enough that we can't forget it, and now every generation of engineers gets to rediscover it in whatever new venue we've built to argue in. Mailing lists. IRC. GitHub. Slack. Discord. Cursor rules. Whatever comes after. Same reactor. Same bike shed. Different paint.
Top 10 dev stories every morning at 8am UTC. AI-curated. Retro terminal HTML email.