Most people get stuck on a hard problem because they leap straight to "what's the answer?" Pólya says: don't rush to compute — first ask the right questions. He splits solving into four stages: ①Understand — what is the unknown? what is given? are the conditions sufficient? ②Devise a plan — have I seen a similar problem? can I first solve an easier version? ③Carry it out — proceed step by step, checking each step really holds. ④Look back — is the answer correct? can I get it another way? what else could this method solve?
The point isn't the four words but that it turns "inspiration" — seemingly uncontrollable — into moves you can practise repeatedly. Stuck no longer means staring blankly; you have a checklist to interrogate yourself with: which step am I in? which condition did I ignore?
Its beauty is that it makes "how to think" itself an object of study — a triumph of metacognition. Pólya noticed that mathematicians reuse a small kit of general moves: analogy, specialization, generalization, working backwards, finding an auxiliary problem. These belong to no single branch of math yet work across all of them. It reveals something deep: discovery isn't pure luck — it's a teachable craft.
These four steps are almost exactly a modern AI agent's planning loop: understand the task → decompose into subgoals → execute step by step calling tools → reflect and self-correct. A large model's chain-of-thought essentially forces it to walk the "plan, execute" steps explicitly; frameworks like ReAct and Reflexion add Pólya's fourth step, "look back" — letting the model check its own answer and retry. Debugging software and designing scientific experiments follow the same flowchart.
Mathematicians almost never solve a problem "from scratch." What they do is reshape an unfamiliar problem until it looks like one they already know how to solve. Pólya calls this "can you reduce it to a known problem?" Descartes went further — he dreamed of reducing every problem to an equation, and every equation to algebra.
An everyday analogy: you must attend a meeting in a city you've never visited. You don't research "how to reach this specific address"; you reduce it to two solved subproblems — "how to get to that city" (book a flight) and "how to find an address in a city" (open a map). Reduction = not reinventing the wheel, but bolting your problem onto wheels that already exist.
Reduction reveals the network structure of knowledge: countless seemingly isolated problems are linked by arrows of "A reduces to B" into one vast web. The moment a core problem falls, everything that reduces to it is solved at once. This is leverage — one fulcrum moving a whole region. The cumulative, compounding power of mathematics springs from exactly this.
Reduction is the soul of computational complexity theory. The definition of "NP-complete" is: every NP problem reduces to it in polynomial time. So to prove a new problem "hard," you needn't analyze it from scratch — just reduce a known hard problem (like 3-SAT) to it. This chain of dominoes holds up all of theoretical computer science. Divide and conquer (reducing a big problem to smaller ones of the same kind), compilers reducing high-level code to machine code, and machine learning reducing "prediction" to "optimizing a loss function" are all reduction.
Facing a system you may operate on repeatedly (chess, a puzzle, a state machine), the sharpest question is: no matter what I do, what never changes? That unchanging thing is the invariant. Like a conservation law, it cleaves the infinitely many possible moves into two camps: the reachable and the forever unreachable.
The classic example — the mutilated chessboard: remove two opposite-corner squares from an $8\times 8$ board; can you tile the rest with 31 dominoes (each covering two squares)? Trying arrangements leads into endless cases. But note: every domino covers one black and one white square, so the invariant = the number of black squares must equal the number of white. The two opposite corners share a color, so removing them leaves the counts differing by 2 — the invariant is broken, hence it is impossible. One sentence beats a million trial placements.
An invariant turns "proving something is impossible" — normally hard — into the elegant task of "pointing out a conserved quantity." To prove something can be done, one example suffices; but to prove it can never be done, you must rule out infinitely many attempts at once — and the invariant is the master key. In physics this is the spirit of Noether's theorem (Day 18): behind every conservation law hides a symmetry. The invariant is one of the deepest aesthetics math and physics share.
The core of program verification is the loop invariant: a proposition that stays true after every iteration, from which you prove the algorithm correct. Database ACID and distributed-system consistency are essentially "maintaining some invariant under concurrent operations." In physics, energy, momentum, and charge conservation are invariants; in machine learning, seeking features invariant to rotation or translation (equivariant networks) is the same idea — find "the quantity unchanged under a transformation."
When a problem involves a pile of objects and you don't know where to start, one move is startlingly effective: fix your gaze on the most "extreme" one — the largest, the smallest, the leftmost, the closest to some point. An extreme object is often cornered into a special property with "nowhere to retreat," and becomes the breakthrough for the whole proof.
For instance, to prove "in any group of people, two must have the same number of friends": finding them directly is hard. But consider the person with the most friends — their count is at most $n-1$ and at least $0$, and "someone has no friends" and "someone is friends with everyone" cannot both happen... The extreme member pins the possible values, and the pigeonhole principle closes the net. The extreme point has no way out, so it speaks first.
Its beauty is a kind of advance-by-retreat wisdom: facing a vast field of objects, you don't treat them uniformly — you bet precisely on the boundary. This rhymes with optimization theory — the optimum of a convex problem always lies at an extreme (a vertex, the boundary). The extremal principle often pairs with infinite descent: assume a "smallest counterexample" exists, then construct an even smaller one — contradiction, so no counterexample exists. Fermat used exactly this to prove $x^4+y^4=z^4$ has no positive-integer solution. From "the smallest," overturn "there exists."
In algorithm design, the greedy method picks the current extreme at each step (shortest edge, earliest deadline, largest gain) — Kruskal's minimum spanning tree and Huffman coding are the extremal principle turned into algorithms. Linear programming's simplex method walks the vertices (extreme points) of the feasible region toward the optimum. Worst-case thinking in game and security analysis fixes on the most extreme outcome an adversary can cause. All of extremal graph theory asks: what happens to a property at its "densest / sparsest"?