标签: david agans

The usual subjects of a book review are new releases. I will not be doing that, though as one of these days I want to review De Architectura by Marcus Vitruvius Pollio . Published around 25 BC it's possibly the oldest book about engineering. My Latin is pretty rusty but thankfully it's available in English from Project Gutenberg . Debugging, by David Agans , is a bit more recent, having been published in 2002 (reissued 2006). In it, he extols his nine rules of troubleshooting anything, though the focus is really on hardware and software. The rules are: - Understand the System - Make it fail - Quit thinking and look - Divide and conquer - Change one thing a time - Keep an audit trail - Check the plug - Get a fresh view - If you didn't fix it, it ain't fixed Dave devotes a chapter to each rule, adding a couple of bonus sections at the end, including a very helpful "View from the help desk." Diagnosing problems over the phone is especially challenging. The book is well-written, folksy, and a very quick read. It's packed – packed – with war stories, most of which do a great job of illustrating a point. Mostly I found myself nodding in agreement with his thoughts. However, he advocates reading the manual/databooks from cover to cover when looking for problems. That's great advice... but given today's 500 page datasheets and the deadline's screaming demands it's impractical in many cases. Geez, the OMAP datasheets are around 5000 pages each. He also believes in "knowing your tools." Great advice. As an ex-tool vendor I was always frustrated by so many customers who mastered 5% of the product's capabilities, when other features would be so helpful. Alas, that problem probably ties into the 500 page datasheet/screaming deadline challenge. But so many tools offer so much capability that it makes sense to learn more than the minimum needed to set a breakpoint or to scope a signal. He asks: "Did you fix it or did you get lucky?" And then says: "It never goes away by itself." Absolutely. A problem that mysteriously disappears inevitably mysteriously reappears, usually at the worst possible time. Though old the book remains very topical, with just a tiny bit of dated material (like advice to be wary of in-circuit emulators, which are far less common now than of yore). Reading this brought back many memories. His aphorisms, like "use a rifle, not a shotgun" were driven into us young engineers long ago and are still valid. Another oldie that's a favorite: "The shortest pencil is longer than the longest memory" (i.e., take notes). So anyone with experience will say "sure, I know all this stuff – why read the book?" The answer is that we may know it all, but it's too-often disorganized knowledge not used with discipline. Just as a tent revival meeting doesn't teach anyone anything they don't know, the book takes the known and organizes that knowledge, driving the message in deeply. For newbies the book is even more important. Every new grad should read this. It's interesting and fun. Recommended.

Most book reviewers usually just discuss new releases. I am not one of those, though as one of these days I want to review De Architectura by Marcus Vitruvius Pollio . Published around 25 BC it's possibly the oldest book about engineering. My Latin is pretty rusty but thankfully it's available in English from Project Gutenberg . Debugging, by David Agans , is a bit more recent, having been published in 2002 (reissued 2006). In it, he extols his nine rules of troubleshooting anything, though the focus is really on hardware and software. The rules are: - Understand the System - Make it fail - Quit thinking and look - Divide and conquer - Change one thing a time - Keep an audit trail - Check the plug - Get a fresh view - If you didn't fix it, it ain't fixed Dave devotes a chapter to each rule, adding a couple of bonus sections at the end, including a very helpful "View from the help desk." Diagnosing problems over the phone is especially challenging. The book is well-written, folksy, and a very quick read. It's packed – packed – with war stories, most of which do a great job of illustrating a point. Mostly I found myself nodding in agreement with his thoughts. However, he advocates reading the manual/databooks from cover to cover when looking for problems. That's great advice... but given today's 500 page datasheets and the deadline's screaming demands it's impractical in many cases. Geez, the OMAP datasheets are around 5000 pages each. He also believes in "knowing your tools." Great advice. As an ex-tool vendor I was always frustrated by so many customers who mastered 5% of the product's capabilities, when other features would be so helpful. Alas, that problem probably ties into the 500 page datasheet/screaming deadline challenge. But so many tools offer so much capability that it makes sense to learn more than the minimum needed to set a breakpoint or to scope a signal. He asks: "Did you fix it or did you get lucky?" And then says: "It never goes away by itself." Absolutely. A problem that mysteriously disappears inevitably mysteriously reappears, usually at the worst possible time. Though old the book remains very topical, with just a tiny bit of dated material (like advice to be wary of in-circuit emulators, which are far less common now than of yore). Reading this brought back many memories. His aphorisms, like "use a rifle, not a shotgun" were driven into us young engineers long ago and are still valid. Another oldie that's a favorite: "The shortest pencil is longer than the longest memory" (i.e., take notes). So anyone with experience will say "sure, I know all this stuff – why read the book?" The answer is that we may know it all, but it's too-often disorganized knowledge not used with discipline. Just as a tent revival meeting doesn't teach anyone anything they don't know, the book takes the known and organizes that knowledge, driving the message in deeply. For newbies the book is even more important. Every new grad should read this. It's interesting and fun. Recommended.