Here's a step 0 for your debugging strategy: spend a few minutes thinking about what could account for the bug. Prior to its occurrence, you are thinking about what could go wrong, but now you are thinking about what did go wrong, which is a much less open-ended question.
I've had large success by treating the bug as a binary search problem as soon as I identify an initial state that's correct and a terminal state that's incorrect. It seems like a lot of work, but that's underestimating just how fast binary searches are.
Depends of course on the nature of the bug whether it's a good strategy.
A subcategory of the design flaw I find quite a lot is the case where the code works exactly as intended, it's just not having the desired effect because of some erroneous premise.
I was such a bad developer that I realized I had to automate the re-running of parts of the system to find the bugs.
Of course, the code I wrote to exercise the code I wrote had bugs, but usually I wouldn't make offsetting errors.
It didn't fix all the problems I made, but it helped. And it helped to have the humility when trying to fix code to realize I wouldn't get it the first time, so should automate replication
Unit/integration tests are anything but a buzzword. And my intentions were not to belittle, but to praise.
Some actions simply make so much sense to do, that any sensible person (unaware of the concept) will start doing them given enough practice, and in process they "reinvent" a common method.
Here's a step 0 for your debugging strategy: spend a few minutes thinking about what could account for the bug. Prior to its occurrence, you are thinking about what could go wrong, but now you are thinking about what did go wrong, which is a much less open-ended question.
I've had large success by treating the bug as a binary search problem as soon as I identify an initial state that's correct and a terminal state that's incorrect. It seems like a lot of work, but that's underestimating just how fast binary searches are.
Depends of course on the nature of the bug whether it's a good strategy.
There's also the Common Weakness Enumeration (CWE), a long-running taxonomy of software weaknesses (meaning types of bugs).
https://cwe.mitre.org/
A subcategory of the design flaw I find quite a lot is the case where the code works exactly as intended, it's just not having the desired effect because of some erroneous premise.
The Third-Party Bug
Is the party responsible for the bug bigger than you? If yes, it's your problem. If no, it's their problem.
John Carmack uses a debugger
I was such a bad developer that I realized I had to automate the re-running of parts of the system to find the bugs.
Of course, the code I wrote to exercise the code I wrote had bugs, but usually I wouldn't make offsetting errors.
It didn't fix all the problems I made, but it helped. And it helped to have the humility when trying to fix code to realize I wouldn't get it the first time, so should automate replication
> I had to automate the re-running of parts of the system to find the bugs
Congratz, you've independently invented integration tests.
I don't always test but adding a lil test after finding and fixing a bug so you don't end up there again a second time is a great practice
Congratz, you've invented regression tests.
Congrats, you've found someone who failed to invoke a buzzword that you know.
EDIT: But Acktshally `the code I wrote to exercise the code I wrote` is a description of "Unit Testing", not integration testing.
Unit/integration tests are anything but a buzzword. And my intentions were not to belittle, but to praise.
Some actions simply make so much sense to do, that any sensible person (unaware of the concept) will start doing them given enough practice, and in process they "reinvent" a common method.
As far as you knew that guy was aware what Unit Testing was since well before you were born. lol. I'm sure he appreciates all your nice compliments.
Good thing he has knights in shining armor like you to defend him from my nasty insults.
Good thing you can admit what you were doing.
Good thing you can understand sarcasm.
Yes because your sarcasm was truthful.
> And my intentions were not to belittle, but to praise.
With the stock eyeroll dismissal phrase.