Staying Employable for the Next Decade

Staying Employable for the Next Decade is a review habit rather than a skill list, because a list goes out of date and a habit does not. The inputs worth reading refresh on published schedules, roughly once a year for most of them. Your anxiety refreshes hourly, and that mismatch is the entire problem this chapter solves.

Key takeaways

• Employability is a stock of judgement plus visible evidence of it, not a checklist of technologies. Technologies are how you demonstrate the stock, and they get replaced on someone else's schedule.
• Four named inputs are enough: DORA's annual report, whose 2025 edition was announced 24 September 2025, Stack Overflow's annual developer survey, GitHub's Octoverse each autumn, and Indeed Hiring Lab's monthly labour snapshots.
• Two hours, twice a year, is the right size. A review that takes a weekend gets skipped, and a review that happens monthly is just anxiety with a spreadsheet.
• Trigger conditions matter more than the calendar. Four of them: your niche stops appearing in postings, you cannot diagnose a failure cold, nothing you decided in the last year survived, and your platform got worse rather than better.
• The provenance check from Chapter 2 is the filter on all of this, applied once per claim. This chapter is the schedule, and that chapter is how to weigh a single number.

Read this after Chapter 2, which is the filter this chapter depends on, and after Chapter 9, whose four dials are two of the trigger conditions below. Keep the division clear: Chapter 2 teaches how to weigh one claim, and this chapter is only about when to look and what to do with what you find.

Every few months a headline arrives that would, if true, change what you should do for the next five years. Some of those headlines are about a real finding. Most are a real finding with its qualifiers removed.

The failure mode is not belief. It is reacting to each one separately, which produces a career made of course corrections and no direction.

The fix is unexciting: decide in advance when you will look, what you will look at, and what would make you change course.

Employability is a stock of judgement, not a list of skills

Define it in a way that survives the next tooling shift.

Employability is the combination of two things: judgement that transfers between systems, and evidence of that judgement that a stranger can evaluate. The technologies you know are how the evidence gets produced. They are not the stock, and treating them as the stock is what makes a career feel precarious every time a framework loses favour.

Chapter 3's classification does the work here. The durable layer is the stock, the surface layer is the current demonstration medium, and contextual knowledge is neither, because it does not leave the building.

So the question a reassessment answers is not "am I using the current tools". It is whether the stock grew this year, and whether anyone outside your team could tell. Nothing else counts.

Anxiety refreshes faster than evidence

The reason a cadence beats vigilance is a mismatch in publication frequency, and it is worth seeing plainly.

The serious inputs on this subject arrive roughly yearly. DORA published its State of AI-assisted Software Development in September 2025. Stack Overflow's developer survey runs yearly, with the 2025 edition the current published one at the time of writing. GitHub's Octoverse arrived in late October 2025. The labour data is faster, with Indeed Hiring Lab publishing monthly, and academic work is slower still.

Commentary about all of it arrives continuously. So does the feeling that you are behind. The commentary produces that feeling rather than the evidence, and noticing the source of it is most of the cure.

Reading on a schedule converts the subject from a background hum into a task with an end. That is the whole benefit. It is larger than it sounds.

Four inputs, on their real intervals

Four sources cover the ground. More than that is procrastination dressed as diligence.

One live example, inside a single source. Indeed Hiring Lab's snapshot published 23 July 2026 puts US software development postings at roughly 73% of their February 2020 baseline, a decline of about 30%. Its 8 July 2026 post, cited in Chapter 1, gives about 27.5% below February 2020. Those are different cuts of one series. Pick one framing per decision and say which one you used.

The two-hour review, twice a year

Here is the artifact, sized so it actually happens.

Twice a year, block two hours. Spend the first thirty minutes on whichever of the four inputs has published since last time, reading the method section rather than the headline. Spend the next thirty on your own market, meaning postings for the work you would want next, looking at what they ask for rather than at how many there are.

Spend the third half hour on yourself, answering three questions in writing. What did I learn this year that transfers. What did I ship that somebody outside my team could evaluate. What can I no longer do without assistance that I could do two years ago.

Spend the last thirty minutes deciding one thing. Not five: one change to what you spend discretionary hours on, written down with the date. In my experience a review that produces five actions produces none, and a review that produces one produces one.

Triggers that force an unscheduled review

The calendar is the floor. These are the conditions that mean you look now, and they are judgement rather than research.

Four triggers. Any one is enough. Your specialism stops appearing in the postings you would want, which is a market signal and not a mood. You attempt a diagnosis you would once have done cold and cannot, which is Chapter 5's decay showing up in the only test that matters. Nothing you decided in the last year is still in force, which is Chapter 9's decision-latency dial reading badly. And your platform got worse rather than better over a year, meaning merge-to-production time went up, because that predicts the next two years of your effectiveness.

A fifth is softer and I still watch it. Two consecutive quarters in which you produced nothing a stranger could evaluate.

None of those is about the industry. All five are about your position in it, which is the only thing you can act on. What I have seen is that people monitor the industry closely and their own position not at all. That is inverted.

What to ignore on purpose

