Reinventing the Wheel Makes More Sense Than It Seems

There's a quiet guilt many programmers know well: you spend hours building something, then doubt strikes—what if a far more robust solution has existed for decades, and you just don't know it yet? Are you wasting your time? Andrew Quinn, in a technical article about replacing a 3 GB SQLite database with a 7 MB FST binary, devotes a footnote to dismantling that guilt. Simon Willison rescued it on his blog on May 10th in a brief quotes entry that, in this case, delivers far more value than its length suggests.

The Prior Knowledge Trap

Quinn's argument is straightforward: paralysis over what already exists is a trap. You don't need to reinvent a thousand wheels, but zero isn't the answer either. His estimate, expressed with unusual intellectual honesty, is that between four and five reimplementations across most domains are enough to reach the true limit of what's known about a problem. In more rigorous fields, mathematics or theoretical computer science for instance, that number might approach twenty or thirty.

The underlying logic isn't about romanticizing wasted effort. It's that each time you build something from scratch, even if it exists elsewhere, you pose targeted questions that no tutorial poses for you. You learn which design decisions were made and why, what trade-offs each choice implies, where the real limits of the approach lie. Reading `awk` documentation teaches you what `awk` does; writing your own columnar text processor teaches you why `awk` is the way it is.

Why This Matters Now

This reflection arrives at a moment when the question "why build something that already exists?" has become more pressing than ever. With code assistants like Claude integrated into daily workflows, the cost of obtaining a working implementation for nearly anything has dropped to near zero. But that doesn't change the cost of understanding that code, or the value of having gone through the process of building it.

What Quinn describes isn't artisanal nostalgia or veiled criticism of modern tools. It's an observation about practical epistemology: the fastest path to the real frontier of knowledge in a domain isn't passive accumulation of others' solutions, but the combination of selective reimplementation with well-directed questions. The ratio between the two is the central argument.

Who This Matters For

This perspective proves especially useful for three types of people:

• Junior developers who feel they never know enough before starting. The answer isn't to study more before building; it's to build in order to study better.
• Teams training new members who wonder whether to assign real tasks from day one or prioritize structured learning. Quinn suggests that the most effective learning happens in the friction of solving concrete problems, not in contemplating already-solved ones.
• Anyone using AI assistants for programming who notices the generated code works but isn't fully understood. The tool doesn't eliminate the need to reinvent some wheels; it simply changes which ones deserve reinvention.

Quinn's original technical article, on FSTs as a storage alternative, is interesting in itself as an optimization exercise. But the footnote may be the most valuable part of the text for anyone new to this craft, or for those with years of experience who've forgotten why they started building things.

---

From our perspective, we share the central idea: guilt over reinventing the wheel is usually less productive than the wheel itself. That Simon Willison found it worth highlighting, given how much he reads daily, is recommendation enough.