Engineering Leadership

Depth, Breadth, and the Half-Life of a Skill

Deciding what to learn deeply when the surface keeps moving under you.

Chapter 3 of 1312 min readOpen access

Depth, Breadth, and the Half-Life of a Skill is the chapter where the evidence from Chapter 2 gets spent on a bet you cannot easily unwind. Learning something deeply costs a year of evenings. Two clocks decide whether that year pays back: how fast the skill decays when you stop using it, and how fast the thing it describes gets replaced.

Key takeaways

  • A skill's half-life has two independent causes: decay through nonuse, and replacement of the thing the skill is about. Most career advice only discusses the second.
  • Arthur and colleagues' 1998 meta-analysis of 189 data points from 53 articles found skill loss growing from an effect size of about zero immediately after training to d = -1.4 after more than 365 days of nonuse, and found cognitive and accuracy-based tasks decay faster than physical and speed-based ones.
  • The durable layer is what stays true when the framework is replaced: complexity and data layout, network and protocol semantics, database and query planning, concurrency and failure modes, security. The surface layer is API shapes, SDK signatures, config formats and console layouts.
  • The surface moves faster than any study plan. GitHub's Octoverse, published 28 October 2025, records TypeScript becoming the most-used language on GitHub in August 2025 after adding over a million contributors, and 693,867 of the 1.1 million public repositories using an LLM SDK created within twelve months.
  • Deliberate practice is not the whole answer, and pretending otherwise is dishonest. Macnamara and colleagues' 2014 meta-analysis found it explained 26% of performance variance in games, 21% in music, 18% in sports, 4% in education and less than 1% in the professions.

Read this after Chapter 2, because the loudest claims about which skills are dying are exactly the claims that fail the four questions. Chapter 4 is the first durable skill treated properly, and Chapter 5 is how to keep the durable ones in practice while using tools that do them for you.

A framework major version lands and takes a week of the team's time. Nobody learned anything durable that week. The knowledge was replaced, not extended.

In the same quarter, one engineer spends four evenings understanding how the database chooses between an index scan and a sequential scan. That reading pays back three times in the next two years, in three unrelated systems, on two different engines.

Those two weeks cost the same. They are not the same investment, and the difference is not effort or intelligence. It is which layer the knowledge sat in. The details here are composited from ordinary team shapes rather than one team, and the shape is exact.

Half-life is measured against nonuse, not against fashion

Define the term properly, because the loose version leads to bad decisions. The half-life of a skill is the time after which half its usable value is gone, and two distinct mechanisms consume it.

The first is decay. You stop doing something and you get worse at it, in a way that is measurable and does not care how the industry is trending. The second is replacement. The system the skill was about no longer exists in the form you learned it, so the knowledge is intact and no longer applies.

Careers advice usually discusses only replacement, which is why it reduces to predicting the next framework. That is a losing game. Decay is the more tractable mechanism, because it is the one you control.

The two combine badly in one specific case: a surface skill you also stopped using. That is where five years of experience turns out to be worth less than the CV says.

The decay asymmetry that decides what to practise

There is a measured finding here and it is the most useful thing in this chapter, though it comes from outside software.

Arthur, Bennett, Stanush and McNelly published a meta-analysis in Human Performance in 1998, covering 189 independent data points from 53 articles. It is twenty-eight years old, and it is worth noting that its subject is a durable property of human memory rather than a fast-moving industry figure. They found substantial skill loss with nonuse, rising from an effect size of d = -0.01 immediately after training to d = -1.4 after more than 365 days without use.

The part that matters for us is not the size. It is the asymmetry. Cognitive, artificial and accuracy-based tasks were more susceptible to decay than physical, natural and speed-based ones.

Read that against what an assistant takes over. It does not take the physical act of typing. It takes the accuracy-based cognitive work: recalling the right structure, reasoning about the edge case, deciding what the correct output is. Those are the tasks the 1998 result says decay fastest under disuse, which is the mechanism Chapter 5 is built around.

