Getting Stuck Is the Point

I learned to code in the years when being stuck was the only option. A build that would not compile and an error message that pointed nowhere useful. A concept that refused to click no matter how many times I reread the same page. Not that I was alone with it. There was a whole ladder for getting unstuck: read the docs again, slower. Pull the worn book off the shelf. Dig through an older project that had solved something adjacent. Ask the colleague one desk over, and if the wall outlived all of that, write the problem up carefully and post it to a forum, then wait, sometimes days, for a stranger with the scar tissue to answer.

Now I write code every day with two models at my elbow, and the whole ladder has collapsed into a single rung. I paste the error and the answer comes back before I have finished forming my own guess. That is real acceleration, and I take the trade all day long. But I spent more than a decade climbing the old ladder by hand, and I can feel with some precision what stops happening in that moment. Something used to run in my head between the rungs, and now it does not get the chance to start. I have pointed at that something in earlier essays, always in passing. It deserves the full look.

What the stuck hours were doing

Being stuck was never dead time. It was the state in which my picture of the machine got corrected fastest.

Here is what happens inside a bug that makes no sense. You have a picture in your head of how the system works, and the system just did something your picture says is impossible. So you run experiments. You form a hypothesis, test it, watch it fail, revise. Each failed guess rules out one more way the machine might work. By the time you find the fix, the fix is almost beside the point. What you really did was find the exact place where your picture was wrong, and redraw it.

Even inside the best bug, plenty of the clock goes to thrash, retyping, rechecking the obvious. The learning lives in the moments where a guess meets the machine and dies. But those moments do not happen unless you stayed in the room for the rest.

That is why I still remember, years later, the bug that ate a week, and cannot recall a single feature that shipped smoothly. The smooth feature never touched my picture of the system. The bug redrew it.

Concepts that refuse to click work the same way. You circle them, try a framing, watch it collapse, try another. When the idea finally lands, it lands into a structure your failed attempts built, which is why it stays. Reading, documentation, and review correct a picture too, and I lean on all three. But a correction only holds where an attempt has made a place for it. The explanation you receive before you have struggled slides off. The same explanation after twenty minutes of failed guesses lands, and stays.

The old ladder was slow, and the slowness was not all waste. To ask the colleague or the forum, you first had to compress the problem into a question someone else could answer, and the compression alone solved half of them. Anyone who ever finished a careful write-up and deleted it unposted, answer suddenly in hand, knows the effect. The book never handed you a bare answer either; it made you read the chapter around it, and the chapter is where the next three bugs got prevented. And while you waited for a reply, your own experiments kept running, because waiting empty-handed was unbearable. Help existed at every rung. It just arrived slowly enough that you kept thinking in the meantime.

The removal is silent

Now put a model in the loop. The build breaks, you paste the error, the fix arrives, you move on. Measured in output this is strictly better, and I will not pretend otherwise. The problem is what the trade looks like from inside. Nothing about the moment flags it. The diff is identical to the one you would have written after three hours of struggle. The commit history of someone who understands the system and someone who has outsourced every wall looks exactly the same, right up until the day it does not.

Because the code was never the product of those three hours. The corrected picture was, and the code was its receipt. Take the shortcut and you still get the receipt, while the picture stays wrong in a way no test suite will surface. A learner who never gets stuck is not on a faster road to the same destination. They are on a fast road to a different one, fluent at producing software they hold a thin picture of, and the thinness only shows on the day the AI at their elbow is wrong and nothing in them knows it.

The nostalgic version is wrong

Plenty of what I was stuck on taught me nothing worth the hours. The hunt for a missing semicolon. The build that broke because of an environmental accident nobody could have predicted. The undocumented flag, the version mismatch, the afternoon lost to a tool that was simply bad. Those walls taught me some tooling folklore, and tooling folklore is precisely the cargo the machines now carry better than I ever did. Dissolving that kind of wall instantly is what the tools are for.

The stuck hours that built me were a different kind, and telling the two kinds apart is the whole essay. They were the hours where the obstacle was my own wrong picture. The system was following its own rules, my idea of those rules was not, and the struggle was the process of finding out. One kind was a tax. The other was tuition.

You can tell them apart before the answer comes, not just after. Ask whether the wall is inside the problem or beside it. A version mismatch is beside the problem: solving it changes nothing about how you will write the next program. A function returning a value your picture says is impossible is inside it: solving it changes what you know. When in doubt, treat the wall as inside for twenty minutes and see whether your understanding moves.

Choosing where to be stuck

So the skill has changed shape. It used to be endurance, because getting stuck was mandatory everywhere. Now it is optional everywhere, which turns it into a budget, and the skill is allocation.

I spend mine deliberately. When the retrieval work I do for legal and health domains misbehaves in a way that surprises me, I go in by hand, because surprise means my picture of the system is wrong, and that is the kind of stuck that pays. Surprise is a signal you earn, though. It only fires where a detailed picture exists for reality to contradict, which is why the beginner's test above asks about the wall, not the feeling. When an agent I have delegated to stumbles somewhere I could have predicted, I let the tooling absorb it, because there is nothing left for that friction to teach me. The delegation pipeline I built exists precisely so I can hand off the walls I have already learned everything from. The ones I have not, I still climb myself, on purpose, slower than I could.

Delegate without guilt. The developer who feels vaguely ashamed every time the model unblocks them has the wrong frame, as if virtue lived in the friction itself. It never did. The friction was only ever the means to the picture. Spend it where your picture is still thin.

And spending it is not sentiment, it is economics. As generating code gets cheap, the work that keeps its price is telling right output from wrong, and that judgment is built out of corrected pictures. The habit transfers, too. Every bug that forces a hypothesis against a running system is a repetition of the same motion that later catches a wrong suggestion in code you have never seen before. A confident claim arrives, and something in you knows to test it.

If you are learning now

Get stuck on purpose, and get stuck small. Pick problems sized so that stuck means twenty minutes of real thinking, not a lost weekend. What you want is frequent contact with your own wrong picture, in pieces small enough to work through.

Attempt first, always. Write your broken version, form your guess about the bug, then bring the AI in, and bring it in as the tutor who reviews your attempt, not the chauffeur who drives you past the problem. Ask it where your reasoning failed, not just what the answer is. Argue with it. The tutor's correction lands precisely because your attempt built the place it fits. Skip the attempt and the same sentences teach nothing.

Then test yourself. Switch the AI off and rebuild the thing, and while you rebuild it, say why each part is there, as if a colleague were beside you asking. The rebuild alone can be faked from memory of watched keystrokes. The why cannot. If both survive, the stuck hours did their work and the understanding is yours. If they do not, you hold a receipt for learning that never happened, and it is better to find out now, on something small, than inside a system with your name on it.

The machines will offer you an exit from every wall for the rest of your career, and most of the time you should take it. Many walls are noise, and clearing noise is what tools are for. The right walls are where your picture of the machine gets built. Learn to tell them apart, refuse the exit at those, and let the wall do its work. Getting stuck at the right walls is the point.