There’s a version of technical debt you can see. Duplicated logic. Hardcoded strings. A class doing seven things at once. That kind shows up in a diff. You fix it with a clear conscience.

The other kind is invisible. It lives in the shape of the system. In the names that almost fit. In the abstractions that were close enough when you wrote them, but drift further from the truth with every new requirement. That debt doesn’t show up in static analysis. It accumulates in the heads of everyone who reads the code after you.

Marcus Aurelius wrote: don’t indulge in dreams of what you haven’t done — count what you have. Applied to code: stop imagining the clean refactor you’ll do someday. Look at what you’re writing right now. That is the only moment where choice exists.

Fëanor knew craft. The Silmarils were the pinnacle of what any maker could achieve — light captured in stone, three stars held in the palm. But he poured so much of himself into them that he could no longer see past them. The work became identity. When the work was threatened, everything else became negotiable. His sons swore an oath that ruined them all. What began as devotion to craft became bondage to it. The jewels didn’t corrupt him — the attachment did.

There’s a lesson there that has nothing to do with jewels. When you write a clever abstraction and become attached to it — resistant to feedback, reluctant to see it changed — you’re carrying something heavier than the code. You’re carrying the claim that your past judgment was correct. That it still is. That the context hasn’t changed.

It usually has.

The stoic move isn’t to stop caring about quality. It’s to care about quality without making it a possession. Write it well. Leave it. Let the next person improve it. The code is not you.

What you owe the codebase is your best judgment today, applied honestly, and then released. Not perfection. Not permanence. Just the integrity to do good work and the humility to know it will need to change.

The invisible debt is often made of attachment, not laziness.

What would it change about how you write code if you assumed the next person to read it will need to make it better — not just understand it?