Photo by Timothy Dykes on Unsplash
Acknowledging the usual Culprit first
Before you blame the compiler, the framework or the new junior on the team, check the boring things. Most bugs I’ve chased for hours turned out to be something I could have spotted in five minutes if I had started at the bottom of the stack instead of the top.
1. Hardware Debugging
When your device overheats, it’s a sign that something’s amiss—unless you’re running a program that justifies the high temperature. If you’ve opted for a budget computer, make sure it meets your needs. For instance, a 2010 laptop might struggle with 2022 AAA games, leading to crashes that look like software bugs but are really thermal throttling. Check your fans, your RAM usage and your disk space before you open the debugger.
2. Read the error message. Properly.
It sounds obvious, but most of us skim the first line and jump straight to Google. Read the whole stack trace, top to bottom. The line that matters is usually the first one that mentions your code, not the framework’s.
3. Reproduce it reliably
A bug you can’t reproduce is a bug you can’t confirm you fixed. Write down the exact steps, inputs and environment. If it only happens “sometimes”, that in itself is a clue: think timing, caching, concurrency or state left over from a previous run.
4. Change one thing at a time
When you change five things and the bug disappears, you’ve learnt nothing, and you may have introduced two new ones. Make one change, test, then move on.
5. Divide and conquer
Cut the problem in half. Comment out half the code, disable half the plugins, or use git bisect to find the commit that broke things. Halving the search space every step gets you to the culprit surprisingly quickly.
6. Rubber duck it
Explain the problem out loud, line by line, to a colleague, a rubber duck or the cat. Somewhere around the third sentence of “so this should obviously work because…” you’ll hear yourself say the wrong assumption.
7. Check your assumptions
Is the config file you’re editing the one that’s actually being loaded? Is the server running the code you just deployed, or a cached copy? Print it, log it, prove it. Assumptions are where bugs like to hide.
8. Log with intent
Scattering print("here") everywhere works in a pinch, but good logging tells you what happened, where and with which values. Add context to your log lines and you’ll thank yourself at 2am in production.
9. Learn your debugger
Breakpoints, watch expressions and stepping through code beat guesswork every time. Spend an afternoon learning the debugger in your IDE of choice; it pays for itself on the first nasty bug.
10. Look at what changed
If it worked yesterday and not today, something changed: code, dependencies, data, the environment, or the operating system. Check the git log, the lock file and the deployment history before diving into the code itself.
11. Take a break
Walk away, make a cup of coffee (or tea), and come back. Your brain keeps working on the problem in the background, and fresh eyes spot what tired ones skip over. Some of my best fixes happened in the shower, not at the keyboard.
In short
Start with the usual culprit, reproduce the problem, change one thing at a time and question everything you “know” to be true. Debugging is less about genius and more about patience and process.