Debugging Strategies That Work in Any Language

Beginners often see red text and immediately start editing. Stop. The error message usually names the problem outright — "undefined is not a function", "file not found", "index out of range".

Below it you'll often get a stack trace: a list of every function call that led to the crash. The top lines are where it broke, and the first line that mentions a file you wrote is usually the culprit. Read it slowly, top to bottom.

Then paste the exact wording into Google inside quotes. Someone has hit it before. (Add your language name, like "Python" or "TypeScript", or you'll get results for five other languages.)

Halve the problem until it's small

Here's the technique that works in every language and saves the most time: binary search. Instead of reading code line by line, cut the problem in half.

• Cut the input. Ten thousand rows crashing? Try fifty. Then five. The smallest failing example is nearly a diagnosis.
• Cut the code. Comment out half the function or skip half the steps. Does it still fail? The bug is in the other half. Repeat.
• Cut the history. If it worked last month, use git bisect in Git. Git is the tool that saves versions of your code; bisect automatically tests older versions and tells you which change introduced the bug.

Three or four cuts usually shrink a scary bug into one obvious line.

Print the values you assume are true

Add output to your code — print() in Python, console.log() in JavaScript, System.out.println() in Java. Print the variable just before the crash. Nine times out of ten, the bug sits exactly where your assumption was wrong: the list was empty, the ID was a number instead of text, the date was null.

Most editors also offer breakpoints. Think of a breakpoint as a pause button on your code: it freezes the program mid-run so you can inspect every value.

And try rubber duck debugging: explain your code out loud, line by line, to a colleague or a plastic duck. Saying it aloud forces you to check each step, and you'll often hear your own mistake halfway through a sentence.

What this means for you

Next time something breaks, run this list before you edit anything:

• Write the steps that trigger the bug, and confirm they fail every time.
• Read the error message and stack trace fully, then search the exact text.
• Change one thing, test, and undo it if it didn't help. Keep a short note of what you tried.
• Shrink the input and the code until the cause is tiny.
• After the fix, add a test that fails without your change. That bug never comes back quietly.

Key Takeaways

• Reproduce the bug on purpose before you touch any code.
• Read the whole error message; it usually names the problem.
• Change one thing at a time so you know what fixed it.
• Cut the problem in half repeatedly until the cause is obvious.

Frequently Asked Questions