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

211–220 of 238 posts

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

#211

Post by manhnt »

> Make it fail: Do it again, start at the beginning, stimulate the failure, don't simulate the failure, find the uncontrolled condition that makes it intermittent, record everything and find the signature of intermittent bugs

Unfortunately, I found many times this is actually the most difficult step. I've lost count of how many times our QA reported an intermittent bug in their env, only to never be able to reproduce it again in the lab. Until it hits 1 or 2 customer in the field, but then when we try to take a look at customer's env, it's gone and we don't know when it could come back again.

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

#213

Post by hugograffiti »

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 pretty rubbish to be honest - I could never work in sales - but if you skip the first few minutes it might give you a flavour of what you can do. (I basically started at the end - where it failed - and worked backwards comparing the good and bad recordings) https://www.youtube.com/watch?v=GyKrDvQ2DdI

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

#214

Post by codr7 »

gregthelaw wrote: post #166
ajross wrote: post #83

Earlier quoted context omitted.

Not to complain about bisect, which is great. But IMHO it's really important to distinguish the philosophy and mindspace aspect to this book (the "rules") from the practical advice ("tools"). Someone who thinks about a problem via "which tool do I want" (c.f. "git bisect helps a lot"[1]) is going to be at a huge disadvantage to someone else coming at the same decisions via "didn't this used to work?"[2] The world is…

I've spent the past two decades working on a time travel debugger so obviously I'm massively biassed, but IMO most programmers are not nearly as proficient in the available debug tooling as they should be. Consider how long it takes to pick up a tool so that you at least have a vague understanding of what it can do, and compare to how much time a programmer spends debugging. Too many just spend hour after hour hammer…

Different mindsets, I find many problems easier to reason about from traces.

It's very rare for me to use debuggers.

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

#215

Post by codr7 »

netcraft wrote: post #127
qwertox wrote: post #14

Make sure you're editing the correct file on the correct machine.

the biggest thing I've always told myself and anyone ive taught: make sure youre running the code you think youre running.

Baby steps, if the foundation is shaky no amount of reasoning on top is going to help.

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

#216

Post by dalton_zk »

dalton_zk wrote: post #197

First time hearing about these 9 rules, but I learning most of them by experience with many years resolving or trying to resolved bugs. Only thing that I dont agree is the book cost US$ 4.291,04 on Amazon

btw the hardcover its this price

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

#217

Post by roxyrox »

GuB-42 wrote: post #48

Rule 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.

agreed. it’s practically a prerequisite for everything else in the book. Staying calm and thinking clearly is foundational

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

#219

Post by badmintonbaseba »

michalsustr wrote: post #116
forrestthewoods wrote: post #93

Earlier quoted context omitted.

> 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 You’re spot on. However it’s clearly a missing feature that Git/Mercurial can’t tag diffs a…

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

git bisect supports --first-parent, no need to squash if you just merge.

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

#220

Post by badmintonbaseba »

gregthelaw wrote: post #167
forrestthewoods wrote: post #135

Earlier quoted context omitted.

I explicitly don’t want squash. The commits are still worth keeping separate. There’s lots of distinct pieces of work. But sometimes you break something and fix it later. Or you add something new but support different environments/platforms later.

But if you don't squash, doesn't this render git bisect almost useless? I think every commit that gets merged to main should be an atomic believed-to-work thing. Not only does this make bisect way more effective, but it's a much better narrative for others to read. You should write code to be as readable by others as possible, and your git history likewise.

git bisect --first-parent
Post reply on HN