An explicit ignore list is as useful as a reading list. It is much shorter.

Ignore any figure that fails the four questions from Chapter 2, which in practice means most numbers in most articles about this subject. Ignore predictions with dates attached, including the confident ones, because nobody has a method for them. This book made none. Ignore capability demonstrations, since a demo is an existence proof and tells you nothing about the rate at which the same thing works on your codebase.

Ignore rankings of languages and frameworks as career guidance. They measure current popularity, which is the surface layer by definition, and they are usually reported without the sample being stated.

The one thing I would never ignore is a change in what the work itself consists of. Adoption numbers moved for three years without changing anybody's daily job much. The introduction of agents that run for hours did change it. That distinction is worth more attention than any percentage.

The measurement I keep on myself

One measure only. It is deliberately not a number about the industry.

The question I ask twice a year is whether I could still form a correct hypothesis about an unfamiliar failure without help, on a real system, inside thirty minutes. That is the Chapter 5 practice used as an instrument rather than as an exercise. It is uncomfortable precisely because it is the ability most easily lost and least visible in output.

I keep it because it is the closest thing I have to a leading indicator. Everything else I could measure about my own work, throughput, review load, decisions made, is a lagging indicator that looks fine right up until the year it does not.

This is the pattern I trust, and I cannot prove it to you. It is one person's instrument, offered as a shape you might adapt rather than as a finding.

What would falsify this book

A career argument that cannot be wrong is not worth reading, so here is the list, and it is short on purpose.

This book is wrong if hiring recovers in an entry-weighted way rather than a senior-weighted one over several years. It is wrong if measured productivity gains concentrate in the most experienced rather than the least. It is wrong if generated code starts requiring less checking per unit rather than more, and if delivery stability improves with adoption rather than degrading. And it is wrong if comprehension becomes cheap, meaning tools that reliably explain an unfamiliar system well enough that a human need not build their own model of it.

All five are checkable. The last is the most plausible of them, and I would watch it hardest. If it happens, Chapter 4 becomes historical and much of Chapter 5 goes with it.

The model I would follow for this is the Stanford Digital Economy Lab's own behaviour. On 9 February 2026 they published a follow-up examining alternative explanations for their own headline finding, reporting that interest-rate exposure does not explain the pattern, that under firm-time fixed effects the decline is significant only after 2024, and that AI is not the sole determinant. Attacking your own conclusion in public is the standard, and it is rare enough that it should count for a lot when you see it.

The objection: this is a lot of process for a career

The strongest version is that four hours a year of structured review is bureaucracy applied to a life, and that people who do great work do not manage themselves this way.

There is truth in it. Nobody built anything worthwhile by reviewing their position. The review is not the work. It is also four hours against roughly two thousand, which is a rounding error, and the alternative is not spontaneity. The alternative is reacting to headlines, which is a schedule set by other people's publishing calendars.

The version of this objection I take seriously is different. Some people genuinely do not need it, because they are inside a fast feedback loop that tells them the truth continuously: a hard problem, a demanding market, colleagues who will say so. If that describes you, the cadence adds little.

For everybody else, and that includes most people in stable jobs at large organisations, the loop is slow and flattering. The review is a substitute for feedback the environment is not providing, and its cost is one afternoon twice a year.

Chapter summary

Employability is a stock of judgement that transfers between systems plus evidence of it a stranger can evaluate, and technologies are the demonstration medium rather than the stock, which is why a skill list dates and a review habit does not. The mismatch that causes the anxiety is publication frequency: the serious inputs arrive roughly yearly, with DORA's report in September 2025, Stack Overflow's survey yearly, Octoverse in late October 2025 and Indeed Hiring Lab monthly, while commentary arrives continuously and manufactures the feeling of being behind. Four inputs are sufficient, each with a stated blind spot. Even inside one source the framing matters, since Indeed Hiring Lab's 23 July 2026 snapshot puts US software postings at roughly 73% of the February 2020 baseline while its 8 July 2026 post gives about 27.5% below that baseline. The artifact is two hours twice a year: method sections rather than headlines, postings read for content rather than volume, three written questions about what transferred, what you shipped that was externally evaluable and what you can no longer do unassisted, then one decision with a date on it. Five trigger conditions force an unscheduled review, all of them about your position rather than the industry. An explicit ignore list covers unsourced figures, dated predictions, capability demonstrations and popularity rankings, while a change in what the work itself consists of is never ignored. And the falsification list is short and real, with cheap comprehension the most plausible of the five.

That is the book. Its argument in one line: producing code stopped being scarce and accountable judgement did not, so the work is to weigh the evidence about your own market yourself, learn the layer that survives a stack swap, read systems faster than you write them, keep the cognitive half of the job in unassisted practice, specify precisely enough to delegate, review as the scarce hour it now is, convert ambiguity into decidable work, choose an organisation that lets judgement compound, cross thresholds by changing what your output is, make the reasoning visible outside the building, and reassess on a schedule rather than on a headline. The measure of whether it worked is not that you predicted the shift. It is that on the day a decision arrived with no defined answer and no tool able to settle it, you were the person it was given to.