I'd say the biggest issue I run into tracking down bugs is that I focus on the specific areas where I've made changes recently. Almost always, the problem involves taking several steps back- thinking about what dependencies are involved, whether I've changed git branches recently, checking a wider range of error logs and even whether any system services are halted. See if another machine or context produces the same error.
Frankly, I can never get there in one session, or if I do I only end up feeling exhausted. Taking a break, a long lunch, doing something novel generally helps. Of course that's not always an option, but changing to a different part of the project, or a different project for a while can give you that cognitive 'reset'. To this day I've never found a bug which wasn't easily soluble once it left alone for a week.
The other side of this is how do you actually break apart your code. You know its broken, but the bug seems to squirm as you segment off areas of code, move to different lines (if it's moving to preceding lines it's almost always a syntax error), and generally show resistance. The old school approach would be to make an isolated test case of just a few lines at a time, adding in more until you see the issue; or break up your code into modules and test each one. If you're going down this road, make sure you actually log the inputs and outputs of data through a function or module- often the data type or structure is doing something you didn't expect or had forgotten about.
Given that sometimes your code can end up like a woven rug (hard to pull apart), I sometimes just rewrite a section of code entirely instead of trying to trace a problem through it. Generally speaking, if you wrote it once you can write it again much faster, and even if your new code isn't great, you can learn from comparing your two attempts and HOW they fail. Hopefully they don't fail.
The best way I've found to fix a problem like that is to remove half of the relevant code again and again until you find a section where taking it away fixes the bug. After you've found the broken section, keep splitting it until the problem goes away again. Split that section etc until you find the exact location of the bug. Once you've found the exact location, slowly put things back together.
Some of those bugs for me have been caused by an invisible whitespace character or Internet Explorer's bad rendering rules.
Sure, I sometimes found bug at let's say 14.00h and the fix usually comes at 16:55. And it's need to be solved that day, so I am going to shut up now :(
I will tell you more, once I stacked on the bug for a week and only at the end of the week I found a problem. I literally checked everything, enabled maximum log level and analyzed 50k lines log file. At the end the mistake was in 1 line.
Sometimes solving a problem is like driving a car: you find something in front of you blocking you and you feel stuck.
In moments like these, you can spend a lot of time sitting and waiting, ready to move faster just waiting for the blockage to clear up. But instead, what if you changed lanes on the road? Suddenly that roadblock that was in front of you slowing you down isn't in front of you any more.
When I find myself at a serious road block (like an all-day bug I'm stuck on) I try to force myself to switch tasks, and change the perspective from which I'm trying to solve the problem. Because of this, even if a bug took more than one day to solve it, I'm not sitting there for a whole day feeling like I've made no progress.
Usually though, I'll be doing entirely different - maybe not even working, maybe I'll be in the shower or shopping or walking down the street - but before too long usually the solution to my roadblock comes to me and I'm able to go back and solve it!
Lol, it would be good to only have bugs that take one day.
Nathaniel Ng
Yes. However, the reality is that sometimes you don't actually know how many bugs there are in the code--a bug may not be just one line of code, it might be a lot more.
Or the bug might be due to a incorrect assumption that was made, and if that assumption turns out to be wrong, multiple chunks of new code need to be written.