The half-life of a good tool
Three categories of tool exist in the working life of a professional: the tool you'll throw out in eighteen months, the tool you'll throw out in five years, and the tool that will, with mild adjustments, outlive you. Almost everyone confuses category one for category three.
hree categories of tool exist in the working life of a professional. The tool you will throw out in eighteen months, because some other tool with a better launch video will replace it. The tool you will throw out in five years, because the company behind it pivots, gets acquired, or quietly stops shipping security patches on the same Tuesday they post a "thank you for the journey" blog post. And the tool that will, with mild adjustments to your relationship with it, outlive you.
The first two categories are well understood. They are most of what you read about, most of what you buy, most of what you put in the what's in your stack footer of a portfolio site. The third category is almost never named, and it is — by an embarrassingly wide margin — the only one of the three that matters for a career that has to last forty years.
This essay is about how to tell which is which, before the eighteen months are up.
The deadpan list, with feeling
Here is what I have noticed, after twenty years of building software, watching shops rise and fall, and once accidentally leaving a job over a tooling argument that I later realized was actually a values argument in a hoodie.
Tools with a half-life of about eighteen months. The framework that was on every conference stage last summer. The build tool that fixed the previous build tool's biggest complaint. The CSS-in-JS library named after a Greek letter. The state management library named after a Norse god. The CLI tool that bundles four of last year's CLI tools. Almost every "rewrite of X" with a domain ending in .dev. The list is long. The list moves quickly. The list is, on the whole, unimportant — provided you do not mistake it for the long list.
Tools with a half-life of about five years. The major web framework you are willing to be associated with this decade. The cloud provider you reluctantly trust. The hosted database that has been around long enough to have outage postmortems on its blog. The IDE you currently prefer over the one you hated last year. The relational database from 1996 that you swore you'd replace and instead, twenty-eight years later, are running production traffic on. (You'll notice that as the half-life gets longer, the things on the list start sounding boring. This is the first signal.)
Tools with a half-life longer than your career. The shell. The text file. The Unix pipe. SQL. HTTP. Git, probably. Make, almost certainly. The keyboard. The terminal emulator. Regular expressions. The function. The list. The plain text email. The well-formed markdown document. The handwritten note on a piece of paper that you scan into the same plain-text format you've been using since you were nineteen. None of these will appear on a roadmap. Most of these have not had a major version bump in the lifetime of anyone reading this. They are not in decline. They are the deep stratum the entire surface industry sits on, and they have, accordingly, the stable property that the deep stratum always has: they keep working while the surface churns.
The arithmetic the deadpan list is trying to convey is this: most of your tooling literacy should be a portfolio, not a position. A few short-half-life tools to ship this year's work. A few medium-half-life tools to anchor the decade. A spine of long-half-life tools that will be there, unchanged, when the rest of your stack has rotated three times. The professionals I most admire are the ones whose long-half-life spine is the thickest. They look, from the outside, like they are behind. They are not. They are upstream.
Why the surface tools dominate the conversation
For the same reason short-half-life skills dominate job descriptions: they are legible. They have logos. They have launch dates. They have a package.json line you can put in a job posting. They are the only kind of tool the present moment can reward, because the present moment doesn't have the patience to evaluate anything older.
This is structural and not anyone's fault, but it produces a peculiar distortion: the visible tooling market is dominated by tools optimized for legibility, and the tools optimized for legibility are, by no coincidence, the ones with the shortest half-life. The vendors with the loudest launches have the most to lose from boredom; the tools that have already proven they don't need boredom (grep, make, the shell) have no marketing budget because they don't need one. So the conversation is, by construction, biased toward churn.
The professionals who get this wrong are the ones who treat the loudness of the conversation as evidence of the importance of the underlying tool. The professionals who get it right invert the signal: the louder the launch, the more carefully they evaluate whether the tool is in the eighteen-month bucket. They don't refuse it. They just don't bet their spine on it.
The three signals of a long-half-life tool
You don't get to see the half-life of a tool while you're choosing it. The vendors don't disclose it. The conference talks don't measure it. The benchmarks ignore it entirely. So you have to read the signals — the indirect properties that correlate with longevity — and weight your portfolio toward tools that show them.
There are, in my experience, three.
Signal one: the tool composes with everything below it. The shell composes with every tool that produces text. The pipe composes with every program. SQL composes with every dialect's data. These tools have the property that they do not require their environment to be like them in order to be useful. They take the world as it is. Compare to a tool that demands its own runtime, its own compiler, its own conventions, its own ecosystem of plugins — that tool is announcing, by its requirements, that it expects the surrounding world to bend toward it. The world will not bend. The world will rotate. The tool will rotate with it.
Signal two: the tool's mental model has not changed in a long time. When the thing a tool teaches you is stable across decades, that thing is almost certainly close to the structure of the underlying problem. When the thing the tool teaches you changes every two years — now we're using hooks instead of classes; now we're using server components instead of hooks; now we're using actions instead of mutations — what is being taught is not the underlying problem. It is the current vendor configuration of the surrounding ecosystem. The configuration changes. The structure of the problem doesn't. Tools with stable mental models are tools that have converged on the problem. Tools with churning mental models are tools that are iterating against the problem. You want both in your portfolio. You want to know which is which.
Signal three: the tool can be replaced by ten lines of code, and isn't. This one sounds backwards and is the most reliable of the three. Most long-half-life tools are embarrassingly simple in their core. The Unix philosophy is, basically, four ideas. SQL's algebraic core fits on one page. Make is a recipe-and-dependency engine you could write in an afternoon. They have endured not because they are clever but because the world has repeatedly tried to replace them with something cleverer and the cleverer thing has, repeatedly, lost. The tool that endures is the tool that is so close to the shape of the problem that any replacement either becomes it or fails to ship.
The tool that endures is the tool that is so close to the shape of the problem that any replacement either becomes it or fails to ship.
The four categories of tool you actually use
Once you can read the signals, the next move is to audit your stack. Most professionals have never done this. They have inherited a stack — from a previous job, a tutorial they liked, a conference talk that hit them at the right moment — and have not separately asked which slot each of those tools is filling.
A useful framing is to bucket your tools into four categories, by what they're for.
Production tools are the things you ship with. The framework, the runtime, the cloud, the database, the CDN. These should skew medium: long enough to amortize the learning curve and the operational scar tissue, short enough to evolve with the actual platform. A pure long-half-life production stack is not actually a feature; it is a sign you stopped paying attention. A pure short-half-life production stack is a sign you are only paying attention to the surface.
Authoring tools are the things you create with — the editor, the keyboard, the terminal, the local shell, the diff viewer, the way you take notes. These should skew long. Switching authoring tools is enormously expensive in muscle memory and in the small ergonomic adjustments you don't notice until they're gone. The professionals I admire have, in some cases, used the same editor for twenty-five years. The editor has changed. The way they relate to it has not. That stability, compounded daily for a career, is its own form of capital.
Coordination tools are the things you collaborate with — the issue tracker, the chat tool, the doc tool, the wiki, the version control, the code review. These are the hardest to choose well, because most of them are organization-imposed and most organizations have made the choice badly. Where you have a vote, vote long on the substrate (Git is forever; the hosted layer on top is not), and medium on the surface, and refuse to let any chat tool become your authoritative store of decisions. (The one that does will eventually be replaced; the decisions will go with it; the team will spend a quarter rebuilding what they thought they remembered.)
Thinking tools are the things you do not produce artifacts in but that change the shape of your thought — the notebook, the whiteboard, the long-form essay, the directed conversation, the walk. These should skew very long. The notebook has been around for about four thousand years. The whiteboard is about a hundred. The walk is older than the species. They have, between them, produced most of what we know. The professional who has no thinking-tools — who treats every cognitive operation as a candidate for the latest AI assistant — is operating with a flat brain.
Why the spine matters more than the surface
The reason the long-half-life spine is the thing to optimize for is not that the surface tools are bad. They aren't bad. They are necessary. You cannot ship 2026 software with only 1996 tools, and the people who try are usually doing performance art rather than working.
The reason the spine matters more is that the spine is what carries the surface across rotations. When the next framework arrives — and the next, and the next — the engineer with a thick spine spends a weekend learning the new framework and goes back to work. The engineer with a thin spine spends a year. Not because the engineer is bad. Because the framework was their identity, and the identity now requires reconstruction, not just retraining.
This is the deeper claim of the post: a tool's half-life is, in the working life of a professional, a psychological property as much as a technical one. The tools you build your competence on become the tools you build yourself on. Choosing a tool with a one-year half-life as your spine means rebuilding your professional self every year. Most people who do this don't notice they're doing it; they just notice that the work feels slightly more hollow each year, that they recognize fewer of their own commits from three years ago, that the discipline they entered no longer maps cleanly to the discipline they currently practice. That feeling is the half-life arriving, on schedule, unannounced.
The spine is what the half-life can't reach.
Some specific recommendations, with the obvious caveats
I will give you a list, as long as we both understand that lists like this are, by definition, the kind of legible artifact this essay has been arguing against. Use the list as a starting condition, not a destination.
A long-half-life spine I'd defend in court:
- The shell. Pick one (
bash,zsh,fish— doesn't matter). Use it daily. Read its manual page by page once a year, on a slow Saturday. Yes, the whole thing. - A version control system you understand below the porcelain. Git, almost certainly. Learn how it actually works, not just the seven commands. The mental model is the durable part.
- A relational database, and its query language. Pick one (Postgres is the conventional answer; MySQL is fine; SQLite is more powerful than people credit). Learn its query planner. The skill is portable across every database for the rest of your career.
- One programming language you have written in for a decade. Doesn't matter much which. Use it long enough to develop prose-level fluency. The fluency transfers to every other language you'll ever pick up.
- A text editor with a deep model. Vim, Emacs, or a modal-equipped derivative. The investment looks irrational at year one and pays for the rest of your career.
- Plain text and the file system. Markdown notes. Local files. Folders that survive vendors. A backup strategy. The most under-rated tool in the modern professional's life is a file you own, in a format you can still read in 2050.
A medium-half-life set worth investing in this decade:
- One major application framework. The current incumbent in your discipline. Re-evaluate every five years.
- One cloud platform. You will resent it. Learn it anyway. It is the operating system of contemporary work.
- One observability stack. Logs, metrics, traces. The specific vendor will rotate; the conceptual stack won't.
- One CI / deployment pipeline you have configured from scratch. Doing it once teaches you what every later abstraction is hiding.
Short-half-life surface to keep light:
- The current "hot" framework or library. Use it; do not love it. If you cannot tell, with your eyes closed, what part of your knowledge would survive its replacement, it is not yet a spine tool.
- The latest editor plugin / agentic IDE / CLI experiment. Try it; do not import its workflow into your spine until it has survived for at least two years and at least one major version of the underlying platform.
A late-night confession about the spine
I'll tell you the part I've never quite said in print.
I have, twice in my career, made the mistake this essay is warning you against. The first time was 2014. I had built my professional identity around a specific JavaScript framework that I genuinely believed was a generational shift. It was. It was also, by 2018, the kind of thing that came up in code archaeology. The version of me that was that framework was, by 2018, an aging artifact. I had to do the work of figuring out who I was without it. The work took about two years and was, in retrospect, the most expensive professional growth I have ever paid for, because most of the cost was paid in time I could not see I was paying.
The second time was 2020 — different framework, same shape of mistake, less excuse. I should have seen it coming. I had even written about avoiding it. I rationalized. I told myself this one was different. It wasn't different. It was just newer.
The reason I am qualified to write this essay is not that I made the right choices. It is that I have made the wrong ones twice and have, after the second time, finally taught myself to read the signal. The signal is embarrassingly simple in retrospect. Every time you find yourself saying this changes everything, slow down. Things that change everything do exist. They are extremely rare. They almost never have a launch event. They almost never look new. They almost always look, on first encounter, boring.
The boring is the signal. Boring is what passes the test of time, because boring is what other people are not, in their excitement, going to overwrite. The most important tools in your life, in ten years, will look boring to a junior engineer in 2036, in the same way that grep looked boring in 2016 and cat looked boring in 1996 and the Unix file system looked boring in 1986 and the relational model looked boring in 1976. They were not boring. They were load-bearing. The boring is the signature of the load-bearing.
If you remember one sentence from this essay, remember that one.
A closing observation about the people who picked the right tools
The thing I will say in defense of the engineers, designers, writers, and other working professionals who have somehow accumulated a stack that does not need to be replaced every two years: they look, from a distance, like they are not doing very much. The reverse is true. They are doing the harder thing. They are resisting churn. Resistance is invisible. Adoption is photogenic. The career rewards photogenic. The decade rewards resistance.
The good news is that the spine is buildable in any career, at any age, by anyone willing to be slightly out of step with the surface. The bad news is that nobody else is going to congratulate you for it, because the things you are choosing — the boring tools, the patient learning, the slow accumulation — are precisely the things the rest of the field has been trained not to celebrate.
The further good news is that you don't need to be celebrated for it, because in about ten years the work will speak for itself, and by then your colleagues will be the kind of people who can read it.
That's the trade.
- learning·2026-05-06·13 min
The half-life of a skill
Three things have a half-life: uranium-238, the enthusiasm of a new hire, and your knowledge of CSS. The third one is the only one most of us pretend isn't happening.
read essay → - taste·2026-05-07·16 min
Taste is the last moat
When every engineer can ship a feature in an afternoon and every designer can prototype in a sentence, the only thing left to compete on is what you choose not to build.
read essay → - learning·2026-05-06·3 min
The 30-second version of a skill's half-life
Most of what you know expires. The fix isn't to learn faster. It's to learn the part that doesn't.
read essay →
The half-life of a skill
Three things have a half-life: uranium-238, the enthusiasm of a new hire, and your knowledge of CSS. The third one is the only one most of us pretend isn't happening.
Taste is the last moat
When every engineer can ship a feature in an afternoon and every designer can prototype in a sentence, the only thing left to compete on is what you choose not to build.
// share this transmission
I write Sage After Dark after the studio closes for the day — one essay or one field note a week, sent Sundays at 21:00 ET. No tracking, no growth-hacks, no schedule outside Sunday.
If this piece moved something for you (or annoyed you), the reply line on every email lands in an inbox I actually read. The list is small on purpose, and the founding window is still open.
Sundays · one essay or one field note · no growth-hacks · unsubscribe in one click.