99 · The Leverage Route

THE SHORTEST PATH — A History of the Art and Science of Problem-Solving

The kit, assembled

This book made one claim and spent eleven chapters earning it: great solvers do not search harder; they change the space until the path is short. You watched the claim hold across four thousand years — a scribe writing down a route instead of an answer, Euler throwing away a city, a wartime economist discovering that a thousand problems were one, a machine playing a move with a one-in-ten-thousand chance of occurring to a human. Different centuries, one silhouette: the space changes, then the walk is short.

Along the way, every chapter left you one Move — a transferable act with a name. Here is the complete kit. The gloss column is not a summary; it is a trigger — the situation in which that Move should come to hand by itself.

Eleven moves. They are not equals: 00 and 02 are the spine — the frame and the representation — and the other nine are what you do once the space is chosen. Which is why they compose in a definite order.

The standard opening

Chess players do not reinvent the first ten moves of a game; they play an opening — a debugged sequence that reaches a playable middle game. Hard problems deserve the same courtesy. When something serious lands on your desk, this is the opening the whole book has been building:

First, refuse the package (00). Write one sentence: what would count as solved? Make it an outcome, not a procedure. List the rules you are obeying and mark which are real.

Second, choose the space (02). Draw the problem in at least two representations — a list, a graph, a table, a picture, a story. Keep the one in which the difficulty looks smallest. This is the highest-leverage minute you will spend.

Third, check the wall (06). Is this problem a known monster in disguise? If the honest shape of it is intractable, decide the trade now — approximate, narrow the instance, or attack a different problem — rather than after a month of noble effort.

Fourth, search — with tools, in order (03, 05). Name the heuristic you are using so you can notice when it fails. Rank the options so the promising paths come first. When a machine searches better, hand it the walking and keep the grading (10).

Fifth, buy information cheaply (07, 08). Before any expensive commitment, find the small experiment that stands in for the big world, and name the one constraint that decides everything.

Throughout, listen for the click (09) — and log the route (01). A sudden simplification is data; verify it. And when the problem yields, write down how — the method is the part of the answer you get to keep.

