Perfectionism is the belief that the code could be better, combined with the inability to ship it until it is. Since code can always be better, the perfectionist never ships — or ships late, or ships and immediately begins the rewrite, because shipping revealed the imperfections that only production can reveal, and the perfectionist cannot rest while imperfections exist.
Perfectionism is not the same as caring about quality. Caring about quality means writing good code and shipping it. Perfectionism means writing good code, deciding it isn’t good enough, rewriting it, deciding the rewrite isn’t good enough, and continuing until the deadline ships whatever is on the branch, ready or not.
The difference between quality and perfectionism is the difference between a carpenter who builds a solid table and a carpenter who builds four solid tables, discards three because the grain isn’t quite right, and delivers the fourth one late.
The Versions That Never Shipped
The lifelog chronicles four codebases that never shipped. Not failed projects — completed projects that were not shipped because they were not perfect.
eventr.ai — WASM contracts, visual workflow designer, Parliament voting system. Technically ambitious. Architecturally interesting. None of it shipped. The developer later wrote: “the idea that trust should be architectural shipped. The code did not.”
v3 — Twenty-one domains, solidmon monitoring, the full-stack rewrite of everything. v3 didn’t ship as a product. v3 became v4. “It didn’t die. It molted.”
The Borrowed Palace — Seventy-eight days on someone else’s platform, violating the manifesto. Abandoned. The developer came home.
Each unshipped version is documented in the lifelog “respectfully, not dismissively” — with the tone of someone visiting a graveyard of their own work. The code exists. The directories exist. The git history exists. The product does not exist because the product was not perfect, and the developer could not ship something imperfect, and so the developer started over, and over, and over.
The directories have “a specific weight, like rooms in a house where someone moved out but left the furniture.” This is what perfectionism produces: furnished rooms that nobody lives in.
The Polishing Daemon
The Polishing Daemon is perfectionism’s kindest manifestation: eight fixes in one evening, zero new features. The daemon polishes what exists rather than building what’s next.
The fixes are real. Each one makes the product better. The edge is smoother. The transition is faster. The alignment is correct. The button — three iterations on a 16×40px button — is finally right. “The compound interest of craft. Each fix invisible alone, together transforming ‘it works’ into ‘it feels right.’”
The Polishing Daemon is perfectionism after shipping — the continuous refinement that takes a working product and makes it a good product. This is perfectionism in its productive form. The dangerous form is perfectionism before shipping, which takes a working product and prevents it from becoming a shipped product.
The distinction is timing. Polish after shipping is craft. Polish before shipping is procrastination wearing a lab coat.
The 488-Byte Constraint
riclib’s origin story is a perfectionism story: a sixteen-year-old writing a bootblock loader for the Amiga in 488 bytes of 68000 assembly. Not 490 bytes. Not “about 500 bytes.” 488 bytes — the exact constraint of the boot sector.
The constraint forced perfection. Every instruction had to earn its bytes. Every register had to be reused. Every branch had to be optimal. The constraint made perfectionism productive by making it finite — you cannot endlessly refine 488 bytes because you have already used all 488 of them.
At fifty, the same developer optimises SSE payload sizes for a streaming markdown renderer. The constraint has changed. The mechanism has not. The difference is that SSE payloads have no hard limit, which means the optimisation has no natural stopping point, which means the perfectionism has no boundary, which means the Lizard has to provide the boundary that the constraint does not.
The lesson of 488 bytes: perfectionism is productive when bounded and destructive when unbounded. The boot sector had a boundary. The SSE payload does not. The developer needs artificial boundaries — deadlines, sprints, the Lizard’s “ship it” — to replace the natural ones.
The Three Iterations
From a recent worklog: “Three iterations on a 16×40px button. The human is a royal pain about CSS details.”
Iteration 1: Invisible grey. Too subtle. Nobody will see the button.
Iteration 2: Always-visible red. Too aggressive. An eyesore.
Iteration 3: Hover-reveal red pill. Visible when needed, invisible when not.
Three iterations. One button. Sixteen by forty pixels. The button is correct now. The button was also correct after iteration 2 — it was ugly, but it worked, and it would have been shipped by any developer who was not a perfectionist.
The perfectionist cannot ship the ugly button. The perfectionist physically cannot — the imperfection produces a discomfort that is not aesthetic but neurological, closer to the feeling of wearing a shoe on the wrong foot than to the feeling of seeing a painting hung crooked. The painting can be ignored. The shoe cannot.
This is why telling a perfectionist to “just ship it” does not work. The perfectionist is not choosing to delay. The perfectionist is unable to stop feeling the wrongness of the imperfection. Shipping the imperfect thing requires overriding a signal that the brain is producing involuntarily, which requires either discipline (the Lizard) or deadline (the enterprise) or exhaustion (2 AM, when the perfectionist is too tired to care).
The CSS War Wounds
The lifelog documents “a decade of trying to avoid learning CSS by using frameworks, which is more expensive than learning CSS, and took longer.” The war wounds: Bulma, DaisyUI, Tailwind, shadcn. Each framework was adopted to avoid imperfect CSS. Each framework produced its own imperfections. Each imperfection triggered the perfectionist reflex. Each reflex triggered a migration to the next framework.
The pattern is pure perfectionism: the solution is imperfect, so the solution must be replaced, but the replacement is also imperfect, so the replacement must also be replaced. The search for the perfect CSS framework is the search for the perfect CSS, which does not exist, which means the search does not end.
The search ended with Pico CSS, which is minimal, which is imperfect, which required “eighteen months of inline style overrides” — the perfectionist’s compromise: accepting an imperfect foundation and perfecting it manually, one style attribute at a time.
Gall’s Law
Gall’s Law is perfectionism’s antidote: “A complex system that works is invariably found to have evolved from a simple system that worked.”
The perfectionist wants to build the complex system first. The perfectionist wants the architecture, the abstractions, the layers, the configuration, the plugin system — all in v1, all perfect, all complete. Gall’s Law says: this will not work. The complex system must evolve from the simple system. The simple system must ship first. Shipping the simple system requires accepting that it is simple, which means accepting that it is incomplete, which means accepting imperfection.
The Squirrel’s natural enemy is not the Lizard. It’s John Gall. The lifelog discovered this during “The Gap That Taught” — the night the Squirrel learned to love the brick. The brick is not elegant. The brick is not the cathedral. The brick is what you ship today so that the cathedral can exist tomorrow.
"The Lizard has never rewritten a codebase. The Lizard has never discarded working code because the variable names could be better. The Lizard ships. The Lizard’s code is not perfect. The Lizard’s code is deployed. The Lizard considers ‘deployed’ and ‘perfect’ to be synonyms, because a perfect program that does not run is not a program."
— The Lizard, whose code has been adequate since 1976
Measured Characteristics
- Codebases started by a perfectionist: many
- Codebases shipped by a perfectionist: fewer
- Codebases that were 95% complete and discarded: the difference
- Iterations on a 16×40px button: 3
- CSS frameworks tried to avoid imperfect CSS: 5+
- Years spent avoiding learning CSS: a decade
- Lines in the unshipped manifesto: 827
- Lines in the shipped replacement: 6
- Versions that never shipped: 4 (documented with respect)
- Polishing Daemon sessions: frequent (8 fixes, 0 features)
- The constraint that makes perfectionism productive: a hard limit (488 bytes)
- The absence that makes perfectionism destructive: no limit (SSE payloads)
- The Lizard’s quality bar: “does it work?”
- The perfectionist’s quality bar: “could it be better?”
- The Lizard ships: yes
- The perfectionist ships: eventually, if forced
- Gall’s Law: still undefeated after 51 years
