Most debugging advice is a list of tools. console.log, breakpoints, strace. Tools matter, but the thing that actually cuts my debugging time in half is a mindset: treat every bug as a wrong belief, not a broken thing. Code does exactly what it says. If the behavior is wrong, one of my assumptions about what the code says is wrong. My job is to find which assumption, not to guess at fixes. Start by writing down what you believe Before touching the debugger, I write three or four sentences: What I expected to happen What actually happened The smallest input that reproduces it What I think the code does at each step That last one is the money. It forces the wrong belief out of my head and onto the screen where I can attack it. Binary search the gap A bug lives somewhere between "input arrives" and "wrong output leaves." Don't read code top to bottom hoping to spot it. Cut the space in half. function processOrder(order) { const priced = applyPricing(order); // check here const taxed = applyTax(priced); // or here const saved = persist(taxed); // or here return saved; } Log the value after applyPricing. If it's right, the bug is downstream. If it's wrong, upstream. Two or three of these and you're staring at the culprit. This is the same idea as git bisect, just applied to a single function instead of a commit history. Change one thing at a time When I'm stuck, it's almost always because I changed three things at once and now I can't tell which one mattered. Fix one variable, rerun, observe. If nothing changed, revert it before trying the next idea. A dirty working tree full of half-fixes is a debugging trap. Trust the data over your memory I've wasted hours "remembering" that a function returns an array when it returns a Map. Print the type. Print the length. Print the keys. print(type(result), len(result), list(result)[:3]) That single line has ended more debugging sessions than any profiler I've used. Memory is unreliable; the runtime is not. Reproduce it small A bug that only shows up in your full app is a bug you don't understand yet. Strip it down. Delete code until the bug either disappears or stands alone in twenty lines. Nine times out of ten, the moment it stands alone, the cause is obvious. If you can't reproduce it on demand, you can't verify a fix. "It seems fine now" is not a fix. Read the error message. Actually read it. Not the top line. The whole stack trace. The line number. The file path. The caused by chain. Frameworks bury the useful part three levels down, but it's there. I've watched people (me) spend twenty minutes reasoning about a null pointer when the log said ECONNREFUSED on port 5432 the whole time. When you're truly stuck, explain it out loud Rubber duck debugging works, and the reason is simple: explaining forces you to state your assumptions in order. The wrong one usually falls out mid-sentence. Talk to a colleague, a toy, or a blank doc. The audience doesn't matter. Then write the test Once I've found the bug, I write a failing test that captures it before I fix it. Then I fix the code until the test passes. This does two things: it proves I understood the cause, and it stops the same bug from coming back. If I can't write a test that fails on the old code, I probably haven't found the real cause yet. The short version A bug is a wrong belief, not a broken machine Write your assumptions down, then attack them Binary search the gap, don't read everything Change one thing at a time Trust printed data over memory Shrink the repro until the cause is obvious Read the whole error, not the headline Explain it out loud when stuck Lock it in with a test None of this is clever. It's just refusing to guess. The mindset is the tool.