The durable layer and the surface layer, and the test that separates them

There is a simple test that classifies any skill you are considering, and it takes one question.

Ask whether the knowledge would still be true if the framework, cloud vendor and language were all swapped tomorrow. If yes, it is durable. If no, it is surface, and it is not worthless: it is just rented rather than owned.

LayerContentsTestBehaviour over five years
DurableComplexity and data layout, network and protocol semantics, database internals and query planning, concurrency and failure modes, security reasoning, systems debuggingSurvives a full stack swapDecays slowly, transfers between employers, compounds with each new system
SurfaceFramework APIs, SDK signatures, config formats, CLI flags, console layouts, one vendor's deployment modelDies with the vendor decisionReplaced on the vendor's schedule, and generated competently on request
ContextualThis company's domain rules, its data quirks, its historical decisionsDies when you leaveHigh value in place, near zero portability, and often mistaken for depth

The third row is the one people misread. Deep knowledge of one employer's systems feels exactly like expertise from the inside and does not travel.

The surface moves faster than any study plan

Two numbers from GitHub's Octoverse report of 28 October 2025 make the point better than an argument would.

TypeScript became the most-used language on GitHub in August 2025, having added over a million contributors in the period, up 66%. And of the 1.1 million public repositories now using a large language model SDK, 693,867 were created within twelve months, a rise of 178%.

Those are first-party platform figures from GitHub about GitHub, which is the right caveat to carry. The direction is still unmistakable. A surface you chose to specialise in two years ago may not be the surface the work is happening on now, and no amount of diligence gets ahead of that.

Which is the actual argument for depth, and it is not a moral one. Depth is the only position from which surface acquisition is cheap. An engineer who understands transactions and isolation levels learns a new object mapper in a day. An engineer who knows one mapper learns the next in a week, and still cannot say what a phantom read is.

Where the tool substitutes first

Now put the assistant into the picture, using the evidence from Chapter 2 rather than a guess.

Cui and colleagues, in Management Science, found gains of 27 to 39% for recent hires and more junior developers against 8 to 13% for senior ones across 4,867 developers. The published finding is the distribution of the gain. It is not a statement about which knowledge got substituted.

Here is my inference from it, offered as an inference. The gains concentrate where the missing knowledge was surface, because surface knowledge is exactly what a model holds comprehensively and hands over on request. What juniors were mostly missing was API shapes, idiomatic patterns and the mechanics of getting something to run, and that shortfall is now purchasable.

If that inference is right, the value of surface specialism compresses towards zero first, and the value of the durable layer holds because it is what tells you whether the generated answer is correct. This is the pattern I trust, and I cannot prove it to you from a single study.

Breadth is a routing table, not a second depth

Breadth gets discussed as though it were depth spread thin. It is a different thing with a different job.

What breadth buys is routing: knowing that a problem is a caching problem rather than a query problem, that this failure smells like clock skew, that this requirement is really an authorisation model. You do not need to be able to build a message queue to know that a queue is the wrong answer here.

So the useful shape is one or two areas of real depth plus deliberately wide, shallow coverage of everything adjacent. In my experience the failure order is consistent. People who go wide with no depth cannot finish anything hard. People who go deep with no breadth solve every problem with the tool they already own.

Breadth is also cheap now, and that is a genuine change. Reading widely with an assistant that explains unfamiliar systems on demand is faster than it was, and the risk is mistaking the explanation for the understanding, which is Chapter 4.

The order I would learn these in

This is judgement rather than evidence, and I would rather state it plainly than dress it in citations.

I would start where failures actually come from. Data first, meaning how your store lays out rows, plans queries and behaves under contention, because most production incidents I have seen are data-shaped rather than code-shaped. Then the network, meaning HTTP semantics, timeouts, retries and idempotency, because distributed failure is where correct components produce incorrect systems.

Then concurrency and failure modes, then security reasoning as a way of thinking rather than a checklist, then observability, meaning how to make a system explain itself. Frameworks come last and continuously, learned in service of a specific task rather than as a subject.

