Slashdot Mirror

I really enjoyed Dave Agans' Debugging Rules, a book that presents a general, solid debugging process. One of the best points is to first be sure you can reliably trigger the bug, so that once you think you've fixed it, you can then do what triggered it before and verify that it does not still occur.

Get the book: http://www.debuggingrules.com/. Full disclosure: I am the author. But it was IEEE Software Magazine that said this should be required reading for all technology students. And unlike most other tech books, this one's cheap, funny, and a quick read.

Not that anyone cares, but this book and site shows how to resolve problems. If your tech can follow that successfully, then they're ready for your companies particulars.

It is just 'OMG IE7 is the broken.' mind-speak of slashdot. It is just a troll. Move along...

Just someone wanting to fling poo. Just remember folks it is not the thing you fling its the fling.

IE7 is a tool. Use it dont use it the rest of us do not care if someone is 'leet' enough to use it or not. I see this every day on slashdot. It is most amusing to watch. I personally switched to firefox. But now that IE has tabs I 'might' switch back. But I am not even sure it is worth my time to contemplate.

People seem to forget that this is a browser. Not life support software. It needs to work 'good enough'. Both IE and firefox are 'good enough'. Could they be better? Hell yeah. Will they? Maybe. What bugs me about firefox? The random 'hangs' that happen. If firefox can not resolve a website it hangs for 30-60 seconds. IE blasts right back with 'dont know' firefox has some sort of retry in there it seems. It is annoying. Read the 'offical' it hangs/memory leak websites. Instead of 'hey there might be something wrong' they blame it on everything BUT themselves. Typical programmer mentality. How do I know it is typical? I work with it every day, I am one. I see my fellow programmers do it every day when they do not feel like fixing something. Hell I have used the 'its not my problem its XYZ' excuse many times myself. It walks talks and acts like a bug. But no one cares enough to fix it. They have convinced themselves it is something else. They have broken rule 3 of debugging 'quit thinking and LOOK'. http://www.debuggingrules.com/

Debugging by Dave Agans: universal, often neglected principles to avoid long debugging cycles. Illustrated with interesting war stories and amusing anecdotes. This is one you'll actually read all the way through. Called a classic by several reviewers, including IEEE SW and Dr. Dobbs.
It was reviewed on Slashdot http://books.slashdot.org/books/04/02/21/228241.sh tml, and is endorsed on the back cover by Rob Malda. (Disclaimer: I wrote it.)
You can get it on Amazon but they sold out this week, so for Christmas you'd have to go Barnes and Noble and pay a bit more.
Oh, and it's cheap ($15 on Amazon, $22 on B&N) but well worth the money.
See http://www.debuggingrules.com/ for info, samples, free poster, etc.

Speaking of something that no one has mentioned.

This poster and this site

Sometimes the most important tool is the one between your ears.

Speaking of something that no one has mentioned.

This poster and this site

Sometimes the most important tool is the one between your ears.

I always have one above my bench, but then again, I designed the poster and think it's both amusing and useful. Downloadable from http://www.debuggingrules.com/

These subjects are the essentials of any kind of engineering, albeit some with a slight bent toward software (UML, re-factoring). But even those subjects could be generalized.

When I wrote "Debugging" http://www.debuggingrules.com/ I was trying to avoid narrowing the focus to a particular language or platform, so it would be a "timeless" book. In fact, I had found the rules I used to be universal for both hardware and software, and then had some fun by generalizing across medicine, automotive, and home repair.

Many general books have been written on time management and business economics, but we could use some on architecture/design, problem analysis, and spec'ing.

Q: Why is this bug taking so long to find?
A: Because you don't know the first 9 things about debugging.

Q: Why don't I know these things?
A: Because you haven't read "Debugging" by Dave Agans.

A debugging analysis tool can help you follow one or two of the nine rules, but you have to follow them all.

Shameless plug, I wrote the book - but it has gotten great reviews. See the slashdot review at http://books.slashdot.org/article.pl?sid=04/02/21/ 228241&tid=156&tid=6

Get the cool rules poster at http://www.debuggingrules.com/

My favorite site when it comes to learning debugging, software or hardware.

You can read a sample chapter from the Debugging Rules book in PDF format by going here. (Requires the free Adobe reader.)

"Most technicians do it by instinct and years of experience. "

No need for years of, or some "guessmatic instinct"

Rules of thumb

Follow these and a lot of problems will fall by the wayside.

Shameless plug warning - Actually, plea for unbiased review ahead -- Given suggestions like "The Mythical Man-Month", if you want a quick, entertaining read on computer engineering, you could try "Debugging" by David Agans. That's me. The book could be a beach read but only for an afternoon at the beach; you'll finish it in a few hours. But it's funnier than Ayn Rand and Fred Brooks put together! It even comes with an endorsement on the cover by slashdot's own CmdrTaco, and there's a free, funny, downloadable poster at DebuggingRules. It got a great review in Dr. Dobb's Journal and EDN, but I'd love to see a slashdotter give a review -- I don't want to ask a friend to review it, friends are biased. Anyone want to step up?