What I optimize for has shifted, and the older preferences were defensible at the time.

I optimized for capability, because capability is the easiest thing to demonstrate. I optimized for elegance, because elegance reads well in review. I optimized for speed, because speed is the only metric a project tracks before it ships. Each was reasonable in the room where it was decided. None of them were quite what the system needed a few years in.

What changed was not a framework or a principle. It was rereading code I had written a few months earlier and noticing the cost of choices I had already half-forgotten.

The first thing I would tell my younger self is to leave more things concrete.

The instinct to generalize is strong in engineering culture. It is rewarded in interviews. It is rewarded in code review. It is sometimes the difference between a junior and a senior label. But generalization paid up front draws against a future you have not yet seen.

Most of the abstractions I am embarrassed by were correct generalizations of the cases I knew at the time. They were not careless. They were premature.

A concrete piece of code can be generalized later, when the second and third use cases reveal what they actually share. A generalization written before those cases exist tends to fit the first case and constrain the next two.

I now prefer to copy three times before extracting once. The copies look ugly during review. They survive change better than the abstraction that would have replaced them.

The decisions that have hurt me most were not bad decisions. They were good decisions that could not be undone when context shifted.

A vendor lock-in chosen for speed. A schema choice that propagated through a hundred call sites before anyone noticed. A platform commitment that made sense for the team at the time and outlived three reorganizations.

Each was reasonable. Each became expensive in a way that had nothing to do with the original analysis.

I now apply a different filter before committing. Not "is this the best decision," which is rarely answerable, but "if this turns out to be wrong, can the people who inherit it actually undo it." That second question has changed more of my choices than any architectural principle.

The honest version of this filter is uncomfortable. It treats most of my own decisions as hypotheses I expect to be partly wrong about. It builds for a team that will know things I do not. It accepts that the present moment is rarely a good vantage point for long decisions.

One of the largest unforced costs in long-lived systems is deferred clarity.

A team disagrees about what something means. The disagreement is uncomfortable. The conversation is postponed. The system is built. The disagreement settles into the code as ambiguity. A year later, two parts of the system operate on incompatible interpretations of the same word. Five years later, a new engineer is told that nobody really knows why it is this way.

The cost of clarifying early is small. It is one awkward meeting, one written paragraph, one explicit decision. The cost of clarifying late is structural. It is rewrites, migrations, and an accumulating tax on every new contributor.

I now treat unresolved ambiguity as a defect with the same weight as a bug. Not because clarity is virtuous, but because ambiguity compounds quietly and is invisible until it is structural.

The most useful question I ask in design conversations now is not "what should we build." It is "what would we have to agree on for this to make sense in three years." If the answer requires a long pause, the design is not ready.

This is not a retreat into caution.

I still build things. I still ship. I still make choices I will not be able to defend a decade from now. The change is not in tempo. It is in what I am willing to spend the future's optionality on.

I am more willing to spend it on concrete things that work and can be replaced. I am less willing to spend it on abstractions that promise reuse. I am more willing to spend it on small commitments that can be undone. I am less willing to spend it on architectural bets that lock in a reading of a problem I do not yet fully understand.

The three preferences pull against each other often enough that this remains a posture, not a procedure. The work is in deciding, case by case, which one is paying more than it is asking.

The net effect is fewer impressive moments and more boring weeks. I have come to read that ratio as a leading indicator, with a caveat I have earned the hard way: boring is not the same as healthy. Sometimes uneventful weeks are a system whose quiet failure modes have not yet surfaced. The most durable systems I know look uninteresting in their day-to-day. The prior is not proof.

There is a posture I want to avoid here.

It would be easy to claim that what I optimize for now is what I should have always optimized for, and that the earlier versions of these preferences were errors. That framing is unfair to the engineer I was.

I could not have arrived here without the years of optimizing for the wrong things. The judgment I have now is the residue of a hundred small surprises, each of which would have read as exaggerated caution if it had been advice.

What I optimize for now is shaped by what I have already done. The same will be true a decade from now. The next version of these preferences will read back on this version as incomplete. That is the expected case.

If I had to compress this into one frame, it would be this.

Earlier in my career I optimized for the system I was building. I now optimize for the system that will exist after me.

Those are not the same system. The first one only has to ship. The second one has to be lived in by people whose names I do not know, against constraints I cannot predict, using context that has eroded.

Optimizing for the second system looks slower in the short run. It looks indistinguishable from over-caution to anyone whose horizon is the next release. It is rarely the thing that gets celebrated.

It is the optimization that compounds in the direction I now choose.

The first eleven weeks of this arc were about the patterns underneath these preferences — time as a constraint, simplicity as a posture, judgment over imported rules, the cost of cleverness, the weight of irreversible choices, the demands of ownership, the regret of decisions that aged badly, the information in systems that surprised me.

Fewer abstractions. Fewer irreversible decisions. Earlier clarity.

That is the trade. I have chosen it knowing what it costs, and I expect to choose it again knowing more.