I would order these differently from how they are usually ordered, and here is why. The standard curriculum starts with language and framework because that is what a first job interviews for. It optimises for getting hired once, at the cost of the next decade.

What to do about the years you have already banked

The obvious anxiety here is sunk cost, and the honest answer is more encouraging than people expect.

Years spent in one framework did not only buy framework knowledge. Buried in them is durable material you were never taught to name. How requests fail. How sessions and identity actually behave, how a schema migration goes wrong under load, and why the third rewrite of that module turned out to be necessary.

The work is to extract it. Take a thing you know works in your framework and ask why it works one level down, then ask what the same problem looks like without that framework. That converts rented knowledge into owned knowledge, and it is much faster than starting fresh, because you already have the failures in memory.

The objection: fundamentals is what everyone always says

It is, and the strongest version of the objection deserves better than agreement.

The strongest version runs: telling people to learn fundamentals is unfalsifiable advice that has been correct-sounding for forty years and never tells anyone what to do on Monday. Worse, it implies that enough deliberate practice makes you excellent, which the research does not support. Macnamara, Hambrick and Oswald's 2014 meta-analysis, twelve years old now, found deliberate practice explained 26% of performance variance in games, 21% in music, 18% in sports, 4% in education and less than 1% in the professions.

Take that seriously. It says the professions are the domain where structured practice explains least, probably because professional performance depends on context, judgement and circumstances that practice does not isolate. So the honest form of this chapter's advice is narrower than the usual sermon. Practise the durable layer not because practice makes excellence. Practise it because the alternative is measured decay in exactly the abilities you need to check a machine's work.

That version is falsifiable. If surface specialists were being paid more and promoted faster than people with durable depth, and if generated code required less checking each year rather than more, I would be wrong. Watch those two.

Chapter summary

A skill's half-life is consumed by two independent mechanisms, decay through nonuse and replacement of the thing the skill describes, and career advice almost always discusses only the second, which reduces it to guessing the next framework. Arthur, Bennett, Stanush and McNelly's 1998 meta-analysis of 189 data points found loss rising from d = -0.01 immediately after training to d = -1.4 past a year of nonuse. It also found that cognitive, artificial and accuracy-based tasks decay faster than physical and speed-based ones, which is precisely the class of work an assistant now performs. A one-question test separates layers: would this still be true if the framework, cloud and language were swapped. Durable knowledge survives that swap and compounds, and surface knowledge is rented on a vendor's schedule and generated on request. Contextual knowledge of one employer's systems does not travel. GitHub's Octoverse of 28 October 2025 shows how fast the surface moves, with TypeScript reaching first place in August 2025 and 693,867 of the 1.1 million LLM SDK repositories created inside a year. Cui and colleagues' distribution of gains, largest for juniors, supports my inference, stated as an inference, that the substituted knowledge is mostly surface. Breadth is a routing table rather than thin depth. And Macnamara and colleagues' 2014 finding that deliberate practice explains under 1% of variance in the professions is why the advice is stated narrowly. Practise the durable layer to prevent measured decay, not because practice alone produces excellence.

Chapter 4 takes the first durable skill and treats it as a discipline rather than a talent. Reading Systems Faster Than You Write Them is about comprehension, which was already most of the working day before assistants arrived and is now the half of the job that decides whether the other half is safe.

Sources

  1. Factors That Influence Skill Decay and Retention: A Quantitative Review and AnalysisHuman Performance · 1998 · Research paper · verified
  2. Deliberate Practice and Performance in Music, Games, Sports, Education, and Professions: A Meta-AnalysisPsychological Science · 2014 · Research paper · verified
  3. Octoverse: a new developer joins GitHub every second as AI leads TypeScript to number oneGitHub · 2025-10-28 · Vendor engineering · verified
  4. The Effects of Generative AI on High-Skilled WorkManagement Science · 2025 · Research paper · verified