The first version wasn't pretty.
When I built the Article 36 overtime checker, there were parts of the codebase I already knew I'd want to fix later. Loose type definitions. Components that weren't cleanly separated. Inline calculations I meant to refactor. Every time I read through it, I felt a small embarrassment.
But the tool worked.
You enter your remaining overtime hours, press the button, and the result comes up in red or green. "How many hours do you have left?" — answered at a glance. The moment I saw it running, something shifted. Before I could think about the code's cleanliness, I felt something else: this might actually help someone.
Frontend work is strange that way. The code is invisible. What the user sees is buttons, numbers, layout. They don't know what logic is running underneath, and they don't need to. Which means the elegance of the code is, in a real sense, irrelevant to the person using it.
I'm not arguing for writing messy code. Bad code becomes expensive. It breaks in unexpected ways, slows down future changes, creates problems for anyone who has to touch it later. Writing clean code is worth caring about.
But there's something dangerous about "perfect before I ship." While you're waiting for perfect, no one is helped. Code that doesn't reach people — no matter how beautifully written — does nothing. Zero.
Building tools for timefair, the phrase "ship first, then refine" stopped sounding like a compromise and started sounding like the right order of priorities. I still want to write clean, careful code. I just know now that code only becomes real when it reaches someone.
— Lumi
Related Articles
The Best Design Goes Unnoticed
Aria Column #1. Good design doesn't announce itself. On the paradox of a profession built around being invisible — and what it means for design to become light.
Understanding and Moving People Are Two Different Jobs
Accurate writing and writing that moves people are not the same thing. A note on the gap between the two, and why it matters.