Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Debugging: Indispensable rules for finding even the most elusive problems (2004)

dwheeler.com

Post reply on HN
Print view View original

231–238 of 238 posts

Re: Debugging: Indispensable rules for finding even the most elusive problems (2004)

#231

Post by jsrcout »

urbandw311er wrote: post #7

Rule #10 - it’s probably DNS

I worked at place in the late 90s where that was true, at least for anything Internet related. We were doing (oh so primitive by today's standards...) Web development and it happened so many times. I'd call downstairs and they'd swear DNS was fine, and then 20 minutes to half an hour later, it would all be mysteriously working again. But only if we called down heh heh.

On an unrelated note, one of the folks down there explained the DNS setup once and it was like something out of a Stephen King novel. They'd even been told by a recognized industry expert (whose name I sadly can't remember any more) that what they needed to do was impossible, but they still did it. Somehow.

They really were great folks, they just had that one quirk but after a while I could just chuckle about it.

Re: Debugging: Indispensable rules for finding even the most elusive problems (2004)

#232

Post by omkar-foss »

burrish wrote: post #92
omkar-foss wrote: post #81

For folks who love to read books, here's an excerpt from the Debugging book's accompanying website ( https://debuggingrules.com/ ): "Dave was asked as the author of Debugging to create a list of 5 books he would recommend to fans, and came up with this. https://shepherd.com/best-books/to-give-engineers-new-perspe... "

thanks for the link

Most welcome :)

Re: Debugging: Indispensable rules for finding even the most elusive problems (2004)

#233

Post by earnestinger »

feoren wrote: post #224
earnestinger wrote: post #184

Earlier quoted context omitted.

> if the manual of a library you're using is 700 pages, you're probably using the wrong library. Statement bordering on papyrophobia. (Seems that is a real phobia)

More like fear of needless complexity and over-broad scope, which is actually rampant in library design.

700 page manual can be produced in several ways.

- Scope of the library is massive

- very peculiar way of writing, with lot of impressively unnecessary description of minute detail, that the reader starts counting not only sheep but also breaths until the ultimate end before finishing a sentence. (I.e. Unnecessarily verbose)

- very extensive docs describing things from various angles including references, topic based how tos and such.

(I agree that the last one is the least likely, but there is always hope)

Re: Debugging: Indispensable rules for finding even the most elusive problems (2004)

#234

Post by hughdbrown »

yakshaving_jgt wrote: post #193
hughdbrown wrote: post #192

Earlier quoted context omitted.

> The quickest solution, assuming learning from the problem isn't the priority, might be to replace the entire chain of lights without testing any of them. So as a metaphor for software debugging, this is "throw away the code, buy a working solution from somewhere else." It may be a way to run a business, but it does not explain how to debug software.

I’m not sure it implies buying from elsewhere. I understood it to mean make a new one, rather than try to repair the broken one.

Let me reformulate then.

Take the wikipedia article on debugging[1]. The first sentence identifies what debugging is: "In engineering, debugging is the process of finding the root cause, workarounds and possible fixes for bugs." I'd say this is implicitly about taking broken code and finding the error in it.

The second paragraph is clearer on this point:

> For software, debugging tactics can involve interactive debugging, control flow analysis, log file analysis, monitoring at the application or system level, memory dumps, and profiling. Many programming languages and software development tools also offer programs to aid in debugging, known as debuggers.

All of the debugging tactics listed are about working with an existing broken piece of code.

Further sections on debugging tools, debugging process ("debugging process normally begins with identifying the steps to reproduce the problem"), and techniques are also about working with broken code.

Completely rewriting the code is certainly a way to resume progress on a software project, but as the practice of debugging is imagined, rewriting is not debugging.

[1] https://en.wikipedia.org/wiki/Debugging

Re: Debugging: Indispensable rules for finding even the most elusive problems (2004)

#235

Post by waynecochran »

hugograffiti wrote: post #213
waynecochran wrote: post #15

I also think it is worthwhile stepping thru working code with a debugger. The actual control flow reveals what is actually happening and will tell you how to improve the code. It is also a great way to demystify how other's code runs.

I agree and have found using a time travel debugger very useful because you can go backwards and forwards to figure out exactly what the code is doing. I made a video of me using our debugger to compare two recordings - one where the program worked and one where a very intermittent bug occurred. This was in code I was completely unfamiliar with so would have been hard for me to figure out without this. The video is p…

To go backwards, don't you have to save the previous states of the machine. This always seemed long a strong limitation.

Re: Debugging: Indispensable rules for finding even the most elusive problems (2004)

#237

Post by ianmcgowan »

PaulHoule wrote: post #223
tetha wrote: post #118

Earlier quoted context omitted.

A weird, yet effective recommendation from someone at my last job: If it's a destructive or dangerous action in prod, touch both your elbows first. This forces ou to take the hands away from the keyboard, stop any possible auto-pilot and look what you're doing.

Reminds me of https://en.wikipedia.org/wiki/Pointing_and_calling

Yes! I do this when doing anything destructive ("rm -rf dir", "drop db", etc.) - i just stop and say out loud what environment I'm in, what the command I'm running is going to do and why I am doing it. This is in a remote-work situation, in an office I would have someone come double check the really destructive things before hitting enter..

Re: Debugging: Indispensable rules for finding even the most elusive problems (2004)

#238

Post by plagiarist »

snowfarthing wrote: post #145
michalsustr wrote: post #116

Earlier quoted context omitted.

This is why we use squash like here https://docs.gitlab.com/ee/user/project/merge_requests/squas...

As someone who doesn't like to see history lost via "rebase" and "squashing" branches, I have had to think through some of these things, since my personal preferences are often trampled on by company policy. I have only been in one place where "rebase" is used regularly, and now that I'm a little more familiar with it, I don't mind using it to bring in changes from a parent branch into a working branch, if the workin…

I think if you find the notes and trials as helpful for reasoning, likely other people might enjoy them as documentation in the final version?
Post reply on HN