The one idea
When stuck, your instinct is to ask "what is the answer?" That question has no entry point. It is too big, and it is why you have been refreshing the same page for forty minutes.
Replace it with a smaller one:
What exactly is preventing me from solving this?
That question always has an answer. Sometimes it is "I don't know what this word means"; sometimes "I don't know whether the data is even arriving". Neither solves the problem — both are progress, and progress is all you need.
This is the most durable skill on this site. Tools change every few years; this procedure has not changed in decades. It works on software, spreadsheets, forms, appliances, bureaucracy and other people's badly written instructions, and it separates people who need help constantly from people who need it occasionally.
Instead of asking what the answer is, work out exactly what is blocking you. That question always has an answer.
Run a fixed procedure: state the problem, list knowns and unknowns, search precisely, test the smallest piece, compare expected against actual.
Debugging is binary search over a chain of assumptions. Each test should cut the space of possible causes roughly in half, and the fastest tests are the ones that check whether a step happened at all.
The protocol
Ten steps, in order. Most problems resolve by step five. Do not skip ahead — the early steps feel like a waste of time and are not.
The ten steps
1 of 10Restate the problem in one sentence, out loud. Not "it's broken", but: "When I click Export, nothing downloads and no error appears." A surprising share of problems die here, because saying it precisely forces you to notice something you had been sliding past.
What "stuck" actually means
You are in one of four states. Naming which changes what you do next.
| State | What it feels like | What to do |
|---|---|---|
| I don't understand the words | Everything looks like jargon | Look up three terms. That is the whole blocker. |
| I don't know where the failure is | It just doesn't work | Smallest possible test. Bisect the chain. |
| I know where, not why | This line is wrong, no idea why | Search it exactly. Read the official docs. |
| I know why, not how to fix it | I understand it, I can't do it | This is the point to ask someone. |
The last row matters. Asking in state four is efficient and reads as competent. Asking in state one reads as not having tried, because you have not.
Problem: a VLOOKUP returns #N/A for about half the rows.
Restate: "For roughly half the rows the lookup returns #N/A; the rest work."
Know: the formula is identical down the column; the lookup table contains the values; it worked when the file was smaller.
Don't know: whether the failing values are present in the lookup table in the exact same form.
Smallest test: take one failing row. Copy its lookup value into an empty cell,
the matching table value beside it, then type =A1=B1. It returns FALSE — not
the same, despite looking identical on screen.
Cause: trailing spaces, or numbers stored as text after a paste.
That diagnosis takes four minutes and requires knowing nothing about VLOOKUP, only testing one cell instead of staring at the column.
Problem: a portal will not accept your document upload. No useful error, just "upload failed".
Know: the file exists and opens; the site loaded fine.
Don't know: whether the failure is size, format, filename, or the site.
Smallest tests, in order of cost: the stated size limit against your file. Accepted formats — many portals take JPG and PDF but not HEIC, which phone cameras produce by default. Rename to remove spaces and special characters. Try another browser.
That sequence solves most upload failures because each step tests one thing. Uploading the same file eleven times tests nothing.
Try this
Someone tells you: "The report won't generate. I've tried everything."
Write the three questions that would convert this into a specific problem.
Your challenge
Level 3 · IndependentNext time you get stuck on anything — work, a form, a device, a piece of software — do not try to fix it for the first ten minutes.
Instead write the four lists: the one-sentence problem, what you know, what you don't, and the smallest possible test. Then run only that test.
Success criterion: you can name the exact point in the chain where things stop behaving as expected, even if you have not fixed it. Locating the failure is the deliverable — fixing it is usually easy afterwards, and often someone else's five-minute job once you can say exactly where it is.
What people usually get wrong
- Trying the same thing repeatedly. If it did not work twice, it will not work the sixth time.
- Changing several things at once. Now you cannot tell what mattered, and you have added new problems.
- Skipping the restate step. It feels like a wasted thirty seconds. It is the step that most often solves the problem outright.
- Searching your whole error message including your filenames. Zero results, because nobody else has your filename.
- Reading a forum thread before the official docs. Forums are excellent for odd cases, terrible for basics, and half the answers are for an older version.
- Asking an AI to fix it before you can state the problem. You get a confident answer to a question you did not ask.
- Not writing down the fix. You will be here again. Everyone is.
How someone experienced does it
Experienced people spend most of their time on step seven, and they pick the test that eliminates the most possibilities rather than the one that feels closest to the answer. In a six-stage chain they test stage three first, because either result clears half of it. Beginners test stage one and walk forward, which is five times slower.
They also suspect their own assumptions before suspecting the tool. "The data is fine", "the file saved" and "I'm looking at the right sheet" hide most faults. When properly stuck, they go back and verify what they were most certain about — and it is astonishing how often that is where it was.
The third habit is a hard timebox. Thirty or sixty minutes, decided in advance; when it expires they ask someone or do something else. Not because persistence is bad, but because after an hour you are no longer generating new hypotheses — you are re-running old ones with more frustration. See asking-a-question-that-gets-answered for what to do when it expires.
When not to use this
Do not run the full protocol when a known procedure exists. If the wifi is down, restart the router. Standard fixes exist because they work, and ten minutes of formal diagnosis before trying the obvious thing is its own kind of stuck.
Do not run it when the problem is urgent and someone nearby knows the answer. Production down, a client waiting, an hour to the deadline — ask immediately. The protocol is for learning and for problems you own, not for proving independence during an emergency.
Prove it
Start a file called stuck-log. Anywhere — notes app, text file, notebook.
Every time you get stuck and then unstuck, add three lines: what broke, the actual cause, what fixed it.
After twenty entries, read it. The same three or four causes will account for most, and you will have stopped losing afternoons to them. It is the highest-return document most people never write.
Keep learning this
Paste this into any AI assistant. It turns the assistant into a tutor that tests you instead of just answering you.
Act as an experienced practitioner who is good at teaching. I have just learned explaining what is likely blocking me on a specific problem, without giving me the fix. Assume I am intelligent but relatively new to this — treat me as beginner level. Work through this in order, and wait for my reply at each step: 1. Ask me 5 questions that test whether I actually understood explaining what is likely blocking me on a specific problem, without giving me the fix. Do not reveal the answers yet. 2. After I answer, tell me which parts I got right, which I got wrong, and which I only half-understand. Explain only what I misunderstood — do not re-teach what I already know. 3. Give me one practical challenge based on something I could genuinely encounter at work or in daily life. Do not solve it for me. 4. Evaluate my solution the way an experienced person would judge it, including what a professional would have done differently. 5. Tell me what to learn next, and why that comes next. 6. Give me trustworthy sources for deeper study — prefer official documentation, primary research or standards bodies over blogs and videos. Rules for you: no buzzwords. No motivational filler. Say "I'm not certain" when you are not certain, and tell me which parts of your answer I should verify myself. Clearly separate facts from your recommendations and your opinions.
Become independent at this
Use this when you want a path from where you are to actually good, with checkpoints you can test yourself against.
I want to become independently capable at getting unstuck on your own — not permanently dependent on AI, tutorials or step-by-step guides. Design a progression for me with five stages: Beginner, Guided practice, Independent practice, Real-world application, Professional level. For each stage tell me: - what I must know - what I must be able to do without help - the mistakes people make at this stage - one practical challenge - one real project that would prove I reached this stage - one way I can test myself honestly Then tell me the signals that I am ready to move to the next stage, and the signals that I have skipped ahead too early. Keep the theory to the minimum I actually need. Focus on ability I can transfer to situations you and I have not discussed.