Reading error messages and stack traces
Errors are directions, not dead ends. Learn to read them calmly and follow them to the cause.
- Read an error message for its three useful parts
- Follow a stack trace to the line that actually matters
- Turn a failure into a minimal reproduction you (or an agent) can fix
The single biggest difference between a frustrated beginner and a calm practitioner is how they react to an error. Beginners see a wall of red and feel defeated. Experienced developers see a set of directions to the problem. Errors are the program telling you, often quite precisely, what it couldn't do.
Anatomy of an error message
Most errors give you three things. Read them in this order:
- The type — what kind of thing went wrong:
TypeError,FileNotFound,NullReferenceException. This alone narrows the problem enormously. - The message — a human-readable description: "cannot read property 'name' of undefined." Read it literally; it's usually telling you exactly the issue.
- The location — the file and line where it surfaced, often with a stack trace showing how you got there.
Don't skim past the first two to panic at the red. The type and message usually are the answer.
Following a stack trace
A stack trace is the chain of function calls that led to the error — the trail of breadcrumbs from where execution started to where it broke. Read it top to bottom is most-recent-first in many languages (bottom-up in others — check which). The key skill:
- The top frames are often inside library code you didn't write.
- Scan down to the first line that lives in your code — that's almost always where to start looking.
The error often surfaces deep in a library, but the cause is the value your code passed in. Find your line, then ask: what did I send here that it didn't like?
The error vs the root cause
"Cannot read property 'name' of undefined" appears at the line that touched
.name. But the real bug is wherever that value became undefined — maybe a
function returned nothing, or a lookup missed. The displayed line is the
symptom; trace backward (often one or two steps) to the cause. Fixing
the symptom without the cause just moves the crash somewhere else.
Make a minimal reproduction
When you're stuck, shrink the problem until only the failure remains: the smallest snippet, smallest input, fewest steps that still triggers it. This does three things — it often reveals the cause on its own, it makes the bug repeatable, and it gives you (or an AI agent) something precise to work on.
Pasting a raw stack trace into an AI agent works far better when you add the minimal reproduction and what you expected to happen. "It's broken" is hard to help; "this input produces this error, I expected that" is easy.
Where to go next
Errors are one kind of history. Next we look at another — version control — and why keeping a record of changes is a tool for thinking.