Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

Writing the Fear Out in Full
What Actually Goes Stale — Three Layers
Conditions Under Which Experience Becomes an Asset
Conditions Under Which Experience Becomes a Liability
The Part That Does Not Get Softened
The One Hour That Builds a Shelf-Life Table
When This Advice Does Not Apply
Further Reading

Writing the Fear Out in Full

As the years accumulate, the shape of the anxiety changes. If the junior version was "will there be a place to start," this version is closer to "when does the place I am standing on disappear."

Written out to the end, it usually reads like this. What I built over ten years looks like it will be worth nothing in a few more. And when that happens, the time and stamina to learn from scratch will not be what they are now. Two different fears are stuck together. One is depreciation of an asset. The other is a decline in the capacity to reinvest.

This post will not tell you that both are groundless. Instead it separates what depreciates from what does not, and looks at the conditions under which the same experience becomes an asset or a liability.

What Actually Goes Stale — Three Layers

Sort knowledge by shelf life and three layers appear.

The surface layer. How a specific tool is operated, a framework's conventions, the names of APIs, the syntax of a config file. The shortest shelf life, and mostly relearnable in a few days. Yet this is the layer whose decay people feel most sharply, because it is visible.
The middle layer. Architectural patterns, how deployment and operations are done, how a team divides the work. It turns over on the scale of a decade and, interestingly, keeps coming back around. Centralized and distributed, one repository and many, running it yourself and handing it off have all traded places more than once. The value of someone who worked a long time in this layer is not knowing which direction is currently in fashion but knowing where each direction hurt.
The foundation layer. How data goes out of agreement with itself, what happens when the same thing is corrected in two places at once, the way networks fail quietly, when a cache betrays you, how to write a trade-off down in one sentence. This layer barely ages.

One honest caveat belongs here. Which layer gets shaken, and when, cannot be known in advance. Some of what is called the foundation layer may be absorbed into tooling over the next decade. What can be said is that depreciation has so far mostly run from the top down, which is enough to put weight on that ordering — not enough to guarantee it.

Conditions Under Which Experience Becomes an Asset

The same ten years are an asset to one person and dead weight to another. The difference comes from the form of the experience, not the quantity.

It has to be compressed. Organized as rules, not as cases. "This is what happened on that project" is a story; "when these conditions overlap, this approach breaks at this point" is a tool. Stories get used over drinks; rules get used in design meetings.
It has to be translatable. A lesson you can only state in the vocabulary of an old environment never arrives at the current team. You have to be able to restate the same principle in terms of the present stack.
It has to be transferable. Judgment that lives only in your head cannot grow past your own throughput. Only judgment moved to other people through documents, reviews, and design discussions compounds inside an organization.

Conditions Under Which Experience Becomes a Liability

The other side is just as concrete. Four forms show up often.

When "we used to do it this way" is the conclusion. Used as evidence it is information; used as a conclusion it becomes a device for stopping the argument.
When one incident became a permanent prohibition. The reason that approach failed then was usually not the approach but the conditions at that moment. If nobody rechecks whether the conditions changed, only the rule survives.
When the cost table was never updated. Much of an experienced engineer's judgment is made of a feel for costs, and the cost of storage, computation, transfer, and human time keeps moving. An optimization derived from an old cost table is a wrong answer by current prices.
When new tools get rejected instead of evaluated. Evaluation costs time. Rejection costs none. So the busier you are, the more your conclusions look like rejection, and after a few years that accumulates.

What the liability list has in common is not laziness but thrift. It is the repeated result of economizing on the cost of checking again, which is why it happens to diligent people too.

The Part That Does Not Get Softened

You hear often that the market carries a bias about age. How widespread it is and what form it takes are things this post has no verifiable numbers for, so it will not attach any. But even granting that the bias exists, the line between out of control and in control can still be drawn. What a hiring side believes is out of control. What you put out in a checkable form is in control.

Constraints on time and stamina are also real. The method of spending a whole weekend on a new technology in your twenties does not reproduce once caregiving and obligations attach. What shrinks there is the total, not the ability. And when the total shrinks, selection starts to matter — and choosing what to learn is something people who have worked a long time tend to do better.

What actually slows down and what speeds up differs from person to person. That is not a question this post can answer on your behalf.

The One Hour That Builds a Shelf-Life Table

One action is enough. Once a year, one hour.

On paper, write the ten things you currently count as valuable. Sort each into one of the three layers above. Then look at two things. If the list clusters in the surface layer, a large share of your current confidence is standing on ground that is replaceable in a few days. If the foundation layer is empty, filling it takes the longest and lasts the longest.

Add one more item. Once a year, handle a new tool as an evaluator rather than a user. Spend a few days, then report to the team on one page: how far it can be trusted and where it breaks. This does two things at once. It refreshes the surface layer, and it keeps the habit of evaluating rather than rejecting.

When This Advice Does Not Apply

In several situations the prescription above misfires.

If you work in an area where the stack really is frozen, the calculation differs. In fields where the pool of people who can handle an old technology keeps shrinking, scarcity raises the price. Chasing the new from that position can mean discarding your own advantage. Even there, though, one thing is worth checking: how many more years the organization running that system plans to keep running it that way.

If the distance to retirement is short, the math changes. Recommending the same reinvestment plan to someone with fifteen more working years and someone with three is not serious advice.

And if you are close to burnout right now, the list in this post becomes one more source of pressure. What is needed then is recovery, not a learning plan.