ON WRITING SOFTWARE THAT LASTS.

Software has a way of outliving its original author’s intentions. Code written for a six-month project ends up running five years later, maintained by someone who wasn’t there for the original decisions. Writing software that lasts isn’t about predicting the future—it’s about leaving behind enough clarity that the next person can reason about it without reading your mind.

I. LEGIBILITY IS A FEATURE

The most underrated quality in a codebase is legibility. Not comments, not documentation—legibility. The kind where you open a file, read it top-to-bottom, and understand what it does without tracing five levels of abstraction.

This means naming things honestly. A function called processData is hiding something. A function called normalizeUserInputToStorageFormat is telling you exactly what it does. The extra characters are not noise; they are documentation that cannot go stale.

The same principle applies to structure. When a module does one thing, its name can say so. When it does many things, the name becomes a lie of omission—and the next engineer has to reverse-engineer your original thinking to understand what it actually contains.

II. FIGHT DEPENDENCY CREEP

Every dependency you add is a future maintenance burden. Libraries get abandoned. APIs break between major versions. Security vulnerabilities surface years after adoption. Before pulling in a package, ask: can I write this in twenty lines? If yes, write it. Own it. Understand it.

This isn’t NIH syndrome—use battle-tested libraries for battle-tested problems. Cryptography, date handling across timezones, complex parsing: reach for well-maintained packages. But resist the pull of convenience when a small, owned implementation is clearer and more controllable.

// Before: a dependency for a two-line operation
import { formatDate } from 'some-date-library';

// After: explicit, owned, no surprises
const formatDate = (date: Date): string => date.toISOString().slice(0, 10).replace(/-/g, '.');

The second version has no install step, no version drift, no dependency audit, and you can read exactly what it does. The tradeoff is real work when requirements change—but at least that work is legible and local.

III. DESIGN FOR DELETION

The best code is code you can delete. When you add a feature, think about how you would remove it. If the answer is “I’d have to touch fifteen files and hope nothing breaks,” the feature is coupled too tightly to the system.

Structure code so that removing a feature is a scoped operation. This discipline forces you to think about boundaries, interfaces, and responsibilities—which consistently leads to better design than starting from the implementation. The systems I’ve been most proud of are the ones where deleting a capability leaves a clean hole, not a crater.

Write for clarity first. Let the machine worry about performance second—it usually handles it better than you’d expect, and when it doesn’t, you’ll know exactly where to look.