Your First Fix: Reading Errors and Iterating

An error message looks scary because it is written for programmers. But underneath, it is almost always saying one simple thing:

"I got to step 12 of your recipe and something was missing."

That is it. It is the most helpful thing your computer ever tells you, and beginners almost always ignore it and just re-ask the AI to "fix it".

How to read one

Most error messages have three useful parts. Find them in this order:

• The type — a couple of words like not defined, not a function, or cannot read properties of null. This is the category of problem.
• The place — a file name and a line number, like app.js:42. This is where it gave up.
• The trail — a list of steps underneath, newest at the top. This is how it got there.

Three common ones, in plain English:

• "X is not defined" — you used a name the code has never heard of. Usually a typo or something never created.
• "Cannot read properties of null" — the code went looking for something and found nothing there. Very often it went looking too early, before the thing existed.
• "X is not a function" — you tried to do something that is not an action.

Where errors hide

Many errors never show up on the page — they go to a place called the console. In any browser you can open it with right-click → Inspect → Console. Red lines are errors.

If your app "does nothing" when you click a button, the console is the first place to look. There is very often a red line there explaining exactly why.

Feeding it back properly

This is the part that separates a five-minute fix from an hour of going in circles.

Weak: It's broken, fix it.

Strong:

When I click the Add button with the text box empty, nothing happens and the console shows: "TypeError: Cannot read properties of null (reading 'value')" at app.js line 42. I expected it to show a message asking me to type something first. Please fix that one thing only.

Notice the four ingredients: what you did, what happened, the exact error text, and what you expected instead. Copy error messages exactly — do not retype them from memory.

And "fix that one thing only" matters. Without it, AI tools cheerfully rewrite half your app, and now you have new problems you did not have before.

The loop

This is the rhythm of the whole job:

• Change one thing.
• Run it.
• Check it — including the thing that used to work.
• Repeat.

The third step is the one people skip. Fixes break other things surprisingly often, and you find that out much more cheaply now than later.

If a fix makes things worse twice in a row, stop patching and ask for that piece to be rebuilt from scratch instead. Knowing when to stop patching is covered in Fix It Manually or Regenerate?.

Your turn

Take one thing from your break-it list in stage 4 and fix it using the strong-report format above. Then run the whole list again to check you did not break something else.

That is Phase 1 — the weekend is done

Look at what you can now do. You described an app in words and got real code. You ran it on your own machine. You tried to break it, on purpose, like a professional. You read an actual error message and fixed it.

That is the complete loop of building software. Everything after this is the same four steps, done better and on bigger things.

Phase 2 is not a weekend. It is a library — one topic at a time, whenever you want. There is no rush and no finish line.