Technology Changes Quickly. Good Principles Don't.

There is a shelf in my office with books about technologies that no longer matter. I keep them deliberately. Every one of them was, at the time, essential — the thing you had to know, the skill that separated the serious from the dabbling. Collectively they represent several years of my life spent learning things that expired.

I do not regret the learning. But somewhere in the middle of that shelf I started keeping a different kind of note: not what the tool did, but what the tool taught. Those notes have not expired. They apply to work I do now with systems that did not exist when I wrote them, and they will probably apply to whatever replaces those.

The half-life of a tool is a few years. The half-life of a principle is a career.

Understanding beats memorizing

The people who navigated each transition well were never the ones who had memorized the most. They were the ones who understood why things were built the way they were. When the specific syntax became irrelevant, their understanding transferred, because the underlying problems — state, naming, coordination, failure — did not change. Only the vocabulary did.

This is a practical instruction about how to spend your attention. When something new arrives, resist learning it as a procedure. Ask what problem it exists to solve and what it gave up to solve it. Every tool is a trade, and the trade is the durable knowledge. The procedure will be obsolete before you have finished getting good at it.

Naming is thinking

This has been true in every medium I have worked in and it survives every change of tooling. When a team cannot agree on what to call something, the disagreement is never about the word. It is about the concept, and the concept is unresolved.

The temptation is to settle it quickly — pick something, move on, we can rename later. You can rename later. You cannot un-ship the confusion, because by then the ambiguous concept has been built into four screens, two tables, and everyone's mental model of the product. Arguments about naming are the cheapest arguments available. It is worth having them for longer than feels comfortable.

Constraints produce quality

Unlimited resources produce mediocre work with astonishing reliability. This is not a moral point about hunger; it is a structural one. Constraints force prioritization, and prioritization is where quality comes from. When you can do everything, you never have to decide what matters, and a product where nothing was sacrificed is a product where nothing was chosen.

The corollary for anyone with sufficient resources: invent the constraints. Fewer people than you could afford. Less time than you need. A smaller scope than you can defend. This feels perverse and it consistently produces better outcomes than the well-funded alternative, which is why small teams keep beating large ones at things the large ones should easily win.

The obvious thing is usually right

Clever solutions have an appeal that has nothing to do with their merit. They demonstrate the builder's ability. They are enjoyable to construct. And they are, almost always, worse than the obvious approach, because the obvious approach is understood by everyone who will encounter it later, including you in eighteen months.

The exception is real: sometimes the obvious thing genuinely does not work, and then cleverness is required and welcome. But the test should be applied honestly. Most cleverness is deployed against problems the boring solution would have handled fine, and the cost is paid by whoever maintains it.

Write for the person who will read this in eighteen months. It will probably be you, and you will have forgotten everything.

Trust is the actual currency

Across clients, colleagues, and users, the pattern is identical. Trust is built slowly through unremarkable consistency, and it is destroyed quickly through a single significant lapse. It does not rebuild at the rate it built the first time; it rebuilds slower, because now there is history.

Nothing about technology alters this arithmetic. Faster tools let you break trust faster. They do not let you build it faster, because the building is made of elapsed time and repeated behavior, and neither of those can be accelerated by better software.

Finish things

The most reliable predictor of whether someone produces good work over a decade is not talent or taste. It is whether they finish. Finishing teaches things that starting cannot, because the last ten percent contains all the reality — the edge cases, the compromises, the discovery that your elegant idea has a problem you can only see from the end.

A person with ten finished mediocre projects knows more than a person with fifty brilliant beginnings. This has always been true and no tool has ever changed it, though every generation of tools has produced a wave of people who hoped it might.

Why this matters now

We are in a period where the tools are changing fast enough that keeping up feels like a full-time occupation, and for some people it has become one. The anxiety this produces is real and largely misdirected.

The specific capability of any given system will be surpassed. What will not be surpassed is knowing what to build, being able to say clearly what you mean, understanding why a design works, finishing what you start, and being the kind of person others can rely on. Those were the differentiators before, and every acceleration in tooling has made them more valuable rather than less, because the tooling handles more of everything else.

The shelf will keep growing. It is a good shelf. But the notes are the part I would save.

If you are trying to decide what is worth learning right now, that is a better conversation than most. I am happy to compare notes.