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

201–210 of 238 posts

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

#201

Post by 101011 »

jwpapi wrote: post #121

I’m not sure that doesn’t sit well with me. Rule 1 should be: Reproduce with most minimal setup. 99% you’ll already have found the bug. 1% for me was a font that couldn’t do a combination of letters in a row. life ft, just didn’t work and thats why it made mistakes in the PDF. No way I could’ve ever known that if I wouldn’t have reproduced it down to the letter. Just split code in half till you find what’s the exact…

Rule 4 is divide and conquer, which is the 'splitting code in half' you reference.

I'd argue that you can't effectively split something in half unless you first understand the system.

The book itself really is wonderful - the author is quite approachable and anything but dogmatic.

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

#202

Post by bch »

gregthelaw wrote: post #159

I love the "if you didn't fix it, it ain't fixed". It's too easy to convince yourself something is fixed when you haven't fully root-caused it. If you don't understand exactly how the thing your seeing manifested, papering over the cracks will only cause more pain later on. As someone who has been working on a debugging tool ( https://undo.io ) for close to two decades now, I totally agree that it's just weird how li…

> If you didn't fix it, it ain't fixed

AKA: “Problems that go away by themselves come back by themselves.”

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

#203

Post by saghm »

dazzawazza wrote: post #76
adamc wrote: post #65

Earlier quoted context omitted.

I had a boss who used to say that her job was to be a crap umbrella, so that the engineers under her could focus on their actual jobs.

Ideally it's crap umbrellas all the way down. Everyone should be shielding everyone below them from the crap slithering its way down.

Agreed. Even as a relatively junior engineer at my first job, I realized that a certain amount of the job was not worth exposing interns to (like excessive amounts of Jira ticket wrangling) because it would take parts of their already limited time away from doing things that would benefit them far more. Unless there's quite literally no one "below" you, there's probably _something_ you can do to stop shit from flowing down past you.

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

#204

Post by eru »

randerson wrote: post #182
hughdbrown wrote: post #141

In my experience, the most pernicious temptation is to take the buggy, non-working code you have now and to try to modify it with "fixes" until the code works. In my experience, you often cannot get broken code to become working code because there are too many possible changes to make. In my view, it is much easier to break working code than it is to fix broken code. Suppose you have a complete chain of N Christmas l…

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. I've been part of some elusive production issues where eventually 1-2 team members attempted a rewrite of the offending routine while everyone else debugged it, and the rewrite "won" and shipped to production before we found the bug. Heresy I know. In at least one c…

Depending on how your routine looks like, you could run both on a given input, and see when / where they differ.

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

#205

Post by FearNotDaniel »

airblade wrote: post #90
adamc wrote: post #65

Earlier quoted context omitted.

I had a boss who used to say that her job was to be a crap umbrella, so that the engineers under her could focus on their actual jobs.

At first I thought you meant an umbrella that doesn't work very well.

Ah, the unintentional ambiguity of language, the reason there are so many lawyers in the world and why they are so expensive. The GP's phrasing is not incorrect but your comment made me realize: I only parsed it correctly the first time because I've heard managers use similar phrases so I recognized the metaphor immediately. But for the sake of reducing miscommunication, which sadly tends to trigger so many conflicts, I could offer a couple of disambiguatory alternatives:

- "her job was to be a crap-umbrella": hyphenate into a compound noun, implies "an umbrella of/for crap" to clarify the intended meaning

- "her job was to be a crappy umbrella": make the adjective explicit if the intention was instead to describe an umbrella that doesn't work well

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

#206

Post by lelanthran »

gregthelaw wrote: post #168
soco wrote: post #21

Earlier quoted context omitted.

What do you do with the years old bug fixes? How fast can one run the CI after a long while of accumulating tests? Do they still make sense to be kept in the long run?

I would say yes, your CI should accumulate all of those regression tests. Where I work we now have many, many thousands of regression test cases. There's a subset to be run prior to merge which runs in reasonable time, but the full CI just cycles through. For this to work all the regression tests must be fast, and 100% reliable. It's worth it though. If the mistake was made once, unless there's a regression test to c…

> For this to work all the regression tests must be fast,

Doesn't matter how fast it is, if you're continually adding tests for every single line of code introduced eventually it will get so slow you will want to prune away old tests.

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

#207

Post by JetSetIlly »

Izkata wrote: post #114
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…

If there's a way to identify those incomplete commits, git bisect does support "skip" - a commit that's neither good nor bad, just ignored.

Can we use git trailers for this? Something like "commit: incomplete" in the commit message.

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

#208

Post by louthy »

adamc wrote: post #65
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.

I had a boss who used to say that her job was to be a crap umbrella, so that the engineers under her could focus on their actual jobs.

I always say this too. But the real trick is knowing what to let thru. You can’t just shield your team from everything going on in the organisation. You’re all a part of the organisation and should know enough to have an opinion.

A better analogy is you’re there to turn down the noise. The team hears what they need to hear and no more.

Equally, the job of a good manager is to help escalate team concerns. But just as there’s a filter stopping the shit flowing down, you have to know what to flow up too.

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

#209

Post by nextlevelwizard »

sitkack wrote: post #152

If folks want to instill this mindset in their kids, themselves or others I would recommend at least The Martian by Andy Weir https://en.wikipedia.org/wiki/The_Martian_(Weir_novel) https://en.wikipedia.org/wiki/Zen_and_the_Art_of_Motorcycle_... https://en.wikipedia.org/wiki/The_Three-Body_Problem_(novel) To Engineer Is Human - The Role of Failure in Successful Design By Henry Petroski https://pressbooks.bccampus.ca/e…

What part of Three Body Problem has anything to do with debugging or troubleshooting or any form of planning?

Things just sort of happen with wild leaps of logic. The book is actually a fantasy book with thinnest layer of science babble on top.

Post reply on HN