Everyone has the same first reaction to a stack trace: eyes glaze over, stomach drops, want to close the window. Twenty lines of red, half of them about files you’ve never seen, all of it ending in some inscrutable message like TypeError: Cannot read properties of undefined (reading 'map').
A stack trace is just the computer’s way of saying “I tried, and here’s exactly where I got stuck.” Claude reads that fluently. You don’t have to.
This lesson is about turning “oh no” into “oh, that’s all it was.”
What a stack trace actually is
Before we hand it off to Claude, a tiny demystification. A stack trace is the list of function calls that were in progress when the error happened — read top to bottom, with the most recent call at the top.
It looks intimidating because it’s printed for a machine, not a person: full file paths, line numbers, function names, sometimes call counts. But there are really only three things in there:
- The error message — what went wrong, in one line.
- The file and line — where it went wrong.
- The chain of calls leading up to it — how the program got there.
Claude can extract all three from any trace, in any language, instantly.
The move
You hit an error. You stay calm. You copy the whole trace — all of it, including the empty lines and the parts you don’t understand — and paste it straight into the chat with Claude. The phrasing barely matters:
I'm getting this error. What does it mean and where do I look?
[paste the full trace here]That’s it. Claude will:
- Translate the error message into plain English.
- Point at the file and line where it actually went wrong.
- Often, look at that file directly and tell you what’s likely causing it.
- Suggest a fix — or at least the next thing to check.
The “scary text” is now a paragraph.
Don’t trim it
The single biggest mistake beginners make is pasting only the last line. The bottom of the trace is where the error fired, but the top of the trace is where the error came from. Truncate it, and you’ve thrown away the part Claude needs most.
Paste the whole thing. Don’t editorialize. Don’t pick the line you think matters.
If the output scrolled and you only saw part of it, scroll back up and grab the whole block — usually the first blank line above is your start, and the last line of red is your end.
Errors that don’t have stack traces
Not every error comes with a polite stack trace. Sometimes you get:
- A short, cryptic line in Claude’s working log: “command not found” or “port 3000 already in use.”
- A failed test with a diff between expected and actual.
- A red squiggle in your editor with a tooltip.
- A red box on a webpage when you tried something.
Treat all of these the same way: copy the text and the context — what you were doing when it happened — and ask Claude. Context is the multiplier.
I asked you to start this project and got this. What's wrong?
[paste the output]Compare that with “it doesn’t work” and you’ll see why context matters. (Anyone who has ever tried to help a friend with their computer over text knows the difference.)
The thing that trips people up
When the error points deep into someone else’s code — Node’s internals, a library you’ve never opened — beginners panic. “I don’t know that code, how could I fix it?”
You don’t have to. Almost always, an error that fires there is really caused by your code using it wrong. Say there’s a mistyped import in server/index.js — require('./emial') instead of require('./email') — and trying to start the project blows up with a wall ending in Error: Cannot find module './emial', thrown from somewhere inside Node’s module loader. You paste that wall into the chat, and Claude reads it and tells you:
“This error is thrown by Node’s
requiresystem, but it’s caused byserver/index.js:4— you wroterequire('./emial')and there’s no such file. You meant
That’s the answer you needed. The fix is one line in your file, not anywhere in Node. (You’re allowed to feel relieved.)
Why this lesson exists
Almost everyone who quits learning to code quits during an error. The wall of red feels like a personal failure. It isn’t — it’s just the machine being literal.
Errors aren’t punishments. They’re the most precise feedback you’ll ever get from a computer. Claude turns that precision into something a human can use.
After this lesson, an error should feel less like a wall and more like a door. A scary-looking door, sometimes. But a door.
What’s next
Sometimes the error isn’t in what’s there now — it’s in what changed. “This worked yesterday. What did I do?” That’s a git history question, and Claude is shockingly good at those too. Next lesson.