6.2
Errors Are Data
Why this exists
This is the single most-used skill in the job you're being hired for. Something stops working, and the only evidence you have is a wall of text nobody wrote for a human to read.
Most people paste the whole wall into Claude and hope. That works often enough to be a habit and badly enough to be a problem — because you learn nothing, and the day it doesn't work you have no next move.
The idea
An error is not a complaint. It's a witness statement, and it's usually telling you exactly what happened.
The reason errors feel unreadable is that they're written for whoever wrote the code, and they put the useful part in an unexpected place. Once you know where to look, most of the wall is noise.
Four things, in the order you want them:
| Look for | Where |
|---|---|
| The actual message | Usually the last line, not the first |
| The file and line number | Right next to it |
| What was being attempted | The line above the failure |
| When it started | Timestamps — and what changed then |
That first one catches people out constantly. A stack trace reads bottom-up: the last line is the actual error, and everything above it is the route it took to get there. Start at the bottom.
Three questions turn a wall of text into a diagnosis:
- What was it trying to do?
- What did it get instead?
- What changed?
Question three is the one that solves things fastest and gets asked least. Systems that ran fine yesterday and don't today have almost always had something change — a deploy, a setting, an expired key, someone else's edit. git log and a timestamp answer it more often than reading code does.
Use Claude, but make it show its working. Don't ask "fix this." Ask "what does this error mean, and what would you check first?" You get an explanation you can verify instead of a change you can't evaluate — and everything from 2.1 still applies. It will confidently misdiagnose a log it doesn't have enough context for.
The habit that separates people who get good at this: read the error yourself before you paste it anywhere. Ten seconds. Even if you only get half of it. That's how the skill actually builds, and within a month you'll be reading them faster than you can paste them.
Do
Use a real error. Break something in the project from Level 5 if you need one.
- Get an error. Don't fix it yet.
- Read it yourself first. Ten seconds, no help. Write down what you think happened.
- Find the last line. Read it as a sentence. Does it change your guess?
- Find the file and line number.
- Find when it started. Check
git logaround that time — what changed? - Now ask Claude: "What does this error mean, and what would you check first?" Compare its answer to your guess.
- Write
diagnosis.md: what it was trying to do · what it got instead · what changed · what you'd check first. - Only then fix it — and confirm the fix from the actual behaviour, not from the absence of the error.
Step 2 is the whole lesson. Your first guess being wrong is fine and expected. Not making one means you never build the skill.
Done when
Never do
Don't paste an error and run whatever comes back. You'll get a change you can't evaluate to a system you don't fully understand — and if it's wrong you won't know until later.
Don't fix an error you haven't understood. An error that disappears without you knowing why hasn't gone. It's moved, and you've lost the evidence that would have found it.