# How to Think Like a Mathematician > Problem-solving as a learnable craft: Polya's four steps, trying small cases, finding invariants, and getting unstuck when you are stuck. --- # How to Think Like a Mathematician You stare at a problem. Nothing happens. The page feels like a locked door with no handle, and the longer you look the more certain you become that real problem-solvers would have cracked it by now. That feeling is the lie this guide takes apart. Mathematicians are not faster than you. They are not staring at the locked door either - they are walking around the building trying every window, and they have a short list of windows worth trying. That list is a craft, not a gift. You can learn it, the same way you learned to debug code: by having a few reliable moves and the patience to run them. ## How to read this Read the phases in order; each one builds on the move before it. Don't rush to the heuristics in phase 2 before you've sat with phase 1 - the four-step loop is the frame that makes every other trick land. Try the examples on paper as you go. The whole point is that these moves only become yours once your own hand has run them on a problem that was actually stuck. If the word "math" still makes your shoulders tense, start with [/guides/why-math-isnt-your-enemy](/guides/why-math-isnt-your-enemy) first. And once you can find an answer, [/guides/what-a-proof-is](/guides/what-a-proof-is) is how you make it certain. ## The phases 1. [The loop: understand, plan, do, look back](01-the-loop.md) - the four-step frame every solver runs, named. 2. [The moves: how to actually get an idea](02-the-moves.md) - small cases, patterns, working backwards, invariants. 3. [Stuck is the job: getting unstuck](03-stuck-is-the-job.md) - what to do when nothing comes, and why struggle beats talent. --- # The Loop: Understand, Plan, Do, Look Back Watch what most people do with a hard problem: they read it once, feel the panic, and immediately start writing equations - any equations - hoping the right ones fall out. That's not solving. That's flailing with a pencil. In 1945 a mathematician named George Polya wrote down what the people who *don't* flail actually do. It turned out to be four plain steps, run in a loop. Not a magic formula - a checklist. The value isn't that the steps are clever. It's that having them stops you from skipping the two steps everyone skips, which are the first one and the last one. ## The four steps 1. **Understand the problem.** What are you given? What are you asked for? Could you state it back in your own words? 2. **Devise a plan.** What approach might connect what you have to what you want? 3. **Carry out the plan.** Do the work, one careful step at a time, checking each. 4. **Look back.** Did it answer the actual question? Does the answer make sense? What did you learn that you could reuse? That's it. The whole loop. And if step 3 falls apart, you don't quit - you loop back to step 2 and try a different plan. Getting stuck is part of the machine, not a sign the machine broke. ## Step 1 is where the problem is won or lost Most wrong answers are not arithmetic mistakes. They are answers to a question that was never asked. "Understand the problem" sounds too obvious to need saying, which is exactly why it gets skipped. Here is the test for whether you understand a problem: can you say it back without the original words? ```text Given: "A train leaves A for B at 60 km/h. Another leaves B for A at 40 km/h. The towns are 200 km apart. When do they meet?" Say it back: "Two things move toward each other and close a 200 km gap. Together they eat 60 + 40 = 100 km every hour. I want the time to close 200 km." The question I'm actually answering: 200 ÷ 100 = how many hours? ``` *What just happened:* re-stating the problem in plain words quietly did the hard part. "Toward each other" is the insight that lets you add the speeds, and you found it not by being clever but by refusing to move until the words were yours. ## Step 4 is the one that compounds Look back is where amateurs stop early and pros pull ahead. You got an answer - now ask: does it pass a sanity check? Could I have gotten it a faster way? Is there a pattern here I'll see again? ```text Answer to the train problem: 2 hours. Look back: - Sanity: in 2 hours the 60 km/h train goes 120 km, the other goes 80 km. 120 + 80 = 200. The gap closes exactly. ✓ - Reusable idea: "closing speed = sum of speeds when moving toward each other." That'll show up again - two pipes filling a tank, two people raking leaves, two processes draining a queue. ``` *What just happened:* the sanity check caught nothing this time, which is the point - you now *trust* the 2 hours instead of hoping. And naming the reusable idea means the next "two things working together" problem is already half-solved. ## For builders You already run this loop - you call it debugging. "Understand the problem" is reproducing the bug before you touch code. "Devise a plan" is forming a hypothesis. "Carry out" is the fix. "Look back" is writing the test that proves it stays fixed. The engineers who skip reproduction and patch the first plausible line are doing the pencil-flail, only in a different editor. When a proof needs to be airtight rather than merely convincing, [/guides/what-a-proof-is](/guides/what-a-proof-is) picks up where "look back" leaves off. > The loop is not linear. You will loop from step 3 back to step 2 many times on a > real problem. That's not failure - that's the loop working as designed. ```quiz [ { "q": "Which two steps of Polya's loop do people most often skip?", "choices": ["Plan and carry out", "Understand and look back", "Carry out and look back", "Understand and plan"], "answer": 1, "explain": "People rush past truly understanding the problem and quit the moment they have any answer, skipping the sanity check and the reusable lesson." }, { "q": "What is the practical test for whether you understand a problem?", "choices": ["You can write an equation for it", "You can say it back in your own words without the original wording", "You recognize the topic it came from", "You remember a similar problem"], "answer": 1, "explain": "Re-stating it in your own words forces out hidden assumptions and often surfaces the key insight, like 'moving toward each other means add the speeds'." }, { "q": "When step 3 (carry out the plan) falls apart, what does the loop say to do?", "choices": ["Give up; the problem is too hard", "Push harder on the same plan", "Loop back to step 2 and try a different plan", "Skip to step 4 and guess"], "answer": 2, "explain": "Getting stuck is built into the loop. A failed plan sends you back to devise a new one, not out the door." } ] ``` --- # The Moves: How to Actually Get an Idea Phase 1 gave you the loop. But the loop has a hole in it the size of a house: step 2 says "devise a plan," and you reasonably want to scream, *with what?* Where does a plan come from when you're staring at a blank page? It comes from a short menu of moves. These are the windows a mathematician walks around the building trying. None of them is guaranteed to work. All of them are worth a try, and on most problems at least one of them cracks the door. Learn the menu and "I have no idea" turns into "let me try the first three." ## Move 1: Try the smallest case When a problem is stated for some big or general number, shrink it. Do the case for 1. Then 2. Then 3. Small cases are cheap, and they show you the machinery. ```text Problem: What is 1 + 2 + 3 + ... + 100? Shrink it: n = 1: 1 = 1 n = 2: 1 + 2 = 3 n = 3: 1 + 2 + 3 = 6 n = 4: 1 + 2 + 3 + 4 = 10 ``` *What just happened:* you stopped trying to leap at 100 and did the parts you can do in your head. Now you have data - 1, 3, 6, 10 - and data is something to look at, which a blank page never was. ## Move 2: Find a pattern Once you have small cases, stare at the numbers and ask what they're doing. Patterns are the bridge from "examples" to "rule." ```text Sums: 1, 3, 6, 10 n: 1, 2, 3, 4 Try multiplying n by the next number: 1×2 = 2, 2×3 = 6, 3×4 = 12, 4×5 = 20 That's exactly double each sum. So sum = n(n+1)/2. Check at n = 100: 100 × 101 / 2 = 5050. ``` *What just happened:* the pattern n(n+1)/2 didn't fall from the sky - you found it by poking the small cases until the numbers confessed. You also *checked* it on a fresh case before trusting it, which is the look-back habit from phase 1 doing its job. ## Move 3: Work backwards Some problems are a maze. Walking forward from the start, every turn looks equally plausible. So start at the exit and walk back - the goal often has only one thing that could lead to it. ```text Goal: end holding exactly 4 liters, with a 5-liter jug and a 3-liter jug. Work backwards: to have 4 in the 5-jug, I'd pour 1 out of a full 5. To pour exactly 1 out, the 3-jug must already hold 2 (it has room for 1). To have 2 in the 3-jug... fill 5, pour into 3 (leaves 2 in the 5), empty the 3, pour those 2 in. Now the 3-jug holds 2. Read it forwards and you have the solution. ``` *What just happened:* forwards, the jug puzzle has a dozen pointless moves you could make. Backwards, each step had almost no choice - "to get here, I must have come from there" pruned the maze down to a path. ## Move 4: Solve a simpler version If the real problem has three hard things tangled together, untangle one. Drop a constraint, lower a dimension, assume the nice case. Solve *that*, then add the hardness back. ```text Real: shortest route visiting 12 cities. Simpler: shortest route visiting 3 cities - trivial, only a few orders. Then 4. You start to see why it explodes, and which ideas (nearest-neighbor, swapping two stops) even make sense to try. ``` *What just happened:* the simpler version didn't solve the 12-city problem, but it taught you the shape of it and which approaches are worth scaling up - far better than guessing at the full thing cold. ## Move 5: Look for an invariant or symmetry This is the deepest move, so it gets its own home in phase 3 - but meet it now. An **invariant** is something that *doesn't change* no matter what moves you make. If you can find one, it often settles the whole problem in a line. ```text Tile a chessboard with dominoes, each covering one black + one white square. Now remove two opposite corners - both the same color, say both white. Invariant: every domino covers exactly one white and one black, always. So any tiling covers equal whites and blacks. But the mutilated board has 32 black and 30 white. Unequal → impossible. ``` *What just happened:* you didn't try a single tiling. The invariant ("one white, one black, every time") made *all* tilings answer the question at once. That's the power - one unchanging fact replacing infinite case-checking. ## For builders These map straight onto how you cut down a bug. "Smallest case" is the minimal reproduction. "Solve a simpler version" is commenting out half the system to localize the fault. "Work backwards" is reading a stack trace from the crash up to the cause. "Find an invariant" is the assertion that should always hold - and the moment it doesn't, you've found your bug. ```quiz [ { "q": "You face '1 + 2 + ... + 1000 = ?' with no formula in mind. What's the natural first move?", "choices": ["Add all 1000 numbers carefully", "Try the smallest cases (n=1,2,3) and look for a pattern", "Give up and look it up", "Guess a round number"], "answer": 1, "explain": "Small cases turn a blank page into data (1, 3, 6, 10...), and the pattern n(n+1)/2 then jumps out." }, { "q": "What makes 'work backwards' powerful on a maze-like puzzle?", "choices": ["It's faster to write", "The goal usually has only one thing that could lead to it, pruning choices", "It avoids arithmetic", "It always finds the shortest path"], "answer": 1, "explain": "Forwards every move looks plausible; backwards each step asks 'what must I have come from?', which often has a near-unique answer." }, { "q": "Why does the invariant settle the mutilated-chessboard problem without trying any tiling?", "choices": ["Because the board is small", "Because every domino always covers one black and one white, so all tilings need equal counts - which the board lacks", "Because corners don't matter", "Because dominoes are symmetric"], "answer": 1, "explain": "One unchanging fact about every domino applies to every possible tiling at once, replacing infinite case-checking with a single contradiction." } ] ``` --- # Stuck Is the Job: Getting Unstuck Here's the secret no one tells you in school: being stuck is not the failure state of problem-solving. It *is* problem-solving. The mathematician at the chalkboard and the beginner at the kitchen table are in the exact same place most of the time - stuck - and the only difference is what they do about it. School trains you to feel that stuck = stupid, because in school the problems were designed to be solvable in two minutes and the clock was running. Real problems aren't like that. The skill that actually separates people isn't speed of insight. It's the ability to sit in not-knowing without panicking, and to keep poking. ## Stuck is data, not a verdict When you're stuck, you've learned something: the obvious approach doesn't work. That narrows the search. Treat the stuck moment as a fork with a list of moves, not a wall. ```text Stuck checklist - run these out loud: 1. Did I actually understand the question? (Re-state it. Phase 1.) 2. Have I tried the smallest case? The next one? 3. What happens if I work backwards from the goal? 4. Is there a simpler version I can fully solve? 5. Is something staying the same no matter what I do? (Invariant.) 6. Have I used every fact in the problem? Which one haven't I touched? ``` *What just happened:* "I'm stuck" became six concrete things to try. Item 6 alone rescues a shocking number of problems - an unused fact in the problem statement is almost always the key you walked past. ## Re-explain it to a rubber duck The single most reliable unsticker costs nothing: explain the problem, out loud, to something that can't help you. A friend, a pet, a literal rubber duck. The act of forming sentences forces the gaps in your own thinking to the surface. ```text You, explaining aloud: "Okay so I need the two corners gone to still be tileable... wait. I keep saying 'two corners' but I never said what color they are. Opposite corners are the SAME color. ...Oh. That's the whole thing. The colors don't balance." ``` *What just happened:* nobody answered you - the duck is rubber. Saying it forced you to be specific about "two corners," and the specificity *was* the insight. Vagueness hides in your head and dies the moment you have to speak it. ## Invariants: the deep move, up close Phase 2 introduced invariants; they earn the spotlight here because finding one is the closest thing to a superpower in this whole craft. The question that unlocks them: **"As I make the allowed moves, what quantity never changes - or only changes in a fixed way?"** ```text Puzzle: numbers 1 to 10 on a board. A move: erase two numbers a, b and write a + b - 1 in their place. Repeat until one number remains. What's the final number - and does the order of moves matter? Ask the invariant question: each move replaces a, b with a + b - 1. The total on the board goes from (... + a + b) to (... + (a+b-1)): it drops by exactly 1, every move. Always. Start total: 1+2+...+10 = 55. Moves until one number left: 9. Final = 55 - 9 = 46. The order never mattered. ``` *What just happened:* the messy "try every order of moves" problem collapsed because one quantity - the total - changed by a fixed amount every move regardless of choice. You didn't simulate anything. You found the thing the chaos couldn't touch. ## Talent is mostly a story about persistence The people who look talented are, overwhelmingly, the people who didn't stop when it got uncomfortable. Productive struggle - wrestling a problem at the edge of your ability, getting it wrong, trying another move - is not the cost of getting good. It *is* the mechanism. The discomfort is the muscle working. So when you feel the locked-door panic from the very first page of this guide, reframe it: that feeling is not evidence you can't. It's evidence you've reached the part where learning actually happens. Run the checklist. Talk to the duck. Find what doesn't change. Loop back to step 2. ## For builders The hardest bugs are won the same way - not by a flash of genius but by a calm checklist run while everyone else panics. Rubber-duck debugging is named for exactly this trick. And the invariant you hunt in a proof is the same assertion you'd add to catch a regression: "this should always be true." When it isn't, you've found the problem. To turn a found pattern into a result no one can argue with, head to [/guides/what-a-proof-is](/guides/what-a-proof-is). ```quiz [ { "q": "What's the most useful reframe of being stuck?", "choices": ["A sign you lack talent", "Data: the obvious approach failed, which narrows the search", "A reason to take a long break", "Proof the problem is unsolvable"], "answer": 1, "explain": "Stuck means you've ruled out the obvious path. That's information, and it points you to the checklist of other moves." }, { "q": "Why does explaining a problem aloud to a rubber duck help so often?", "choices": ["The duck gives hints", "Forming sentences forces hidden vagueness in your thinking to the surface", "It passes the time", "It lowers stress, nothing more"], "answer": 1, "explain": "Vagueness survives in your head but dies when you must say it precisely - and the precision is frequently the missing insight itself." }, { "q": "In the 'a + b - 1' board puzzle, why doesn't the order of moves matter?", "choices": ["Because all the numbers are small", "Because each move lowers the total by exactly 1 regardless of which numbers you pick", "Because addition is commutative", "Because there are only 9 moves"], "answer": 1, "explain": "The total is an invariant that drops by a fixed 1 per move no matter your choices, so the final value (55 - 9 = 46) is forced." } ] ```