
There is a specific kind of pride that comes from writing a lot of code. It is visible in pull requests that span hundreds of lines, in engineers who describe their projects by the size of the codebase, in the quiet satisfaction of a `git log` that shows thousands of commits attributed to your name.

It is almost entirely misplaced.

The engineers I have most admired - across companies, teams, and domains - share a different orientation. They take as much satisfaction from a pull request that deletes five hundred lines as from one that adds them. They understand that code is a liability as much as an asset, and that the most powerful thing you can often do is find the lines that should not be there and remove them.

This essay is about the craft of deletion: why it is hard, how to develop the instinct for it, and what you see differently once you start practicing it seriously.

## Why Deletion Is Hard

Adding code feels safe. You understand what you are adding. The tests you write confirm it behaves the way you intend. The diff shows a clear increase in capability. When the feature ships, there is evidence of your contribution.

Deleting code carries different psychological weight. The code exists for a reason - or it once did. Someone wrote it. Maybe you wrote it. Removing it feels like it might break something, even if no tests exercise it. It feels presumptuous. Who are you to decide this code is unnecessary?

This feeling is worth examining, because it is the primary reason codebases accumulate dead weight. Not laziness. Not ignorance. The legitimate psychological difficulty of asserting that something that exists should not exist.

The engineers who learn to delete well learn to manage this discomfort. They develop a set of questions that make the decision less dependent on feeling and more dependent on evidence:

- Is this code exercised by any test?
- Is this code reachable from any entry point?
- Has this code path been triggered in production in the last 90 days?
- Would anyone notice if it were gone?

If the answer to all four is no, the burden of proof has shifted. The question is no longer "should I delete this?" but "why shouldn't I?"

## The Four Categories of Code Worth Deleting

Not all deletable code looks the same. Here is the taxonomy I have found most useful.

**Dead code.** Functions that are never called. Branches that are never taken. Exports that are never imported. These are the easiest to identify with static analysis tools - a TypeScript strict build, eslint's no-unused-vars, Go's unused import checker. They are also the easiest to delete because there is no ambiguity: the code does not run.

**Commented-out code.** This category is pernicious because it masquerades as documentation. Commented-out code is not documentation. It is code that someone was not confident enough to delete, left as a note to a future reader who cannot interpret it without knowing the history. If the code existed, the commit history contains it. Delete it.

**Defensive code for conditions that cannot occur.** This is subtler. It includes null checks for values your type system guarantees are non-null, fallback branches for error conditions your infrastructure prevents, and retry logic in codepaths that never fail transient failures. This code is not wrong - it might even be correct - but it obscures the code that matters and creates cognitive overhead for everyone reading the function.

**Abstraction that serves hypothetical future requirements.** The third version of something that has only ever been instantiated once. The plugin interface for a system that has never had more than one implementation. The configuration knob that nobody has ever turned. Build for what exists, not for what might exist.

<BeforeAfter
  before={`// Before: defensive code that cannot be reached
function getUserName(user: User): string {
  if (!user) {
    console.warn('getUserName called with null user');
    return 'Unknown';
  }
  if (!user.name) {
    return 'Anonymous';
  }
  if (user.name.trim() === '') {
    return 'Anonymous';
  }
  return user.name.trim();
}`}
  after={`// After: trust the type system
function getUserName(user: User): string {
  return user.name.trim() || 'Anonymous';
}`}
/>

The before version is not wrong. Every guard has a story behind it - a bug report, a crash, a moment when `user` was unexpectedly null. But if your type system now guarantees `User` is non-null at all call sites, those guards are noise. They imply uncertainty that no longer exists, and they make the function harder to read than it needs to be.

## The Strangler Fig Pattern in Reverse

The Strangler Fig pattern is a well-known approach to migrating legacy systems: build the new system alongside the old one, gradually route traffic to it, and remove the old system once traffic has fully migrated.

Most teams execute the first two steps well. They consistently fail at the third.

I have seen codebases where the "strangled" legacy system has been running at 0% traffic for two years. It is not deleted because nobody is certain it is safe to delete. The migration was declared complete, the new system was celebrated, and the old code remained - a fossil embedded in the production codebase, confusing every new engineer who encounters it.

The discipline to actually complete the third step - to remove the thing you have replaced - requires organizational will that pure technical instinct cannot provide. It requires someone to own the cleanup, to write the PR, to get it reviewed and merged even when there are shinier things to work on.

This is the craft part. Not the technical knowledge of how to delete safely, but the persistence to see deletion to completion even when it carries no visible reward.

## How to Delete Safely

