AiBook · ISBN 9798173134660 · PDF

AiBook · Jeremy Schoemaker · 2026 · ch-58.html

Subtract Before You Add

(Spine Ch. 58.)

“I made this one [letter] longer only because I have not had the leisure to make it shorter.” Blaise Pascal, Provincial Letters, Letter XVI (1656)

Fourteen checks in a free airank report, and two of them carry a quarter of the total score: publish a plain-text markdown file (13 points), add a link tag pointing at it (12 points). When a research pass came back saying neither check helps citation, I went and got proof. Fifty-seven ClaudeBot fetches pulled out of the crawl logs, every one verified against Anthropic’s published IP ranges. Real bot, real file, real timestamps. I walked into that argument holding a receipt, and I was very pleased with myself for about a day. The receipt was for the wrong thing.

A slow-query storm paged five times in a row on 14 August 2026, and every instinct in the room said add indexes. The plan the council eventually produced added exactly one index and deleted one, and the deletion was the part that mattered. cgos_via_search_idx had zero reads. It had never served a single query in its life and it taxed every insert into the hottest-written table in the schema, right before a 75-worker backfill was scheduled to pour writes into it. Seventy-five workers were about to come through the door and the grenade was already on the floor. We had convened a council to add things to a database whose actual problem was a thing already in it.

Bottom line: The first move on any system that hurts is subtraction. Delete the dead index, the dead code path, the dead feature, the dead paragraph. Then look again, because the right addition is usually obvious once the corpse is out of the room, and it is usually one thing instead of four. Adding to a complex system compounds the complexity you were hired to fix. Deletion is the only change that cannot introduce a new bug in the thing it removes.

Nobody does this because deleting is unreviewable as achievement. A pull request that removes 3,000 lines reads to a manager like you had a slow week.

When it bites

The pattern

Sequence removal before construction. That is the whole principle, one of the 21 pstack principles Flavio Copes published on 21 August 2026. Three mechanical reasons:

Dead things cost on write, not on read. An unused index looks free because nobody queries it. Every insert pays for it. Dead code is read by every person and agent that touches the file, and loaded into the context window of a model you pay by the token. cgos_via_search_idx cost money on every row and returned nothing on any of them.

Removal reveals the structure. Once the dead path is gone you can see the shape of the live one. The airank schema stopped looking under-indexed the second we stopped counting an index that never ran.

The addition gets smaller. The council started with four candidate new indexes. After measurement, one survived, product_categories(parent_id), the only one whose EXPLAIN showed a real scan of 18,659 rows. The others pointed at tables of 5 and 1 rows.

Node.js shipped this in public. Version 25.0.0 landed 15 October 2025 and the release notes lead with what came out: SlowBuffer plus fourteen other deprecated APIs, removed for lower memory overhead and less maintenance. SlowBuffer announced its own problem in the name for years and it took a SEMVER-MAJOR to admit nobody wants a buffer that finishes slow.

Subtraction applies to prose, and this book proves it

The rule I write this manuscript under is a deletion rule, and it is not written down anywhere. I checked again on 9 September 2026: no style guide in the repo, no CLAUDE.md, and the one committed AGENTS.md is about building the print interior, not prose. The rule set lives in prompt strings and in my memory, which is a comedy of a place to keep a rule about writing things down. As enforced: zero em dashes. A banned word list (delve, seamless, cutting-edge, tapestry, paradigm, synergy, and about thirty more). No triplet lists for rhythm. No rhetorical question I then answer. No closing line summarizing the section I wrote.

The em dash rule at least has a number. The proof pass on 9 September 2026 took the manuscript from 291 em dashes to zero at 07:16, and 73 were back two minutes later. Every survivor sat inside a line the agents had been told not to touch, because the em dash was in my own template. I banned a character and kept shipping it myself.

Every one of those rules is a removal. There is exactly one addition rule in the whole set: every paragraph needs a concrete noun. A number, a filename, a date, a product, a person.

That single positive rule does the work of a hundred style guidelines, and only because everything else got cut first. You cannot write a paragraph that contains cgos_via_search_idx and 298,255 reads and also contains “in today’s rapidly evolving landscape.”

The biggest deletion I have shipped is this book. On 9 September 2026 the manuscript entered a subtract pass at 157,097 words. Pass one got it to 142,858 and left 28 chapters over the 2,400-word cap. Pass two went harder. Then the integrity checker, told to compare against the pre-cut snapshot and repair only the damaged part, decided a 30 percent drop in word count was the damage and restored ten chapters wholesale. Every check passed. Ch. 17 came back at 3,249 words.

