3 ms·
"The very best way to get better at debugging is to not put bugs there in the first place" Actually, I've come to the opposite conclusion recently. During col
by cellularmitosis 15y ago
"The very best way to get better at debugging is to not put bugs there in the first place"
Actually, I've come to the opposite conclusion recently.
During college, as well as for all of my personal projects, and during the early part of my career, I had the fortune of mostly working on projects for which I was the sole coder from start to finish.
As you say, when you're the only variable in the equation, you eliminate the need for strong debugging skills by following a set of best practices which tends to prevent creation of bugs in the first place.
And then I inherited my first seriously brain-damaged codebase. 16,000 lines of "what not to do". All of my favorite practices listed in the c2 wiki were completely ignored. Massive copy-paste coding. State BOOL's distributed throughout the app making it extremely fragile and tightly coupled. Thread safety? What's that? Hell, they couldn't even avoid giving methods and variables ambiguous names, even in the simplest of cases ("buttonClick". wtf? is that a command (e.g. clickButton) or an event (e.g. buttonClicked)?)
I was wholly unprepared for debugging this monstrosity. My first instinct was to rewrite the whole thing. In fact, a co-worker of mine had attempted exactly that before I was assigned to this beast, but introduced his own set of show-stopping bugs before being pulled off onto another project, ultimately wasting two weeks of work (his branch was abandoned) and souring the waters for any such attempt on my part.
For several months I forced myself to avoid the urge to rewrite, and just slogged through it until I finally started to understand what was going on.
I have to say, forcing myself to continue to chew on something sour when every instinct told me to spit it out really improved my ability to follow what was happening in a foreign codebase. Now, even when bughunting relatively sane codebases, I feel I'm more quickly able to zero in on the problem.
- wglb 15y agoI agree with what you are saying in the context of taking on another's program. In similar situations, I have also attempted to rewrite the body of code. Once it was a necessity, as the code was perhaps 50% wishful thinking and never worked. I have tried in other cases, unwisely, and failed. But when you are confronted with a pile of bad but working software, I have done what what you are saying here--dive in and understand what is happening.