12 min · Advanced
Errors, Debugging, and Better Code
Read the useful part of an error, ask for the smallest fix, and only then consider a clearer shape for code that already works.
Learning objectives
- Point to the useful first line of an error, including the file name and the line number.
- Describe a button that does nothing because the script looks up the wrong id, and ask for the smallest fix.
- Review working code for correctness, clarity, and safety, and reject a rewrite you cannot explain.
01
Why this matters
A red error feels like a wall, so people paste the whole project and accept the first giant replacement. Most beginner pages fail for a small reason, such as a name that does not match. This lesson shows that mismatch, then the habit of asking why after the smallest fix. You will not refactor a page that still does not run.
02
Concept
An error is a message from the computer about a line it could not finish. Read the first line first. It often names the failure more clearly than the pile under it. Then find the file name and the line number. The console — the browser panel that lists those messages — is where this text appears. Copy that first line, the file name, and the line number into your prompt. Do not paraphrase the error from memory.
Here is a small broken page, in words and in a short line of code. The button is written as id equals total-btn. An id — a name you give one element so a script can find it — must match exactly. The script calls getElementById with total, which searches for a different name. The console can report: Uncaught TypeError: Cannot read properties of null (reading addEventListener), at the index file, line 18.
Null — a missing value — is what that search returns when no element has the id total. A TypeError — using a value in a way that value does not allow — appears because null has no addEventListener. Paste the error and the two relevant lines. Ask for the smallest fix. After it works, ask why it failed. Refactor — changing the shape of the code without changing what it does — comes only after the click works.
A code review can then look at correctness, clarity, and safety. Correctness asks whether the button does the intended thing. Clarity asks whether a stranger could follow the names. Safety asks whether a secret, a payment, or a reckless rewrite crept in. Documentation — a short note future-you can read — can be four lines at the top of the file. Do not apply a giant rewrite you cannot explain line by line.
03
Real-world example
The button and the wrong name
You build a page with a button that should show a total. The button line is: <button id='total-btn' type='button'>Show total</button>. The script line is: document.getElementById('total').addEventListener('click', showTotal). You click and nothing happens. The console first line says it cannot read addEventListener of null, and it points at line 18 of the index file. The names total-btn and total are not the same, so the search finds nothing. The smallest fix is to make those names match, either in the button or in the script, not both at random. After the click works, you ask why null appeared. Only then would you consider renaming for clarity. A full rewrite is how a one-word mismatch becomes a page you no longer own.
04
Gemini demonstration
A realistic exchange. Open Gemini beside this page and try a version with your own facts.
You
The button does nothing. I want the smallest fix, not a rewrite. Button line: <button id='total-btn' type='button'>Show total</button> Script line: document.getElementById('total').addEventListener('click', showTotal) First console line: Uncaught TypeError: Cannot read properties of null (reading 'addEventListener') at index.html:18 Tell me the smallest change and which name should win. Do not add features.
Gemini
The smallest fix is to make the id match. The button is named total-btn. The script searches for total. Those are different names, so getElementById finds nothing and hands back null. Calling addEventListener on null is the TypeError on line 18. Change the script to look up total-btn, and leave the button text alone. Do not rename both sides in one edit, or you may miss them again. Do not rewrite showTotal, add a library, or restyle the page in this step. Save, double-click, and click the button. If the same first line remains, the old script is still the one the browser opened.
You
The button works after that one change. Now explain why it failed, in plain words. Do not refactor yet.
Gemini
The browser builds the button with the id total-btn. Your script asked for an element named total. No element had that exact id, so the lookup result was null, which means missing. The next step tried to listen for a click on that missing value. Null cannot take addEventListener, so JavaScript stopped and reported a TypeError. The line number told you where the bad lookup was used, not a second bug inside showTotal. Nothing about the math of a total was tested, because the click never arrived. A refactor would be optional later, and only if the names are already consistent and you can explain the new shape.
05
Prompt breakdown
The prompt
The button does nothing. I want the smallest fix, not a rewrite. Button line: <button id='total-btn' type='button'>Show total</button> Script line: document.getElementById('total').addEventListener('click', showTotal) First console line: Uncaught TypeError: Cannot read properties of null (reading 'addEventListener') at index.html:18 Tell me the smallest change and which name should win. Do not add features.
- It states the goal as the smallest fix, which blocks a replacement you cannot read.
- It pastes the button line and the script line so the mismatch is visible.
- It includes the first console line, the file, and the line number instead of a vague summary.
- It asks which name should win, so you get one edit rather than two competing renames.
06
Common mistakes
Usually
The page is broken. Rewrite the whole project in a cleaner style and I will paste whatever you return.
Better
Here are the first error line, the file, the line number, and the two lines involved. Give the smallest fix only.
Usually
It still fails, but I will describe the error from memory as something about a null pointer maybe.
Better
Copy the first console line exactly, including the file name and the line number.
Usually
It works now. Replace it with a framework before I forget.
Better
It works. Ask why it failed, write a four-line note, and refactor only if you can explain the new shape. Refuse a giant rewrite.
07
Practice exercise
Make the names match
Done when: You can point to the mismatched id, state the smallest fix, and explain null without reading the reply aloud.
08
Challenge
Review only after it works
After the button click works, ask for a review with three headings: correctness, clarity, and safety. Correctness: does the click do what the label says. Clarity: could you explain the id and the listener tomorrow. Safety: confirm there is no key, no payment, and no instruction you do not understand. Request documentation as four short lines future-you can read. If the review suggests a refactor, apply it only when you can say what stays the same. Reject any reply that replaces the file with code you cannot narrate. The working click is the prize. A prettier file you do not understand is a new bug.
Hint: Refactor means a new shape with the same behavior. If you cannot name the behavior, do not accept the new shape.
09
Key takeaways
- Read the first line of an error, then the file name and the line number, and paste those rather than a paraphrase.
- A button that does nothing may be an id mismatch: the script searches for a name the page never gave.
- Ask for the smallest fix, then ask why. Refactor only after the page works.
- Review correctness, clarity, and safety, and do not apply a rewrite you cannot explain.
10