Debug systematically instead of guessing

Changing things at random until a bug disappears is slow, and even when it works you learn nothing about why. Systematic debugging means isolating the problem: what you expected, what actually happened, and the smallest case that reproduces it. It is the same habit senior engineers rely on, applied to smaller problems, and it compounds every time you use it.

Stop guessing, start observing

When something breaks, the urge is to start editing code immediately. Resist it for a minute. Every random edit adds a new unknown: if the bug goes away you don't know which change fixed it, and if it doesn't you may have created a second bug on top of the first.

Instead, treat the bug as a question the program is answering incorrectly, and collect evidence before touching anything:

• What exactly did you do right before it broke?
• Does it happen every time, or only sometimes?
• Is there an error message, a stack trace, or a wrong value you can see?

Observation is cheap. Guessing feels faster, but it usually costs far more time in total.

Write down expected versus actual

"It doesn't work" is not something you can debug. Turn it into two precise sentences: what you expected to happen, and what actually happened.

For example: "I expected the cart total to be 15 after adding items priced 10 and 5. It shows 105." That sentence already hints at the cause, because 105 looks like two pieces of text glued together rather than numbers added up.

Writing this down forces you to be specific. It also gives you a clear definition of "fixed": the bug is gone when the actual behaviour matches the expected behaviour for those exact steps. It is also exactly what you would need to write if you asked someone else for help.

Read the error before you react

Error messages are evidence, not noise. A typical JavaScript error tells you what went wrong and where:

TypeError: Cannot read properties of undefined (reading 'name')
    at renderUser (app.js:14:22)
    at main (app.js:30:3)

Read it from the top. The first line says some value was undefined when the code tried to read .name from it. The stack trace says this happened at line 14 of app.js, inside renderUser, which was called from main on line 30.

So the real question is not "why is my app broken" but "why is the object on line 14 undefined, and where did it come from?" That is a much smaller problem to investigate.

Shrink it to the smallest reproduction

A bug inside a 400-line file with ten steps to trigger it is hard to reason about. Make it smaller until the cause has nowhere to hide.

• Find the shortest sequence of steps that still triggers the bug.
• Remove code, inputs, or features that aren't needed to reproduce it.
• If you can, copy the suspicious logic into a tiny standalone script with hard-coded input.

If the bug disappears when you remove something, that piece is involved, so put it back and look closer. If it still happens without it, you've ruled that piece out. Often the act of shrinking the problem reveals the cause before you even finish.

One hypothesis, one test

Now form a single, testable guess and check it with the smallest possible experiment. For the cart example, the hypothesis might be "the prices are strings, so + joins them instead of adding them":

console.log(prices, typeof prices[0]);
// [ '10', '5' ] string

The log confirms it, so the fix is to convert with Number() before adding. If the log had shown numbers, the hypothesis would be ruled out, and that is still progress: you've narrowed the search.

When you don't know where to look, split the problem in half. Check the value halfway through the flow, or halfway through your recent changes, and keep halving until you find the exact point where good turns into bad.

What to do now

Pick the next bug you hit in your project, or one you fixed recently by trial and error, and work through it deliberately:

1. Write one sentence for expected behaviour and one for actual behaviour.
2. Read the full error message and note the file and line it points to.
3. Reduce it to the fewest steps that still reproduce it.
4. Write down one hypothesis and test it with a single log or check.
5. After fixing it, rerun the original steps to confirm, and note the cause in your commit message.

Keeping a short log of hypotheses you tried makes the process visible, and it gives you real stories to tell when someone asks how you solve problems.