I built a safety net that could not tell deletion from destruction, so it undid the work and congratulated me.

Pass three ran a checker that could only see structure (receipt count, epigraph bytes, headings, URLs, em dashes), told in capitals that shorter is expected and never a reason to restore. Final: 135,707 words, zero chapters over the cap, 266 receipts intact. A 13.6 percent cut with nothing load-bearing lost.

Then a receipts pass put it back to 150,842 and pass four, this afternoon, took 44 chapters under the cap again. This chapter has been cut four times, restored once against its will, and still tells you to delete things.

One worked example

airank, 14 August 2026. The stated task was index optimization. The council of seven opened with a measurement rather than a narrative, which is the only reason any of this went right.

The first surprise: the schema was not under-indexed. The one table lacking a primary key (post_tag) had zero rows. Every large table carried composite indexes. chatgpt_observation_sources had 464MB of index against 298MB of data. Nothing for “add indexes” to point at.

So the room flipped to the opposite theory, over-indexed, and nominated two indexes for the chop on leading-column selectivity: cgos_via_search_idx and cgos_ad_network_idx.

userstat was off, so information_schema.index_statistics came back empty. performance_schema was on, and table_io_waits_summary_by_index_usage keeps a read counter per index. One query:

cgos_host_obs_idx        193,558,187 reads
cgos_canonical_obs_idx    70,289,427 reads
cgos_obs_idx               1,731,675 reads
cgos_capture_idx           1,609,326 reads
cgos_ad_network_idx          298,255 reads
cgos_via_search_idx                0 reads

The selectivity heuristic was backwards. ad_network, nominated for deletion, stays. via_search had to go.

Jeremy Schoemaker, twenty-five years of shipping software, argued for dropping the live index and keeping the dead one. One counter, one query, and I got pwned by a table I could have read in eleven seconds before I opened my mouth.

Outcome: one index dropped, one added, and a cascade of retractions on every load-bearing claim the council made. The seat that called ad_network dead retracted to retain it. The seats that wanted four new indexes retracted to one.

The transferable part is not “measure before you optimize,” which everyone claims to believe and nobody does. It is that the measurement changes the sign of the answer. We set out to add. The move was to remove.

The second version of the same lesson, 22 August 2026. I defended the two markdown checks with crawl logs. The logs prove crawlers fetch the file. Nothing in them proves that fetching it changed whether the page gets cited. Two different causal links, and I measured the first while charging for the second. Fifty-seven verified fetches, zero verified citations, a 25-point weight resting on the gap. I built the thing, priced the thing, and produced the evidence for the adjacent claim with total confidence.

The fix was a deletion. Move the check from PROVEN to UNPROVEN, keep the 13 points, and show the customer both readings.

The quiet failure

The loud failure is the codebase nobody deleted from, and it announces itself. Twelve-minute test suites, a 4,000-line file with four live functions, an onboarding doc that starts with “ignore everything in legacy/.”

The quiet failure is worse, and it is a diagnosis error:

You add capacity to a system whose problem is load.

Kris Drouet, a VP of Engineering, wrote this up on 2 August 2026 after watching a leader misread a team. The board deck showed declining velocity; the recommendation was hire more. The question that settled it was how long since the team had a week with nothing on fire. The answer was before the migration, fourteen months earlier.

That team was not slow, meaning broken systems. It was tired, meaning cooked. Hiring four engineers onto a team with no slack means four onboarding loads, four review queues, and the people already carrying it start updating their resumes. The first move was subtraction: cut the roadmap in public, buy relief, then remove ambiguity and queues.

Second quiet failure: you delete the loud thing and keep the dead thing. The acute airank storm was already fixed by a canonical_url swap that took 1.62 million rows to 108,000. The zero-read index was still there taxing every write, invisible precisely because it never showed up in a slow-query log. Dead things do not page you.

Third: you subtract from the artifact instead of the system. Cutting words out of the plan is not cutting work out of the quarter. Ch. 15 covers what happens when you confuse the two.

Do / don’t

Do

Don’t

Where this sits in the book

Ch. 13 is subtraction applied to instructions: the skill beats the 40-page brain dump because it is the brain dump minus 38 pages. Ch. 50 applies it to sequence; “never” is a deletion decision people keep calling a scheduling decision. Ch. 15 is why the plan is not the work: deleting a line from a plan removes nothing from production. Ch. 44 is the measurement that says which thing is dead; without it every deletion here is a guess with confidence attached.

Sources and receipts

Verified:

What I could not verify: