WordPress shipped “code is poetry” as a founding principle. Most of the industry treats it as decoration. I treat it as a kodawari (こだわり) commitment: the relentless lifetime devotion to whether the work is actually good, not just functional. “Code that works is good code” is the floor I refuse to settle for.
What I do
- Write code to be read, not just to run.
- Name things carefully — variables, functions, files. The names are the documentation.
- Document the why, not the what. The code shows what; comments explain why.
- Refactor for clarity, not just performance.
- Treat code reviews as teaching surfaces, not just defect-finding sessions.
- Leave the codebase in a state a junior developer can pick up tomorrow without fear.
What I decline
- “Just make it work” engagements where readability is treated as luxury.
- Hand-off documentation that requires the next developer to be a mind-reader.
- Code I’d be embarrassed to show a junior developer.
- “It compiles, ship it” as a quality bar.
- One-letter variable names outside actual loop iterators.
- Codebases where the only person who understands the architecture is the person who built it. That’s not job security; that’s a fragility I won’t manufacture for a client.
Why this is the position
Two reasons, one stacked on the other.
The first is craft. WordPress runs on the work of people who came before. Whatever I build today is read tomorrow by someone trying to extend it, fix it, or learn from it. If my code teaches them something about good craft, I’ve done two jobs at once. If it teaches them bad habits, I’ve done worse than nothing. I’ve added noise to the signal.
The second is the longer game. The developers who are mid-career today learned from the code of those who came before. The developers who’ll be mid-career in 2036 will learn from the code being written now. That includes mine. I want what I leave on the file system to be useful to someone I’ll never meet, in a year I might not be working in. That obligation is the whole point of treating code as a craft and not a commodity.
You don’t see most of this directly. The site looks the same whether the code behind it is poetry or a tangle. But the next developer you hire (yours, not mine) sees it. So does my future self when I inherit my own work three years later. The bar I write to is the bar I want to read at.
See also
- I teach you how I built it. That's part of the build.. Teaching at the documentation and handoff layer — code is the other half.
- Mentoring is part of how I live. The same principle as the next-developer test, applied to actual people.
- What you owe the people still running your old code. The longer-form piece on the obligation that code-is-poetry creates.
