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

191–200 of 238 posts

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

#191

Post by r-bryan »

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 once worked with a company that provided IM services to hyper competitive, testosterone poisoned options traders. On the first fine trading day of a January new year, our IM provider rolled out an incompatible "upgrade" to some DLL that we (our software, hence our customers) relied on, that broke our service. Our customers, ahem, let their displeasure be known.

Another developer and I were tasked with fixing it. The Customer Service manager (although one of the most conniving political-destructive assholes I have ever not-quite worked with), actually carried a crap umbrella. Instead of constantly flaming us with how many millions of dollars our outage was costing every minute, he held up that umbrella and diverted the crap. His forbearance let us focus. He discretely approached every 20 minutes, toes not quite into entering office, calmly inquiring how it was going. In just over an hour (between his visits 3 and 4), Nate and I had the diagnosis, the fix, and had rolled it out to production, to the relief of pension funds worldwide.

As much as I dislike the memory of that manager to this day, I praise his wisdom every chance I get.

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

#192

Post by hughdbrown »

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…

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

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

#193

Post by yakshaving_jgt »

hughdbrown wrote: post #192
randerson wrote: post #182

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

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

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

#196

Post by r-bryan »

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…

Well dang, we are not restricted to git as the only place we can put historical metadata. You know, discursive comments, for starters?

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

#199

Post by kmoser »

Zolomon wrote: post #89

I have been bitten more than once thinking that my initial assumption was correct, diving deeper and deeper - only to realize I had to ascend and look outside of the rabbit hole to find the actual issue. > Assumption is the mother of all screwups.

When playing Captain Obvious (i.e. the human rubber duck) with other devs, every time they state something to be true my response is, "prove it!" It's amazing how quickly you find bugs when somebody else is making you question your assumptions.

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

#200

Post by scubbo »

ianmcgowan wrote: post #87
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.

There's a story in the book - on nuclear submarines there's a brass bar in front of all the dials and knobs, and the engineers are trained to "grab the bar" when something goes wrong rather than jumping right to twiddling knobs to see what happens.

Thank you for explaining that phrase! I couldn't find it with a quick Google.
Post reply on HN