Make sure you're editing the correct file on the correct machine.
That's why you make it break differently first. To see your changes have any effect.
Debugging: Indispensable rules for finding even the most elusive problems (2004)
51–60 of 238 posts
Re: Debugging: Indispensable rules for finding even the most elusive problems (2004)
#52I would almost change 4 into "Binary search". Wheeler gets close to it by suggesting to locate which side of the bug you're on, but often I find myself doing this recursively until I locate it.
Yeah people say use git bisect but that's another dimension (which change introduced the bug).
Bisecting is just as useful when searching for the layer of application which has the bug (including external libraries, OS, hardware, etc.) or data ranges that trigger the bug. There's just no handy tools like git bisect for that. So this amounts to writing down what you tested and removing the possibilities that you excluded with each test.
Re: Debugging: Indispensable rules for finding even the most elusive problems (2004)
#53Re: Debugging: Indispensable rules for finding even the most elusive problems (2004)
#54Personally, I’d start with divide and conquer. If you’re working on a relevant code base chances are that you can’t learn all the API spec and documentation because it’s just too much.
Also: Fix every bug twice: Both the implementation and the “call site” — if at all possible
Ye ol’ “belt and suspenders” approach?
Re: Debugging: Indispensable rules for finding even the most elusive problems (2004)
#55Re: Debugging: Indispensable rules for finding even the most elusive problems (2004)
#56Rule 0: Don't panic Really, that's important. You need to think clearly, deadlines and angry customers are a distraction. That's also when having a good manager who can trust you is important, his job is to shield you from all that so that you can devote all of your attention to solving the problem.
Slow is smooth and smooth is fast. If you don't have time to do it right, what makes you think there is time to do it twice?
Re: Debugging: Indispensable rules for finding even the most elusive problems (2004)
#57For #4 (divide and conquer), I've found `git bisect` helps a lot. If you have a known good commit and one of dozens or hundreds of commits after that is bad, this can help you identify the bad commit / code in a few steps. Here's a walk through on using it: https://nickjanetakis.com/blog/using-git-bisect-to-help-find... I jumped into a pretty big unknown code base in a live consulting call and we found the problem pr…
"git bisect" is why I maintain the discipline that all commits to the "real" branch, however you define that term, should all individually build and pass all (known-at-the-time) tests and generally be deployable in the sense that they would "work" to the best of your knowledge, even if you do not actually want to deploy that literal release. I use this as my #1 principle, above "I should be able to see every keystroke ever written" or "I want every last 'Fixes.' commit" that is sometimes advocated for here, because those principles make bisect useless.
The thing is, I don't even bisect that often... the discipline necessary to maintain that in your source code heavily overlaps with the disciplines to prevent code regression and bugs in the first place, but when I do finally use it, it can pay for itself in literally one shot once a year, because we get bisect out for the biggest, most mysterious bugs, the ones that I know from experience can involve devs staring at code for potentially weeks, and while I'm yet to have a bisect that points at a one-line commit, I've definitely had it hand us multiple-day's-worth of clue in one shot.
If I was maintaining that discipline just for bisect we might quibble with the cost/benefits, but since there's a lot of other reasons to maintain that discipline anyhow, it's a big win for those sorts of disciplines.
Re: Debugging: Indispensable rules for finding even the most elusive problems (2004)
#58Very good online course on debugging: Software Debugging on Udacity by Andreas Zeller https://www.udacity.com/course/debugging--cs259
Udacity is owned by Accenture? That is...Surprising.
Re: Debugging: Indispensable rules for finding even the most elusive problems (2004)
#59Make sure you're editing the correct file on the correct machine.
Yep, this is a variation of "check the plug" I find myself doing this all the time now I will temporarily add a line to cause a fatal error, to check that it's the right file (and, depending on the situation, also the right line)
I'm glad I'm not the only one doing this after I wasted too much time trying to figure out why my docker build was not reflecting the changes ... never again..
Re: Debugging: Indispensable rules for finding even the most elusive problems (2004)
#60For #4 (divide and conquer), I've found `git bisect` helps a lot. If you have a known good commit and one of dozens or hundreds of commits after that is bad, this can help you identify the bad commit / code in a few steps. Here's a walk through on using it: https://nickjanetakis.com/blog/using-git-bisect-to-help-find... I jumped into a pretty big unknown code base in a live consulting call and we found the problem pr…
git bisect is an absolute power feature everybody should be aware of. I use it maybe once or twice a year at most but it's the difference between fixing a bug in an hour vs spending days or weeks spinning your wheels