beauty is the residue of understanding; value is the residue of care.

2025 marks ten years since I started programming (5 years as a hobbyist, 5 as a professional). I started it as a hobby in middle school and somehow managed to make it my career.

I was influenced a lot by Peter Norvig’s Teach Yourself Programming in Ten Years when I started, feels surreal to write this after almost a decade.

I was struggling with this piece until I read this essay which gave me a beautiful through-line to connect all these thoughts.

The most satisfying change I made this year was a deletion.

No new feature, no clever abstraction, just revisiting a fragile branch and replacing it with a simpler one, deleting most of it. The system became simpler. Cleaner abstractions, fewer edge cases.

Craft felt like subtraction, and it looked calm.

I didn’t start here though, I was part of a scrappy team in a startup trying to get to product-market-fit. I started fast: big PRs, large confidence, adrenaline as process.

Cleverness looked like progress because it moved the graph. I shipped by duct tape and heroics, and felt invincible until the bill arrived. Hidden costs collected in corners: flaky tests that failed only when I needed them most, names that hid intent, code seemed dead but somehow still shaped behavior.

Speed without comprehension is just deferred pain, code that can’t be reasoned about slows everyone (even agents), especially our future selves.

So I slowed down on purpose.

Practice became a loop I could trust: name, test, refactor, delete. I wrote to think, and tests became letters to future me, little contracts to lean on when memory failed. I shipped small and reversible. I looked for seams, split behavior cleanly, and defined boundaries by their promises instead of their internals.

I measured twice: dry runs, feature flags, shadow writes. The thrill of novelty gave way to the steadiness of boring tech. Minimal machinery with maximal clarity wasn’t decoration; it was how speed becomes sustainable.

With time, the job felt less like heroics and more like stewardship. I cared about rollback plans, a lot. I wanted to delete more than I added. I wrote runbooks and optimized feedback loops: fast tests, fast CI, tight local iterations.

I tried to make change cheap.

Resilience stopped being a slide and became a sensibility, design for failure paths first, prefer reversible moves, assume partial outages, keep the blast radius small. Observability wasn’t an afterthought or a dashboard; it became the way the system spoke, a language for telling us how it felt and where it hurt.

Deliberation wasn’t slowness; it was the discipline that let us go fast without breaking ourselves. The craft move wasn’t to wait, it was to stage risk, to isolate it, to run in shadow, to toggle, to keep pull requests small enough to reason about.

“Slow is smooth and smooth is fast”.

A good migration plan mattered more than a new pattern. Deleting an abstraction shipped more value than polishing it. Quality turned out not to be a vibe but a set of small constraints that compound.

Constraints like the following:

• Use names that tell the story; if the name feels vague, the design probably is.
• Keep surfaces as small as possible. Fewer methods, narrower contracts, less to hold in your head.
• Prefer simple data and composition over deep inheritance. Make invariants explicit and write tests that freeze them in place.
• Choose boring tech that keeps edges sharp.
• Default to deletion, if it isn’t pulling its weight, remove it.

Beauty emerges, if it’s going to, as the residue of these kind of choices, the clarity that remains when you stop trying to be clever and start trying to be understood.

Under pressure and chaos, craft shows itself. The systems I’m proud of degrade gracefully, they tell us what’s wrong, they can be steered back without heroics and fire-fighting. Calm systems keep teams humane.

And then there’s the problem itself. A beautiful solution to the wrong problem is a perfect answer to a question nobody asked.

Ten years taught me to front‑load definition: talk to users, read the transcript, trace the workflow, cut scope, argue, say no. Ship less but correct. When the problem is crisp, execution becomes honest. Outcomes over output. Speed lives in feedback loops.

I’m still unsure about a few things

• When to embrace novelty for long‑term leverage versus when to double down on the boring proven path ?
• How to measure craft without turning it into theater ?
• How to align incentives so deletion and risk‑reduction are celebrated instead of quietly undervalued ?

But I’m clearer about what I’m aiming at: systems and teams that feel calm (eventually). Places where beauty and value show up not because we chugged redbull, did 996 and chased them, but because we practiced deliberate understanding and care long enough for their residue to remain.

I really love this video by Linear talking about this idea of calm.

Amidst all this, the future of writing code feels more dichotomous than ever.

On one hand, I deeply resonate with essays like “Craft Is the Antidote to Slop”. The argument that craft and taste are the last standing and critical pillars of good software in a world where slop is abundant¹. Personally, I want to see good, thoughtful and useful software still being built².

On the other hand, reality is less romantic.

Most software doesn’t need craft. It needs to exist, to work well enough, to solve today’s problem before the requirements change tomorrow. The world runs on duct tape and heroics, and it mostly works. Craft is expensive, and in a world where LLMs can generate functional code in seconds, the economic case for deliberate slowness gets harder to defend.

Honestly, the real tension isn’t craft versus slop, but craft versus pragmatism. The question isn’t whether to care, it’s what to care about and when. Not every system needs to be calm. Not every abstraction needs to be beautiful. Sometimes good enough ships, and perfect never does.

Users don’t see your elegant deletion, they don’t feel your careful migration plan, they don’t know you chose boring tech. They see whether it works and whether it helps them.

So where does that leave us?

Craft isn’t about making everything perfect; it’s about knowing which problems deserve understanding and which ones just need solving. It’s about building the capacity to move fast when it matters because you moved deliberately when you could.

Ten years in, I’m less interested in being spot-on about craft versus speed and more interested in systems that don’t break people.

The residue metaphor still holds, you can’t force beauty or value, but you can create the conditions where they’re likely to emerge. Practice the constraints. Delete more. Keep feedback loops tight. Care about the right things. And ship.

---

Notes

Special thanks to Komal Tiwari, Hrushikesh Dokala and Sanil Khurana for reading drafts of this post and providing feedback.