Measure Twice, Prompt Once
choutosThere's a garage in Ourense — not the fancy kind with diagnostics machines and waiting rooms with...
There's a garage in Ourense — not the fancy kind with diagnostics machines and waiting rooms with coffee, but the kind where oil has seeped into the concrete so deep it's become part of the floor. Moncho has worked there for forty years. Maybe forty-five. He stopped counting when his knees started predicting rain.
A young man brings in his car. Won't start. "The battery," he says, confidently. "I already looked it up online."
Moncho doesn't touch the hood. He asks the young man to sit inside and turn the key. He listens. Then he asks when it started. Whether it's worse in the morning. Whether the lights flicker when the engine tries.
The young man grows impatient. "I told you, it's the battery. I read three forums. Can you just replace it?"
Moncho shrugs, opens the hood, and points at a corroded wire thinner than a shoelace. "Your battery is fine," he says. "But your alternator hasn't been charging it for two weeks."
I've been watching programmers work with these new AI tools. Claude, Copilot, Cursor — names that sound like spacecraft, and perhaps they are. They can write code faster than any human. They can fix bugs in seconds. They can turn a rough idea into a working program before you've finished your coffee.
And yet.
And yet I keep seeing the same thing. A young developer stares at an error message. Red text, intimidating. They copy it, paste it into the machine, and say: fix this. The machine tries. Sometimes it works. Often it doesn't. The developer pastes again, adds more context, grows frustrated. Why won't you just fix it?
They're doing what the young man did with his car. They've diagnosed the problem before they understood the system.
There's a book — published in 1945, when my father was learning to walk and Europe was still counting its dead. A Hungarian mathematician named George Pólya wrote it for his students at Stanford. How to Solve It, he called it, which is either the most arrogant or the most humble title imaginable. Probably both.
Pólya's first rule is almost embarrassingly simple: understand the problem.
Not "solve the problem." Not "fix the problem." Understand it. What are the parts? How do they connect? What do the words actually mean?
I know, I know. You're thinking: of course I understand the problem. It's right there in the error message. Line 47. Something about a null reference.
But do you understand what a null reference is? Not the definition — anyone can Google a definition. Do you understand why it happened? What your code expected versus what it got? The path the data took before it arrived at line 47 and found nothing there?
This is the difference between Moncho and the young man with the dead car. The young man knew the symptom. Moncho understood the system.
Here's what I've started doing, and it feels almost like cheating because it works so well.
Before I ask the machine to fix anything, I ask it to explain.
"How does authentication middleware work? Not in general — in this codebase, with these files. Draw me a picture. Show me the flow."
"What happens when a user scrolls to the bottom of this list? Which functions fire? In what order? Where does the request go?"
The machine is remarkably good at this. Better than any documentation, because it can read your actual code and show you what's really happening, not what someone intended three years ago when they wrote the README.
And something strange happens when you do this. By the time the machine finishes explaining, you often see the bug yourself. It's sitting there, obvious, in the diagram the machine drew. The scroll detector that never fires because something else is intercepting the event. The request that goes to the wrong endpoint because someone copy-pasted from a different file.
You don't even need to ask for a fix. You understand the system now. The fix is obvious.
Pólya was teaching mathematics, not programming. His students were proving theorems, not debugging APIs. But the principle is the same: you cannot solve what you do not understand.
The machine is powerful. Incredibly, almost absurdly powerful. But it responds to what you give it. If you give it a symptom and say "fix," it will guess. Sometimes brilliantly, sometimes not. If you give it a question — help me understand — it will teach. And once you understand, the fixing becomes almost trivial.
Moncho never replaced a battery until he knew the charging system worked. He never touched an engine until he'd listened to it run.
The young developers copy error messages and pray. The old ones ask questions first.
I'm not saying this is the only way. The machines are getting smarter. Perhaps soon they'll understand the system automatically, diagnose without being asked, fix without explanation.
But I suspect not. I suspect that understanding will always be valuable, that the programmer who knows why will always outperform the one who only knows what. The tools change — they always change — but the craft remains.
Pólya knew this in 1945. Moncho knows it now, in his garage in Ourense, with oil in the concrete and rain in his knees.
The question before the answer. The diagnosis before the repair.
Measure twice, prompt once.
Enfin.
The book is "How to Solve It" by George Pólya (1945). Dense, mathematical, not for everyone. But the first twenty pages will change how you think about problems. A colleague, Ignasi Bosch, pointed me to it this morning. Some debts you repay by passing them on.