the second hundred · metaphor 186
Some undertakings look impossible from the front — the years-long project, the life rebuilt, the thing so large you can't see how anyone could ever get there from here. And then one day it turns doable, not because it shrank, but because you finally broke it into pieces you'd already solved.
What makes a plan feel impossible is rarely its true size. It's the sense that you must re-derive everything from scratch, every time — that each morning starts the whole reasoning over, re-litigating the same worries, re-solving the same small problems you solved yesterday and forgot you'd solved. The work explodes not because there is so much of it, but because you keep doing the same work again.
The escape is almost embarrassingly simple: solve each piece once, write down the answer, and never solve it again. If the same sub-problems keep recurring — and in any real plan they do — then remembering them collapses an impossibly branching task into a short list of steps. Computer scientists built an entire method on exactly this move, and gave it a grand name: dynamic programming.
The idea
Take a task defined in terms of smaller versions of itself — to know step n you need steps n−1 and n−2. Solved naively, by recursion, this branches: each step spawns two, each of those spawns two more. The tree of work grows exponentially. To reason eighteen steps ahead this way takes thousands of computations. It really does look impossible, and the panel shows you the cloud.
But look closely at that cloud and you'll see the same subproblems appearing over and over. Step 4 shows up in dozens of places; step 2 in hundreds. They are overlapping — the branches keep re-deriving answers that other branches already found. Dynamic programming is the recognition that there were never thousands of different problems here. There were only n+1 of them, each buried under a mountain of needless repetition.
So you solve each subproblem once and remember the answer — memoize it. The second time a branch asks for step 4, it doesn't recompute; it looks the answer up and returns instantly. The exponential tree collapses to a thin spine of genuine work with a fringe of instant look-ups. Thousands of computations become a couple of dozen. The plan didn't get smaller. You just stopped re-solving what you already knew.
What to try
Every count in the panel is produced by actually running the two strategies and tallying real calls — nothing is a stand-in formula. Drag the size of the plan upward with memoization off, and watch the tree balloon: at size 12 it is hundreds of nodes; by 18 it is thousands, a dense triangle of repeated work, and the "from scratch" counter climbs faster than you'd believe. The little chart underneath plots that climb on a log scale — the red line is the exponential, and it runs away.
Now press Memoize subproblems. The same plan, the same size — but the cloud snaps to a thin green zig-zag, the counter drops from thousands to a couple of dozen, and the speed-up reads hundreds of times over. On the chart, the green line barely lifts off the floor: linear, not exponential. Slide the size back and forth in each mode and feel the difference between a task that grows out of reach and one that grows one step at a time. The presets take you from trivial to apparently-impossible.
The mapping
The move is one everyone has made without a name for it. The overwhelming project feels impossible while you hold the whole tangled thing in your head at once; it becomes a to-do list the moment you name its parts and notice that half of them are the same part. The recurring worry eats the day because you re-argue it from zero each time it surfaces — until you write down, once, what you actually concluded, and can just look it up. The skill you can't imagine having is a tower of sub-skills, most shared with things you already know; learned in the right order, each rests on the last.
And the real correspondence runs deeper than "break it into steps." Dynamic programming works only when a problem has optimal substructure — when the best solution to the whole is genuinely built from best solutions to its parts — and overlapping subproblems, so that remembering pays off. That is a precise claim about a plan: that its pieces compose cleanly, and that the same pieces recur. When both hold, the impossible-looking thing was always just a modest number of decisions wearing an exponential disguise. The insight is never "try harder." It's "you've solved this piece before — stop starting over."
Read as life lessons
What explodes a plan is repetition, not scale. A task with n+1 real parts can generate thousands of computations if you keep re-deriving them. Kill the repetition and the size becomes almost irrelevant.
Memory is the whole trick. The instant you record what a subproblem's answer is, every future branch that needs it pays nothing. A decision made once and remembered stops costing you every day.
DP rewards the right decomposition — parts that compose and recur. Finding those parts is the hard, human step; once you've found them, the execution is almost free. Spend your effort on the joints, not the grind.
In the wild
Shortest paths, sequence alignment, optimal scheduling, and the knapsack all yield to DP: each turns an exponential search into a filled-in table by solving every subproblem exactly once.
Bellman's equation runs the same trick over time: the best action now, given the best value of every state you might land in. It's the backbone of reinforcement learning and optimal control.
Project decomposition, checklists, and reusable templates are memoization by hand — recording a solved step so no one on the team ever has to re-derive it from nothing again.
The mapping, exactly
| Mathematics | Life |
|---|---|
| a subproblem | A smaller version of the same decision you keep facing on the way to the whole. |
| naive recursion | Re-deriving everything from scratch each time — re-litigating the same worry as if for the first time. |
| overlapping subproblems | The same few decisions recurring all over the plan, rather than thousands of unique ones. |
| the memo table | Remembering what you already worked out — writing the answer down so you never solve it twice. |
| exponential → linear | An impossible-looking task turning into a short list of steps, once the repetition is removed. |
| optimal substructure | The whole genuinely built from the best solutions to its parts — the decomposition that makes it hold together. |
The honest model
The plan is the Fibonacci recurrence — f(n) = f(n−1) + f(n−2) — chosen because it is the cleanest problem with overlapping subproblems. The panel actually runs the naive recursion and builds its real call tree: every node you see is a genuine call. From-scratch work counts each of those calls, and it equals exactly 2·f(n+1) − 1 — the exponential you watch balloon.
With Memoize on, it runs the same recursion but keeps a table of solved subproblems: the first time it meets f(k) it computes and records it (green); every later request is an instant look-up (a hit). The remembered tree therefore has only n+1 genuine computations plus a fringe of look-ups — linear work. The speed-up chip is just the honest ratio of the two real call counts, and the chart plots both as you drag the size. Nothing is a fitted curve; it's two algorithms racing on the same problem.
Where the metaphor tears
DP needs the problem to actually factor — clean parts that recur and compose into the whole. Plenty of hard things don't: the pieces interact, the sub-answers can't be reused, there's no table to fill. Some overwhelming tasks are genuinely irreducible, and telling someone to "just break it into subproblems" is cruel when the subproblems refuse to hold still.
Memoization trades time for space: you must be able to hold every distinct subproblem's answer at once. When the number of genuinely different subproblems is itself astronomical — the real curse of high-dimensional planning — remembering them all is no more possible than recomputing them. DP doesn't dissolve the difficulty; sometimes it only moves it from time into memory.
The method rewards a decomposition you already had to invent. "He remembered his subproblems" quietly presumes he'd first carved the plan at the right joints — and that carving is the whole act of insight. Cache the wrong decomposition and you'll memoize nonsense, efficiently. The math makes execution cheap; it never tells you where to cut.