Why I write code the way I do

There is a version of software engineering that treats code purely as a means to an end. Write something that works, ship it, move on. I understand the appeal — the business doesn't care how readable your function names are.

But I can't do it that way. Not because I think slow and careful beats fast and rough — I've shipped things over weekends that I'm still proud of. It's more that I believe the quality of attention you bring to the work shows up somewhere, eventually.

What I mean by craft

When I say craft, I don't mean perfection. I mean the small choices that nobody asked you to make: picking a variable name that communicates intent instead of just being correct, writing a comment that explains why instead of what, structuring a module so its seams reveal something true about the problem.

These things don't take much longer than their alternatives. They just require actually thinking about what you're doing while you do it.

The code you can read six months later

The most useful test I've found: will future-me understand this without rereading everything? Not just the code — the reasoning. Why was this written this way? What constraint was being navigated?

A well-named function is a sentence in a story. The best codebases I've worked in read like thoughtful prose. The worst read like someone left the first draft.

On speed

I want to say something careful here because "care about craft" can slide into "be slow and precious about everything."

Speed and craft are not opposites. The engineers I most admire are fast because they care about craft — clean code is easier to change, easy-to-read tests catch regressions faster, modular architecture lets you swap things out without unraveling everything else.

The tax you pay upfront for being intentional returns compounded over the lifetime of the code.

This is something I'm still working out, honestly. There are weeks where I move fast and something feels off, and weeks where I'm too careful and it's frustrating. The balance shifts by project, by deadline, by what the code is for.

But I keep coming back to the idea that caring about the work — genuinely caring, not just performing care — is the thing that makes this job feel like something worth doing.