The parts of an error message that actually matter
Most error messages have three useful parts: the error type, the message, and the stack trace. New developers read the message and stop — experienced developers scan the stack trace first. The message describes what broke; the stack trace tells you where your code triggered it. The bottom of the stack is the framework or runtime internals (not your bug). Your code appears near the top — that's where to look.
Example: a TypeError: Cannot read properties of undefined (reading 'map') tells you: something you expected to be an array is undefined. The stack trace shows the component and line number. The fix is not at the line where .map() is called — it's one level up, where the data was fetched or passed as a prop. The error location and the bug location are often different.
A systematic approach to errors you've never seen
- 1.Copy the exact error message (not a paraphrase) and search it with the library or framework name appended. Most errors have existing GitHub issues, Stack Overflow answers, or documentation notes with the exact fix.
- 2.Check what changed last. If the code worked yesterday and fails today, the cause is almost certainly in the recent change — a dependency update, a config change, or new code. Git diff against the last working commit.
- 3.Reproduce in isolation. Strip the error down to the minimum code that reproduces it. The process of isolating it often reveals the cause before you find the answer.
- 4.Check environment differences. Works on your machine but not in CI? Fails in production but not locally? The bug is almost certainly an environment variable, a missing dependency, or a Node.js version difference.