Getting Unstuck, Not Getting Finished

Four kinds of stuck

"I'm stuck" is four different situations, and each wants a different amount of help. Naming which one you are in is most of the skill.

1. 1I don't understand what is being asked. Cheap to fix, no learning cost. Get it clarified immediately.
2. 2I'm missing a fact or a formula. Also cheap. Knowing that the integral of 1/x is ln|x| is lookup, not insight.
3. 3I know the method but the execution has gone wrong. This is where the learning is. Guard it.
4. 4I have an answer and it's wrong and I can't see why. This is where the *most* learning is, and it is the one people give away fastest.

Cases 1 and 2 — just ask. Nobody builds character by not knowing what a word means. Cases 3 and 4 are the ones where the phrasing of your request decides whether you come out of it knowing more.

The minimum viable hint

Models are trained to be helpful, and left alone they will hand you the whole thing. You have to say otherwise, explicitly, every time. These work:

Do not give me the answer. Ask me one question that would
get me unstuck.

Give me the smallest hint that lets me continue. If that
isn't enough I'll ask again.

Here is my working through line 6. Is line 6 correct?
Answer yes or no. Nothing else.

I think the problem is in my choice of method, not my
arithmetic. Am I right about that? Don't say which method.

That last one is worth practising. You are asking it to confirm the *shape* of your error while you keep the work of locating it. It is the highest-value question in this lesson.

Most chat tools let you set a standing instruction — custom instructions, a saved system prompt, a project. Put the hint rule there once and stop retyping it:

When I ask about schoolwork, default to hints and questions.
Give full solutions only when I say "full solution".

Debugging is the clearest case

Code makes this concrete because the error message is right there.

TypeError: 'NoneType' object is not subscriptable

The fast path is to paste your file and the error and get corrected code back. You will ship in ninety seconds and hit the same error next week, because NoneType errors are a category, not an incident.

The slower path:

Here's the traceback. Don't look at my code yet.
What does this error class usually mean, and what are the
two or three most common causes?

Then you go and find yours. Third time you meet that error, you will not need to ask at all. That is the whole return on the extra four minutes.

Struggle is not the ingredient

Here is where a lot of study advice goes wrong, and it is worth being precise.

The research on productive failure — Manu Kapur's work, and the desirable-difficulties literature generally — is about struggle *followed by instruction*. Attempt, fail, then get taught. Struggle alone, with no resolution, is not a learning condition. It is just an unpleasant afternoon.

So timebox it. A workable rule: if you have made no forward progress in six or seven minutes, the struggle is done producing value. Not the six minutes when you were slowly assembling something. The six minutes of rereading the same line.

At that point, get the smallest hint and carry on. You have banked the benefit. Sitting there for another twenty minutes out of pride costs you the next topic.

Close the loop

One step that people skip, and it converts the whole thing.

After the hint got you moving and you finished the problem — do it again from a blank page, later that day. No hint, no notes. Two minutes if it went in. If it did not go in, that is worth knowing now, cheaply, rather than in an exam hall.

And keep a running list of what you needed hints for. Not to feel bad about. That list is a map of exactly where your understanding is thin, and it is far more accurate than any feeling you have about which topics you are weak on. When revision starts, you will not have to guess.