A worked miniature. Suppose the problem is the drearily common one: our weekly report takes two days to produce. The package says "write the report faster." Refuse it: what counts as solved is decisions get made with current numbers — perhaps no report at all (00). Redraw: not a document but a pipeline — sources, transforms, a template; suddenly the two days are visibly three hours of queries and thirteen hours of formatting and chasing (02, and the measurement is 04's). The formatting is mechanical — delegate it to a machine under your template (10); the chasing violates a single load-bearing constraint — numbers are never where the report is written (08). The solved state turns out to be a dashboard and a fifteen-minute Monday conversation. Nobody searched harder. The space changed, and the path got short.

The thirty-day route

Reading about moves does not install them. Use makes them reflexes — which is the difference between owning a book and owning a kit. The route below takes thirty days, roughly thirty minutes each except the two capstones. It assumes you have real problems; it works only on real problems. Do not practice on puzzles alone — puzzles have owners' frames, and the whole point is learning to question frames that matter.

Week 1 — Frames and spaces (chapters 00–02)

• Day 1. Read 00. Pick one live problem. Write in one sentence what would count as solved. If your sentence names a procedure ("implement X"), rewrite it as an outcome.
• Day 2. Frame audit: list every rule you are obeying on that problem. Mark each real or habit. Ask of one habit-rule: who set this, and does it bind me?
• Day 3. Read 01. Take something you did well last week and write its route — steps, order, checks — as if teaching it. Name the method. You now own it as an object.
• Day 4. Read 02. Redraw one current problem in a different representation: prose into a diagram, a dispute into a table of claims and evidence, a process into boxes and arrows. Keep whichever drawing makes the difficulty smaller.
• Day 5. Gauss day. Find one repetitive task in your week and look for the pairing, symmetry, or batch structure that collapses it — the fifty-first way of seeing the same sum.
• Day 6. Königsberg day. Take one thing widely called impossible in your world and prove which constraint makes it impossible — count the thing that must balance and doesn't. An impossibility argument is a map of exactly what would have to change.
• Day 7. Review. Write the week's best reframe on one card, in one sentence. This card starts your deck.

Week 2 — The named tools (chapter 03)

• Day 8. Read 03. Make five heuristic cards: analogy · invert · work backwards · relax a constraint · specialize first. One line each on when it fires and how it fails.
• Day 9. Work backwards from a real goal: write the final state, then the state just before it, until you reach today. Note where the backward chain disagrees with your forward plan — that disagreement is information.
• Day 10. Inversion day. For one project ask: how would I guarantee failure? List five answers. Negate them. You now have the five things that actually matter.
• Day 11. TRIZ day. State one live contradiction — "we need it stronger AND lighter," "faster AND safer" — and refuse the compromise for thirty minutes; search for the resolution that gets both. Most compromises are surrenders negotiated too early.
• Day 12. Analogy day. Ask: what other field has my problem's shape? Queues, contagion, inventory, evolution, auctions — the distant field has usually been at it longer.
• Day 13. Incubation test. Load one hard problem carefully — read everything, state it precisely — then take a walk with no phone. Log what surfaces, even nothing. You are calibrating your own background process, not summoning magic.
• Day 14. Review. For each card in the deck: did it fire this week? What is its failure mode? A tool whose failure mode you cannot name is a superstition.

Week 3 — The formal engines (chapters 04–06)

• Day 15. Read 04. Instrument before improving: time one whole process end-to-end and find where the hours actually go. Expect to be wrong about it.
• Day 16. Whole-system day. Find one local optimization around you that damages the whole — the report polished for a meeting that shouldn't exist. Name the true objective it forgot.
• Day 17. Read 05. Draw a real decision as a six-node graph — states, transitions, costs — and run Dijkstra by hand. The exercise is not the arithmetic; it is feeling a decision become a space.
• Day 18. Strategy day. Classify three current tasks: greedy (take the best now), divide-and-conquer (split, solve, merge), or dynamic programming (overlapping subproblems — cache one repeated sub-answer this week and watch the savings compound).
• Day 19. Read 06. Reduction day: before inventing anything, ask which solved problem is this in disguise? Spend the thirty minutes searching the shelf, not the space.
• Day 20. Wall day. Identify one thing you brute-force that is genuinely hard — combinatorial, political, physical. Choose the trade explicitly: approximate, randomize, narrow the instance, or stop paying. An unnamed wall collects tolls forever.
• Day 21. Review. Write your personal "known monsters" list — the recurring problem shapes in your work and the standard trade for each.

Week 4 — Galleries, beauty, machines (chapters 07–10)

• Day 22. Read 07. Shrink one experiment: replace an expensive test in your world with a cheap proxy — and write down what the proxy cannot see, because that blindness is the price and you should pay it knowingly.
• Day 23. Read 08. Constraint day: for one live project, name the load-bearing constraint. Then either honor it completely or price what breaking it would cost. The hundred other rules are decoration.
• Day 24. Teaching day. Retell one gallery case — Snow's map, the scrubber, Rejewski's permutations — to another person, from memory, ending with its move in one line. If the retelling sags, you stored the story but not the structure.
• Day 25. Read 09. Start a beauty log: each time something suddenly simplifies this week, write the click down — and schedule its verification. The click is evidence, not verdict.
• Day 26. Elegant-wrong day. Take one tidy story you currently believe and attack it: what evidence would break it? The seduction chapter (09) exists because this exercise is the one solvers skip.
• Day 27. Read 10. Delegation drill: give an AI engine one real search under your frame — write the goal predicate and constraints first, then grade the arrivals against the predicate, then log where your frame leaked. The leak log is the lesson.
• Day 28. Centaur audit. Two columns: where machines now beat you (delegate, without nostalgia) and where you still add value (double down, without complacency). Date the page; it will age, and the dated page is the point.

Capstones

• Day 29. The full opening, live. Take one important problem and run the standard opening end-to-end in a timed ninety minutes, whole kit on the table. Write the path you took — which moves fired, in what order, what changed.
• Day 30. Write Move 11 — yours. Name, trigger, failure mode, in the house format. Somewhere in your domain is a move this book does not contain, one your own scars have taught you. The kit was never meant to arrive complete. It was meant to arrive extensible.

The solver's checklist

Before: What counts as solved — as an outcome? Which rules are real? In what representation is this smallest? Is it a known monster?

During: What tool am I using — by name? Are good paths coming first? Has honest effort failed enough to suspect a wall? Did something click — and did I log it?

After: Write the route. Shorten it once — the second draft is where elegance lives. Shelve the method as an object with a name. What would make this problem never return?

That last question deserves its line. The chapters kept meeting solvers whose deepest solution was to make the problem extinct — Semmelweis did not treat childbed fever better, he removed its cause from the doctors' hands. The shortest path of all is the one nobody has to walk again.

Problems worth having

One skill remains, and the book has been circling it since Gordium: the moves tell you how to solve, not what. Machines have made the how abundant — chapter 10's engines will walk almost any space you can specify, and they get better every season the ink on that chapter dries. Which means the scarce act, the one the whole apparatus now waits on, is the choice of problem. Problem-finding — taste — is the last unautomated move, and taste is built the same way the others were: by keeping a route log, by noticing which solved problems left the world lighter and which merely left it optimized, by asking of every candidate knot not "can I undo this?" but "what comes free if I do?"

So the book ends by inverting its own opening. At Gordium, the knot was handed to Alexander; the prophecy, the frame, the audience — all set by others, and his genius was refusal. You are past that now. From here on, more and more, you will be the one handing out knots — to your tools, your machines, your colleagues, your future self. That is what it means to hold the frame while the searching is delegated: the quality of the problems you set becomes the ceiling on everything downstream.

The knot is the problem as handed to you. The path is yours to choose. Both halves of that sentence were always true; the route you have just walked exists to change which half you live in.

Choose well. Walk short.

THE SHORTEST PATH · end