Conviction to delete is necessary but not sufficient. Deleting wrong costs time and trust. Here is how to do it with confidence:

**Use your coverage tools to find unreachable code.** Istanbul/V8 coverage, Go's cover tool, Python's coverage.py - a coverage report under a meaningful test run will reveal code that has never been executed. Combined with branch coverage, you can identify not just functions but individual branches that are unreachable.

**Check production telemetry before deleting.** If you have structured logging or metrics, search for the function name, the log line, the error code. A code path that has never appeared in two years of production logs is a candidate for deletion. A code path that appeared three weeks ago is not, even if the tests do not cover it.

**Delete in stages for large removals.** For major removals - an entire subsystem, a deprecated API - delete in stages across multiple PRs. First mark the code deprecated and add a log warning when it is called. Ship that. Wait two release cycles. If no warnings appear in production, delete. This approach surfaces assumptions you did not know existed.

**Trust your type system.** If TypeScript, Rust, or Go tells you a function is never called and your linter agrees, the burden of proof has shifted. The compiler has a larger surface area than your intuition.

## The Codebase Archaeology Problem

The hardest code to delete is code you did not write and do not understand. This is the codebase archaeology problem: you open a file, see a function, see no callers, and do not know if it is safe to remove.

The answer is usually in the git history. `git log -p -- path/to/file` will show you every change to a file, including when the code was added, what the commit message said, and what it replaced. A commit message that says "Add fallback for legacy API v1" written four years ago, combined with the fact that the API v1 endpoint was decommissioned two years ago, tells you the story.

Most engineers never look at this history. They treat the current state of the codebase as the primary source of truth and feel blind when they encounter code with no obvious callers. The history is there. Read it.

## The Metric That Matters

Here is a metric I have started tracking on my own work: the ratio of lines deleted to lines added over a quarter.

Not because deleting more is always better. Some quarters require adding more. But the exercise of tracking it surfaces a pattern: in quarters where I delete more, the codebase feels lighter at the end. New features take less time to add because there is less to navigate. Reviews are faster. Onboarding is simpler.

The aggregate effect of sustained deletion is a codebase that grows in capability while shrinking in complexity - which is the goal every engineering team says they want and almost none consistently pursue.

Develop the instinct. Trust the compiler. Delete the code.

---

*The follow-up to this essay covers the specific patterns I use for safely removing old API versions - with feature flags, deprecation warnings, and a concrete timeline for final deletion.*


The Craft of Deleting Code


When I was a senior engineer, I thought about the staff track the way most senior engineers do: as a destination defined by scope and influence. I would become staff when I owned a larger surface area, when my decisions affected more systems, when I was trusted with the company's most technically complex problems.

That framing is not wrong, exactly. But it is incomplete in a way that causes a lot of capable engineers to stall - sometimes for years - while they try to build toward a target they have defined incorrectly.

This essay is about the model I eventually arrived at for understanding what the staff track actually rewards, and what I would do differently if I were a senior engineer today trying to level up.

## The Wrong Model

The wrong model treats the staff level as "senior engineer, but for bigger things." More systems, more complexity, more influence over technical direction.

This model is wrong not because scope and influence are unimportant - they are - but because it treats them as inputs rather than outputs. Engineers who pursue scope actively often produce a specific failure mode: they become owners of systems they should not own, decision-makers on problems where they add the least value, and blockers in organizations that would be better served by distributed decision-making.

I have seen this pattern repeatedly. An engineer who is clearly ready for staff by every technical measure keeps getting passed over. Their manager gives them feedback that is frustratingly vague: "You need to increase your scope" or "Your impact needs to be felt across the organization." The engineer takes on more projects, inserts themselves into more decisions, ships more features. The promotion still does not come.

The problem is not that they are not doing enough. The problem is that they are doing the wrong things.

## The Right Frame: Problems, Not Projects

The frame that unlocked the staff track for me was shifting from "projects I own" to "problems I solve for the organization."

Projects are bounded in time and scope. You start them, you finish them, you move on. A project-oriented engineer is valuable - they ship things. But organizations have problems that span years, that cut across team boundaries, that are not obviously solvable and cannot be assigned to a specific project roadmap. These are the problems that staff engineers are uniquely positioned to address.

Here is a concrete example. At one company, deployments were slow - fifteen minutes from merge to production. This was not anyone's "project." It was not on any roadmap. No team owned it. Individual teams had adapted their workflows around it: batching changes, reducing deploy frequency, accepting the latency as a cost of doing business.

