Bugs show up, eat all your time, and gaslight you into thinking you are the problem. You’re not.
You just solved that problem a few commits ago, but now it’s harvest season again.
Here are some debugging hacks that worked for me during such times:
1. Stop blaming the code: examine your assumptions instead
Half the bugs you chase aren’t in your code. They’re in your head. You assume the API returns the right format. You assume the config is loading. You assume that “of course that condition can never be false.”
Pause. Write down 3 things you’re assuming. Then test if they’re true. Most bugs die here.
2. Use print statements whenever possible
Yes, logs are good. But sometimes what you need is a print statement that shows the raw, brutal truth.
Forget “elegant” logs. Instead, write: console.log('IT GOT HERE', value, otherValue);
If you can’t print in prod, simulate the state locally. Or inject temporary logging and roll it back after you're done.
If you're guessing, start printing.
3. Use the "check what changed" shortcut
The code worked yesterday. It doesn’t today.
What changed?
- A merge?
- A package update?
- Someone “just renamed” a field?
Use git diff. Use git blame. Use your team’s messages. Bugs appear when you think the change you just made is “harmless.”
4. Break things on purpose
Sometimes the fastest way to debug is to make the problem worse.
- What happens if you delete the whole function?
- What if you make the input obviously wrong?
- What if you hardcode a temporary value?
It tells you what part of the code is actually running and what’s just decoration.
5. Explain the bug to anyone, even a rubber duck
Explaining the bug to someone else, even to a rubber duck, will often reveal the solution to you.
The best way to do it is explain it in writing, like a message or a blog post. Halfway through, you’ll realize where you messed up.
If you're writing a message to your teammate, ask your teammate to refrain from responding until you finish typing. You’re not asking for their input, necessarily. You’re asking to have someone listen to you so you can think straight.
6. Error messages lie sometimes, but stack traces tell the truth
That error might say the issue is in fileA.js, line 134. But the real culprit is 10 steps back.
Start from the stack trace. Rebuild the call flow mentally. Use breakpoints or traces to walk the same path.
The truth is in the path, not the punchline.
7. Reproduction kills bugs dead
If you can’t reproduce it, you can’t fix it. End of story.
- Try different environments.
- Use test accounts.
- Recreate the exact state the user was in when the bug showed up.
Once you have reproduced it at least once, the bug is already on its way to the graveyard.
8. Logs make good maps and bad novels
Don’t drown in logs. Learn to:
- Filter by correlation IDs.
- grep for error keywords.
- Log timestamps to detect timing bugs.
Better yet, set alerts on error patterns and high-latency paths. The log is not your diary. It’s your surveillance system.
9. Check the components your code interacts with
Is it your bug? Maybe.
But first consider:
- Is the upstream API acting weird?
- Is the database server caching stale data?
- Is the content delivery system serving outdated JavaScript?
Debugging is cross-boundary now. Isolate systems. Confirm assumptions. Don’t play alone, you can share the load.
10. Take rest breaks like a professional
That bug you can’t crack after you've spent three hours on it? You are likely to squash it in 10 minutes after lunch.
Walk away. Rant to a friend. Stare into the void.
Debugging isn’t just thinking. It’s re-thinking, and your brain needs room to do that.
Bonus: Your boss isn’t impressed when you say “I fixed it.”
What they really want to know:
- What broke
- Why it broke
- How we’ll prevent it next time
Write postmortems. Add comments. Create a test case. That’s debugging like a boss.
Still stuck? Make your own hacks.
These 10 tips aren’t a checklist: they are a starter kit. If you’ve been debugging long enough, you’ve probably invented a few of your own rituals:
- Copying state to a playground
- Spinning up a fresh dev environment
- Asking your future self in code comments what on earth this logic was meant to do
Whatever works, write it down. Share it. Teach it. That’s how you get better at debugging not just faster, but smarter.
To wrap up
- Don’t trust your assumptions, question them.
- Logs are your sidekick, not your saviour.
- Break stuff, observe, and simplify.
- If you're stuck, walk away.
For more information
- Finding bugs faster: A smarter way to debug integration failures, Arun Vishwanathan
- Testing AI-coded applications: Practical tips for software testers, Rafaela Azevedo
- I think, therefore I test: the importance of thinking for testers, Ady Stokes
- Fixing a bug vs fixing a feature, Hanisha Arora
What do YOU think?
Got comments or thoughts? Share them in the comments box below. If you like, use the ideas below as starting points for reflection and discussion.
Questions to discuss
- What’s the single most useful debugging trick you’ve learned that isn’t on this list?
- Have you ever spent hours chasing a bug, only to realize it came from a false assumption? How did you catch it?
- How do you decide when to step away and take a break or when to keep going on finding a solution?
- What’s the best “rubber duck moment” you’ve ever had: explaining a bug made the solution suddenly obvious?
Actions to take
- Try rubber-ducking: Explain a bug (real or imaginary) in writing to yourself, or talk it through to a friend who isn’t technical. Notice at what point clarity starts to emerge.
- Break something on purpose: Pick a working function and break it on purpose. Change inputs, hardcode incorrect values, or delete parts of it. Observe how your system fails, and what that teaches you about where to look when real bugs appear.
- Measure your own slowdown: If you want data, start small. Track how long it takes between finding a bug and actually closing it. Then check how much of that time is spent waiting, reworking, or context switching. You’ll probably find that “testing slows you down” wasn’t the real slowdown at all. You can also do the same for your team to measure your team’s slowdown.
- Bring your leads into it: Set up a short chat or team session to share your debugging tricks - what’s working, what’s not, where time gets lost. Aligning language and priorities can turn debugging from a background chore into fast-track fixes.
