What to do when you are stuck on a problem
If you want to know what to do when you are stuck on a problem, start with a plain fact about being stuck: it rarely means you have run out of ideas. It usually means you keep trying the same kind of idea, with small changes, and expecting a different result. The way out is to stop, see what you have already tried, and change direction on purpose.
Five moves do most of the work. List what you tried and how each attempt went. Restate the problem in one line. Explain it out loud, step by step. Step away for a set time. Then pick one new attempt that comes from a different direction. A journal of problems such as Problem Graph is built around the first move: a problem goes down in one line, and every solution tried is attached with its outcome, marked worked, partly or failed.
A problem you cannot solve takes up room even when you are not working on it. You think about it in the shower, on the bus, at night. Each failed attempt adds a little more weight, and after a while the problem feels bigger than it is.
Part of that weight comes from memory. When nothing is written down, you carry every attempt in your head, and the head is a poor record. You forget what you already tried, so you try it again. You remember the failures more than the partial wins, so you underrate how close you came. You lose track of why an idea did not work, so you cannot tell whether a small change would fix it.
Five moves take that load out of your head and onto a page, where you can look at it.
Move one: list every attempt and its outcome
Write the problem at the top of a page. Under it, list every attempt you have made, one per line. Next to each, write what happened in one word: worked, partly or failed. Then add one short reason.
This list does three things at once. It stops you from repeating an attempt you already made. It shows you the pattern in what you tried, which is often a single kind of fix with small variations. And it gives you the partial wins, which are clues, not failures.
Keep the failed attempts on the list. It is tempting to cross them out, but a failed attempt with its reason tells you something true about the problem. A fix that failed because you forgot to do it is a different lesson from one that failed even though you did it every day.
Move two: restate the problem in one line
Once the attempts are on the page, read the problem line again. Often the line you wrote at the start was a guess at the cause, not the problem itself. "Too much goes on takeout" is a guess. "Money is gone before any can be saved" is the problem.
Rewrite the line so it says what is wrong and how you would know it is fixed, without naming a solution. If you have three or four candidate lines, write all of them and pick the one that the failed attempts did not touch. A guide on how to break a big problem into smaller problems helps when the line turns out to hold two or three problems at once.
Move three: explain it out loud, step by step
Programmers have a name for this move. Rubber duck debugging is a technique where a programmer explains their code step by step, aloud or in writing, to reveal mistakes and misunderstandings. The listener can be a toy duck, since the listener does not matter. What matters is that you have to say every step in order, and the step you skipped in your head is often where the problem sits.
The same works for problems outside code. Say what happens, in order, from start to finish. "On the 1st, pay comes in. On the 3rd, money goes into the budget app. On the 15th, rent and bills go out." Speak slowly and do not jump ahead. When a step makes you pause, or you hear yourself say "and then somehow", write that step down. It is where to look next.
Move four: step away on purpose
Stepping away can feel like giving up. It is not, if you do it on purpose. Psychologists call it incubation): the unconscious processing of a problem that has been set aside for a time, which may lead to insight. Graham Wallas proposed it in 1926 as one of four stages of the creative process: preparation, incubation, illumination and verification.
The same page notes that incubation substantially increases the odds of solving a problem, and that it works best with long breaks and light mental work during the break. So do something easy. Walk, cook, sort a drawer. Do not swap one hard problem for another.
Two rules keep a break from turning into avoidance. Do the first three moves before you step away, so your mind has the full picture to work on. And write down a date to come back, such as "Sunday morning", so the break has an end.
Move five: pick one new attempt from a different direction
When you come back, read the page from the top. Look at the list of attempts and ask what kind of fix they all are. If every attempt was a way to spend less, try a way to save first. If every attempt was a change you make alone, try one that involves someone else.
Other people's experience is the fastest source of a new direction. Someone with a similar problem has often tried the fix you have not thought of, and knows whether it worked. Some problem journals show similar problems other people shared and which of their solutions worked, so you can borrow one with a link back to where it came from. You can also ask directly; a guide on how to ask for help with a problem you cannot solve covers how to put the question.
Pick one attempt, not three. Write what success looks like and when you will check. Then do it, and add its outcome to the list.
A worked example: the savings that never happen
Here is the five-move process on one everyday problem: you want to save $200 a month and, after three months, have saved nothing.
The list. You write three attempts. A budget app: failed, because you stopped opening it after a week. Cash envelopes for food: partly, because food spending went down but the money still went somewhere else. A rule of no takeout on weekdays: failed, because the money saved was spent by the end of the month anyway.
The one line. All three attempts were ways to spend less. Your first line was "Too much goes on spending." The new line is "Money is gone before the 15th, so nothing is left to save."
Out loud. You say the month in order. Pay arrives on the 1st. Rent and bills go out on the 15th. Saving was meant to happen "at the end of the month, with what is left". Saying it out loud, you hear the gap: saving comes last, so it never happens.
The break. You take two days off the problem and write "back on Sunday" at the bottom of the page.
The next attempt. On Sunday, the new direction is clear: save first, not last. You set $200 to move to savings on payday, before anything else. You write the success line, "$400 in savings by the end of the second month", and the date to check.
Frequently asked questions
How long should you stay stuck before changing approach?
Change approach when you notice you are repeating the same kind of attempt, not after a set number of days. If your last two attempts were small changes on one idea and both failed, it is time to stop and make the list.
Is stepping away from a problem the same as giving up?
No. A planned break, after you have written the problem and your attempts down and set a date to return, gives your mind time to work on it. Giving up has no return date.
What if every attempt has failed?
Then the problem line is probably wrong, or the attempts all came from one direction. Rewrite the line without naming a fix, and look for a solution someone else used on a similar problem.
Why does explaining a problem out loud help?
Saying each step in order forces you to fill gaps your head skips over. The step where you pause or get vague is often where the problem is.
Getting unstuck is a change of direction
Being stuck is rarely a lack of effort. It is effort pointed the same way again and again. Writing down each attempt with its outcome shows you that direction. Restating the problem and saying it out loud show you where the gap is. A planned break gives your mind room, and a new attempt from a different direction, often borrowed from someone who faced the same problem, turns the list from a record of failures into the path to what worked.
Problem Graph
Every problem you carry, on one map. Solved together. Visit problemgraph.vlvd.net