A senior engineer trying to build scope might have noticed this problem and proposed a project: "Q3: Reduce deploy time to 5 minutes." They would have gotten approval, worked through the quarter, and shipped an improvement. That is valuable.

A staff engineer approaches it differently. They recognize that the slow deployment is not the problem - it is a symptom of a deeper organizational problem: the company has no shared ownership of the deployment pipeline, no forum for cross-team infrastructure concerns, and no engineer with the standing to propose and drive systemic changes to shared tooling. A project to speed up deployments does not address any of those things. It produces a faster deployment that degrades again in twelve months when no one is accountable for maintaining it.

The staff-level intervention is to solve the organizational problem - to create the forum, to establish the ownership model, to make the organization capable of solving its own deployment problems without needing a "fix the deploys" project every year.

## The Three Things the Track Actually Rewards

Based on what I have seen promote people at multiple companies, the staff track consistently rewards three things:

**1. Identifying the right problems.** Not the most visible problems, not the problems someone assigned to you, not the problems you are best positioned to solve personally. The problems that, if solved, unlock disproportionate value for the organization. This requires knowing the business, understanding what other teams are struggling with, and having the structural patience to work on problems that might take quarters to show results.

**2. Solving problems through other people.** This is the one that surprises engineers the most, because it sounds like management. It is not management. It is the ability to drive an outcome by making other engineers more effective - by writing the design doc that clarifies the decision space, by pairing with the junior engineer until they can drive the implementation themselves, by building the tooling that makes a class of problems easier for everyone. The leverage multiplies across people. Your personal output matters less than the output you enable.

**3. Building organizational trust.** This is the most underrated of the three, and the one most difficult to pursue directly. Staff engineers are trusted with ambiguous problems precisely because the organization trusts their judgment. That trust is built slowly, through a track record of decisions that turned out to be right, through consistency between what you say and what you do, through the willingness to be honest about tradeoffs in public forums even when the honest answer is unwelcome.

You cannot fake this last one. You cannot build trust by performing trustworthiness. You build it by actually being trustworthy - which means sometimes saying "I don't know" and sometimes arguing for the slower path even when the faster path is more politically convenient.

## The Sponsor Problem

One thing the career advice literature consistently underweights is the role of sponsorship. Mentorship gives you advice. Sponsorship puts your name in a room where decisions are made.

Most promotions to staff level happen because someone senior advocated for a specific engineer in a calibration or leveling conversation. Not because the engineer met a rubric, though meeting the rubric matters. Because a person with credibility in the organization said "this is the engineer we should bet on for this level."

The practical implication: knowing who your sponsor is, and ensuring they have visibility into the work that matters, is not political maneuvering. It is recognizing how organizations actually function and doing the work of making your contributions legible to the people who will speak for you.

If you do not have a sponsor, the first order of business is building the relationships that might produce one. Not through networking in the generic sense - through doing good work in collaboration with senior people who can see it clearly and who have standing in your organization to speak for you.

## What I Would Do Differently

If I were a senior engineer today trying to build toward staff, here is the approach I would take, in roughly prioritized order:

**Find the org's most painful unsolved problems.** Not the problems people are complaining about loudest - those often already have owners. The problems that people have adapted around, that produce quiet frustration rather than loud incidents, that cross team boundaries so no one feels accountable. These are where staff-level leverage lives.

**Work on one of those problems consistently.** Not intermittently. Consistently. The attention span of an individual contributor tends toward "what is due this sprint." The attention span required for staff-level problems is measured in quarters. Pick something and stay with it.

**Write more, in public.** Design docs, postmortems, architecture decision records, team-visible channels. The staff level is only partially about what you build. It is also about the thinking that makes the organization better at building. Making your thinking visible creates the evidence that your thinking is worth trusting with a larger surface area.

**Ask your manager directly what the gap is.** "What would I need to demonstrate to be promoted to staff?" is a direct question that most managers can answer more specifically than the generic feedback cycle allows. If the answer is vague, push for specifics. If the answer is that you are not yet meeting the bar on a specific dimension, that is useful information.

The track is learnable. The confusion around it is largely a visibility problem - most of the work that gets rewarded at the staff level is invisible to engineers earlier in their careers, so the criteria feel arbitrary until they do not.

Once they do not, it usually seems obvious in retrospect. That is almost always a sign you are thinking about it correctly.

---

*For a more operational take on this, Will Larson's "Staff Engineer: Leadership Beyond the Management Track" is the closest thing to a field guide that exists. It is worth reading before your next career conversation.*


Essaystaggedengineering

The Craft of Deleting Code

How I Think About the Staff Engineer Track