How to Get Unstuck When You've Been Debugging for Hours

Every developer knows the feeling: you’ve been staring at the same bug for two hours, you’re convinced the code is wrong, and then you discover it was a typo. Good debugging skills aren’t just about being smart — they’re about having a systematic approach that works even when you’re frustrated.

Read the Entire Error Message

The most common debugging mistake is reading the first line of an error and immediately Googling it. Read the whole thing first.

Error messages contain:

• What went wrong (the error type)
• Where it went wrong (file path and line number)
• The stack trace (what sequence of calls led there)

The line number tells you exactly where to look. The stack trace tells you how you got there. Read both before doing anything else.

Isolate the Problem

If you don’t know where the bug is, make it smaller:

# If this function is broken, test it in isolation
def calculate_total(items):
    return sum(item["price"] for item in items)

# Test with minimal input
print(calculate_total([{"price": 10}]))  # Does this work?
print(calculate_total([]))               # What about empty?

Binary search your own code. Comment out half of it. Does the bug still happen? If yes, it’s in the remaining half. Repeat.

Check Your Assumptions

Most bugs live in the gap between what you think the code is doing and what it’s actually doing. Print (or log) intermediate values:

def process_order(order):
    print(f"DEBUG: order = {order}")  # What does this actually contain?
    total = order["amount"] * order["quantity"]
    print(f"DEBUG: total = {total}")
    return total

Don’t assume. Verify.

The Rubber Duck Method

Explain your code out loud to an imaginary (or real) rubber duck. Describe what it does, line by line. In the process of explaining, you’ll often hear yourself say “…and then it does… wait, that’s wrong.”

This works because articulating a problem forces you to think about it differently. The act of explaining surfaces assumptions you didn’t know you were making.

When to Ask for Help

Spend 30–45 minutes genuinely trying to solve it yourself. Then ask for help — but ask well. Share: what you’re trying to do, what you’ve already tried, and the exact error message. “It doesn’t work” is not a question. “I’m getting TypeError on line 42 after trying X and Y” is.

Conclusion

Good debugging skills are systematic, not magical. Read the full error, isolate the problem, check your assumptions, and explain it out loud. The developer who debugs well isn’t smarter — they’re more methodical.

Read next: JavaScript Error Handling: try, catch, and finally

External resource: How to Debug Like a Pro — Julia Evans