Errors are normal — and they're on your side
An error message feels like the computer scolding you. It isn't. It's the computer trying to help — telling you exactly what confused it, and usually where. A red error is not "you failed." It's "here's the clue."
Professionals aren't people whose code never breaks. They're people who've made peace with breakage. Something not working is the normal state of coding, right up until the moment it works. Breathe. Read the clue. Fix one thing.
Read the message — it usually tells you what and where
Most error messages have two gifts in them: what went wrong and where (a file and a line number). Beginners panic and skim; pros slow down and read. Here's a typical one:
TypeError: Cannot read properties of undefined (reading 'name')
at showUser (app.js:42:16)Read it plainly: the what is "tried to read .name on something that doesn't exist," and the where is "app.js, line 42." You now know more than enough to start. Go look at line 42.
When there's a big wall of red, the first line and the first file/line-number that's yours are what matter. The rest is usually the error's travel history.
The browser console
When a web page misbehaves, its errors don't show on the page — they show in the console, a hidden panel in your browser. Open it:
- Right-click the page → Inspect, then click the Console tab.
- Or press
⌥ ⌘ J(Mac) /Ctrl ⇧ J(Windows).
Red lines there are errors; they follow the same "what + where" shape. Any time a page "just doesn't work," open the console first — the answer is almost always sitting right there.
Print to see what your code is actually doing
Sometimes there's no error — the code just does the wrong thing. The oldest, best trick is to make your code show its work: print values as it runs, so you can see where reality drifts from what you expected.
// JavaScript — shows up in the browser console
console.log("user is:", user)
# Python — shows up in your terminal
print("user is:", user)Drop one in just before the line that breaks. Is the value what you thought? Often the bug is obvious the moment you can actually see the value — it was empty, or a number was secretly text.
Ask Ada well — and rubber-duck
Ada is a fantastic debugging partner, but the quality of the help depends on the quality of the ask. The rule: give the whole clue.
I got this error — here's the full message: [paste the entire red error]. It happened when I clicked the "Save" button. Here's the file. What's going on, and how do I fix it?
Paste the full error, say what you were doing when it happened, and point at the file. That's ten times more useful than "it's broken."
Programmers keep a rubber duck on the desk and explain the problem to it out loud. Half the time you spot the answer mid-sentence — the act of explaining forces you to slow down. Ada is a duck that talks back.
When you're truly stuck
- Copy the exact error into a search engine. Someone has hit it before — usually thousands of someones. Results from Stack Overflow and official docs are gold.
- Read the official docs for the tool you're using. Dry, but correct.
- Change one thing at a time, and re-test after each. Changing five things at once means you won't know which one mattered.
- Take a break. A surprising number of bugs solve themselves on a walk. Your brain keeps working; you just stop staring.
Change one thing, then test. The fastest way to turn one bug into three is to change a bunch of stuff at once and lose track of what did what. Small step, test, repeat — it feels slower and is much faster.
That's the whole craft: stay calm, read the clue, look at the value, change one thing. Do that and there's no bug you can't outlast. Every expert you admire got there by fixing thousands of these — you're just getting started on yours.