What do you think?
Rate this book
Debugging: The 9 Indispensable Rules for Finding Even the Most Elusive Software and Hardware Problems
When the pressure is on to resolve an elusive software or hardware glitch, what’s needed is a cool head courtesy of a set of rules guaranteed to work on any system, in any circumstance.
Written in a frank but engaging style, this book provides simple, foolproof principles guaranteed to help find any bug quickly. Recognized tech expert and author David Agans changes the way you think about debugging, making those pesky problems suddenly much easier to find and fix.
Agans identifies nine simple, practical rules that are applicable to any software application or hardware system, which can help detect any bug, no matter how tricky or obscure. Illustrating the rules with real-life bug-detection war stories, Debugging shows you how
Understand the how perceiving the ""roadmap"" can hasten your journeyQuit thinking and when hands-on investigation can’t be avoidedIsolate critical why changing one element at a time can be an essential toolKeep an audit how keeping a record of the debugging process can win the dayWhether the system or program you’re working on has been designed wrong, built wrong, or used wrong, Debugging helps you think correctly about bugs, so the problems virtually reveal themselves.
Written in a frank but engaging style, this book provides simple, foolproof principles guaranteed to help find any bug quickly. Recognized tech expert and author David Agans changes the way you think about debugging, making those pesky problems suddenly much easier to find and fix.
Agans identifies nine simple, practical rules that are applicable to any software application or hardware system, which can help detect any bug, no matter how tricky or obscure. Illustrating the rules with real-life bug-detection war stories, Debugging shows you how
Understand the how perceiving the ""roadmap"" can hasten your journeyQuit thinking and when hands-on investigation can’t be avoidedIsolate critical why changing one element at a time can be an essential toolKeep an audit how keeping a record of the debugging process can win the dayWhether the system or program you’re working on has been designed wrong, built wrong, or used wrong, Debugging helps you think correctly about bugs, so the problems virtually reveal themselves.
196 pages, Kindle Edition
First published September 23, 2002
184 people are currently reading
1071 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 53 reviews
June 26, 2015
As I've said about other software engineering books (and my review for "Debug It!"), there's a fair number of useful ideas in this book, and enough dubious ideas to hold back any forceful recommendation.
First things first: the "9 indispensable rules" are neither a checklist nor a rubric. They're aphorisms and rules of thumb. And just like everyday aphorisms (like "a bird in the hand is worth two in the bush"), most of the principles in this book (like "check the plug"):
- are simple enough to seem useless when you first hear them,
- actually contain a really useful idea that's worth internalizing,
- can help you in a great number of situations, but
- are also absolutely wrong in many other situations.
As a result, the best way to view this book is a collection of things to think about when debugging, rather than a rigorous methodology or procedure. (I actually like that the book talks broadly about technical concerns rather than being dogmatic about a specific approach, but the set-up is problematic because it invites blind adherence when a thoughtful application is more appropriate.)
The writing and the rules themselves are a bit muddled, and that can really lead readers down a wrong path. The best example is the rule "quit thinking and look", which could be much more accurately (and not less succinctly) called "stop guessing and gather data". I get what the author wants to say, but telling people to "quit thinking" isn't what he means. That's actually the opposite of what inexperienced engineers need to learn about debugging. Worse, there's a strong tendency for people to take such pat one-liners out of context, and the author invites that by promoting the rules themselves rather than the ideas.
In summary: as with "Debug It!", there are useful ideas here, but they should be considered very thoughtfully.
First things first: the "9 indispensable rules" are neither a checklist nor a rubric. They're aphorisms and rules of thumb. And just like everyday aphorisms (like "a bird in the hand is worth two in the bush"), most of the principles in this book (like "check the plug"):
- are simple enough to seem useless when you first hear them,
- actually contain a really useful idea that's worth internalizing,
- can help you in a great number of situations, but
- are also absolutely wrong in many other situations.
As a result, the best way to view this book is a collection of things to think about when debugging, rather than a rigorous methodology or procedure. (I actually like that the book talks broadly about technical concerns rather than being dogmatic about a specific approach, but the set-up is problematic because it invites blind adherence when a thoughtful application is more appropriate.)
The writing and the rules themselves are a bit muddled, and that can really lead readers down a wrong path. The best example is the rule "quit thinking and look", which could be much more accurately (and not less succinctly) called "stop guessing and gather data". I get what the author wants to say, but telling people to "quit thinking" isn't what he means. That's actually the opposite of what inexperienced engineers need to learn about debugging. Worse, there's a strong tendency for people to take such pat one-liners out of context, and the author invites that by promoting the rules themselves rather than the ideas.
In summary: as with "Debug It!", there are useful ideas here, but they should be considered very thoughtfully.
July 15, 2017
"This book tells you how to find out what's wrong with stuff, quick. It's short and fun because it has to be -- if you're an engineer, you're too busy debugging to read anything more than the daily comics."
Примерно с этого начинается первая глава. Тут всё правда. Книга небольшая, книга весёлая и в ней всё по делу.
Книга именно про отладку. Причём не делается акцент, что это должна быть отладка софта. Автор, судя по историям, успел поработать и с софтом и с железом, поэтому на чём-то одном не зацикливается. Вот есть проблема, вот правила, которые нужны применять, чтобы её найти и починить (правило про Quit Thinking and Look вот прям очень хорошее).
В книге куча примеров (war stories). Многие из них не про программирование (машины, которые не заводятся; окна которые пропускают воду; видеочип, работа которого зависит от рубашки тестировщика, etc.). Из-за разнообразия, правда, не всегда понятны детали. Но читать всё равно интересно.
Не могу сказать, что после прочтения я стал ошибки находить в два раза быстрее. Но в каких-то сложных случаях советы (Quit Thinking and Look, Keep an Audit Trail) реально помогали.
Рекомендую. Сам прочитал два раза подряд.
March 21, 2018
A solid book on general (timeless) debugging principles. As I read this book I noticed I seemed to (almost magically) be debugging more effectively. Also, this book recommends that you learn your debugging tools well, so I learned and practiced using PyCharm's debugger well, which has made a huge difference when I'm debugging Python code.
March 12, 2022
All in all, solid advice that's at a good abstraction level, not getting so detailed as to be not generally applicable. My main knocks are that it really deserves an update for modern software development and the author's tone might be too much for some. (It was usually okay for me, but I did get annoyed a number of times.)
I'd recommend it to anyone who feels like they have something to learn about debugging. It's not long, and the style does make it a fairly easy read.
While the first rule still remains relevant (seriously, more devs should read documentation and code), it's certainly not as feasible to cover as much system understanding now than it used to be. If you're in the JS ecosystem, good luck with understanding the system!
I don't think anyone obeys all the rules all the time while debugging, myself included, but also probably everyone could do them more often. For me, that would primarily be keeping an audit trail!
I'd recommend it to anyone who feels like they have something to learn about debugging. It's not long, and the style does make it a fairly easy read.
While the first rule still remains relevant (seriously, more devs should read documentation and code), it's certainly not as feasible to cover as much system understanding now than it used to be. If you're in the JS ecosystem, good luck with understanding the system!
I don't think anyone obeys all the rules all the time while debugging, myself included, but also probably everyone could do them more often. For me, that would primarily be keeping an audit trail!
January 19, 2024
Quite ok, advice are sound, book is quite short not to drag on too much, written with good humour, and peppered with plenty of stories about applying said advice in practice.
If you're short on time and want to get the general idea - rules are listed out right in the beginning, and in a slightly more detailed version in last section of every chapter.
Otherwise, it would work well if you just want to relax, read something easy, funny and a bit educating.
If you're short on time and want to get the general idea - rules are listed out right in the beginning, and in a slightly more detailed version in last section of every chapter.
Otherwise, it would work well if you just want to relax, read something easy, funny and a bit educating.
April 21, 2025
I loved it.
All these rules should be obvious to anyone who has debugged anything. And yet, most people don't follow them, and even people that do know them stray. The book makes a great job of explaining them, and all the stories are interesting and real fun to read.
(he should do a technical autobiography, I'd buy that)
All these rules should be obvious to anyone who has debugged anything. And yet, most people don't follow them, and even people that do know them stray. The book makes a great job of explaining them, and all the stories are interesting and real fun to read.
(he should do a technical autobiography, I'd buy that)
September 9, 2018
In my view this book was too long.
The rules are clear, make sense, but they were introduced by A LOT of war stories, most of them related to how you debug hardware problem. I had some issues following all the explanation there.
The rules are clear, make sense, but they were introduced by A LOT of war stories, most of them related to how you debug hardware problem. I had some issues following all the explanation there.
August 19, 2024
- This is the first book about debugging I have read, and I like it.
- The debugging rules mentioned in this book are practical and it aligns with my experience and knowledge in software industry.
- For instance, one of the things I learned right after becoming a software engineer, is the second rule in this book: Make it fail. It means we skills look for the way to be able to make the program failed deliberately. In that way, we could find out the root cause and test if our fix works.
- The rules may sound trivial or even elementary. However, in reality, complex problems are almost always discovered, or missed by such fundamental techniques. I enjoy this book because it has reminded me those tiny thoughts, which I often forget, and take me some time on recalling them.
- As the author stated, not all engineers need this book to do their job well, because most of them will develop or learn at least some of these skills mindset while working. Not to mention, some of them are natural who possess the debugging mindset already.
- The author used a humorous tone with tons of examples (it is called war story) to explain the concepts. They are realistic and make it easy for us to memorize them.
- To conclude, I would recommend this book to any problem solvers out there who want a summary on problem fixing skills.
- The debugging rules mentioned in this book are practical and it aligns with my experience and knowledge in software industry.
- For instance, one of the things I learned right after becoming a software engineer, is the second rule in this book: Make it fail. It means we skills look for the way to be able to make the program failed deliberately. In that way, we could find out the root cause and test if our fix works.
- The rules may sound trivial or even elementary. However, in reality, complex problems are almost always discovered, or missed by such fundamental techniques. I enjoy this book because it has reminded me those tiny thoughts, which I often forget, and take me some time on recalling them.
- As the author stated, not all engineers need this book to do their job well, because most of them will develop or learn at least some of these skills mindset while working. Not to mention, some of them are natural who possess the debugging mindset already.
- The author used a humorous tone with tons of examples (it is called war story) to explain the concepts. They are realistic and make it easy for us to memorize them.
- To conclude, I would recommend this book to any problem solvers out there who want a summary on problem fixing skills.
May 17, 2022
The most important point of this book is reminding: debugging is full of methodology!
The idea sounds natural after pointing out, but in practice, very often, we wading through the bug forests, navigating or lost in the software maze, we forgot this.
Before reading this book, I already sensed this so it's a good time to read it.
The book has a good coverage overall, understand the system, know the limit of the tools, stop
The big downside however, is the elusive writing of the hardware case study. As a software guy, they are really hard to follow, plus seems too much tied to a specific problem. The author spent lengthy space about them. Even worse, he diligently trying to callback the case in the principles. This can really be more concise.
I also don't like some arguments. e.g. "troubleshooting is different from debugging." "don't stimulate the bugs, but stimulate them." They are just word game and exists only for the sake of having comparison?
My approach to digest this book: focus on bold text and titles, be selective and conscious of them, try to see if you can find past experience correlatable for proof, counterexample, further thoughts, etc.
summarize it.
worth a read, for sure.
The idea sounds natural after pointing out, but in practice, very often, we wading through the bug forests, navigating or lost in the software maze, we forgot this.
Before reading this book, I already sensed this so it's a good time to read it.
The book has a good coverage overall, understand the system, know the limit of the tools, stop
The big downside however, is the elusive writing of the hardware case study. As a software guy, they are really hard to follow, plus seems too much tied to a specific problem. The author spent lengthy space about them. Even worse, he diligently trying to callback the case in the principles. This can really be more concise.
I also don't like some arguments. e.g. "troubleshooting is different from debugging." "don't stimulate the bugs, but stimulate them." They are just word game and exists only for the sake of having comparison?
My approach to digest this book: focus on bold text and titles, be selective and conscious of them, try to see if you can find past experience correlatable for proof, counterexample, further thoughts, etc.
summarize it.
worth a read, for sure.
February 16, 2021
This is a fantastic, practical book full of really solid wisdom for troubleshooting systems. It emphasizes many of the things that we often neglect by over analyzing the situation. The best rule, in my opinion, is "Quit thinking and look": an exhortation to closely examine the problem, in its entirety, before thinking about solutions. I have seen both myself and others pontificate and ruminate on the potential solution to a problem while the issue itself was staring us right in the face if we bothered to just examine it closely.
Granted, this book is written from the perspective of someone who has an electrical engineering background, meaning it may have some examples that are inaccessible to anyone not familiar with the trade. I think the hurdles to understanding are low, and the book is written in very clear language that will benefit anyone looking to improve their mindset with troubleshooting.
Granted, this book is written from the perspective of someone who has an electrical engineering background, meaning it may have some examples that are inaccessible to anyone not familiar with the trade. I think the hurdles to understanding are low, and the book is written in very clear language that will benefit anyone looking to improve their mindset with troubleshooting.
May 6, 2025
I enjoyed this book more than I expected to considering it was required reading for my job. Even though it was published the year I was born there were tons of relevant concepts that I have already been able to apply to my Software Job and throughout my life. The narration of the War Story’s kept me engaged, I would love to see this revamped with some additional modern examples because I do think that the rules stand the test of time extremely well.
It’s nice to have a more concrete approach to debugging than turning something off and back on again although that wasn’t forgotten as it’s its own rule! I also work Support for our applications and the Help Desk chapter was particularly interesting because that covers the other portion of my Job. Mark (my boss) absolutely killing it with the book recs and I couldn’t not count it towards my goal because it definitely derailed my “reading for fun” books last week.
It’s nice to have a more concrete approach to debugging than turning something off and back on again although that wasn’t forgotten as it’s its own rule! I also work Support for our applications and the Help Desk chapter was particularly interesting because that covers the other portion of my Job. Mark (my boss) absolutely killing it with the book recs and I couldn’t not count it towards my goal because it definitely derailed my “reading for fun” books last week.
April 25, 2025
Enjoyable, to the point, and full of useful ideas crystallised to the point where you can communicate them to others, or slap your forehead and say "wait, I should Quit Thinking And Look". The war stories are all illustrative and entertaining: it might have been a better book if it had drawn from a wider range of engineers' experiences, but Dave Agans' own career has furnished plenty of material. My only real criticism of the material is that his distinction between *stimulating* the failure (good) and *simulating* the failure (bad, or at least suboptimal) isn't as clear as I'd like. Still, I'm sure I shall be returning to this book regularly, and recommending it to junior (and not so junior!) colleagues.
February 10, 2025
Sometimes while reading, I would get the thought: this is common sense, why am I reading this? Then at work I would do something stupid, and realize that the common sense he preached is looked over so often creating problems and hold ups while debugging. I started using his list of items while debugging, thinking through it like his examples, and I can say my work really improved as I did so. I think it was written for people like me: early career, still in the "make it work" phase, and lacking the experience to problem solve efficiently. I really think this book made a real difference for me as an engineer, specially when I could see such a direct effect on my work.
April 29, 2022
This was assigned as part of the reading in a CS course. It was written in 2002, and, honestly, feels like it was written in 1972. The content itself is fairly straightforward and focused on debugging hardware and oftentimes hardware related to TV and radio, not modern tech. The language used is cringey and outdated, it assumes every reader is an older male. I let the prof know it should probably be replaced with something a little more modern that emphasizes debugging on tech that is at least from the last 10 or so years.
February 11, 2024
As a software engineer I found the book very helpful in terms of the way to debug issues more systematically and efficiently. The author provides a good mental framework to approach problems with the software and hardware systems. I especially liked a few advices: "quit thinking and look" and "make it fail". I do debug software bugs on daily basis and started to apply these principles along with "keep an audit trail" which resulted in faster bugs resolving. I would recommend the book for any engineers who are willing to improve their debugging & troubleshooting skills.
January 21, 2025
Excellent stuff!
Sure, it's things you consciously think you already know, but it's great to have them laid out like this in a straightforward manner; plus the war stories are both interesting and varied and I think the humor was alright too.
Might be worth trying as a non-engineer too - you can might have to skip the more in-depth technical parts but I'm sure the problem-solving tips and tricks will come in handy in life (like when your water heater is not doing its job well, to reference a particular anecdote)
Sure, it's things you consciously think you already know, but it's great to have them laid out like this in a straightforward manner; plus the war stories are both interesting and varied and I think the humor was alright too.
Might be worth trying as a non-engineer too - you can might have to skip the more in-depth technical parts but I'm sure the problem-solving tips and tricks will come in handy in life (like when your water heater is not doing its job well, to reference a particular anecdote)
September 28, 2020
I enjoyed the book, but a little less so toward the end. The initial rules are more important and interesting, their chapters were more engaging reads. The chapters for the last two to three rules were less interesting to me (and shorter content). The extra chapters after the rules (recap etc), felt redundant. The writing style and anecdotes are dated, but mostly this made the book more enjoyable for me, good job to Mr Agans.
July 11, 2020
Good book, entertaining to read, some very good field stories that most engineers, specially those in electronics, will surely enjoy. There are no big new ideas - the author admits it is mostly formalized common sense. Regardless, simply formalizing is valuable as it allows you to have a good grip on what NOT to do and why you do things in certain way.
January 31, 2022
This book is to debugging, what Clean Code is to programming. Which is to say: Though it contains outdated examples, and sometimes the advice is too idealistic and stringent, it is still a helpful list of fundamentals every engineer (and people dealing with engineering-like problems) should go through once.
November 12, 2024
Really loved the book!
It explains the logic behind the rules, how you can apply them and why they are effective.
I truly recommend to anyone that wants to understand how to debug things. Even if some of the ideas I intuitively understood and applied, it was nice to get them even more highlighted and explained.
It explains the logic behind the rules, how you can apply them and why they are effective.
I truly recommend to anyone that wants to understand how to debug things. Even if some of the ideas I intuitively understood and applied, it was nice to get them even more highlighted and explained.
April 13, 2025
The antidote and basically the antithesis to vibe coding which I really appreciate. Simple rules to follow when debugging errors in code that can make your life much easier and less frustrating when errors do occur. Very digestible with interesting about hardware and software and its interactions from a persons life experience.
May 25, 2018
I really enjoyed this book. I recently did a talk about debugging and there was a lot of overlap. Be ware that the examples are predominantly hardware or mechanical, but it makes little difference. This is a great resource.
August 13, 2020
A lot of this I knew instinctively, as will surely be true for any of us who have to debug as part of their jobs, but this book distilled this knowledge succinctly into 9 simple rules, with great "war stories" to help us see the application of these rules in "real world" scenarios.
July 9, 2023
It's remarkable that despite the rapid changes in tech, the concepts presented in this book remain relevant two decades after its publication. However, the 'war stories' in this book are quite dated which makes it challenging to read.
January 29, 2025
I think a lot of us apply these principles instinctively all the time. But, it is nice to have things written down more concretely. It helps you identify when you are ignoring something obvious because of a blind-spot.
June 12, 2025
While some of it may feel obvious or repetitive, there are a lot of good lessons to learn from. At the very least, it's made me think about how I'm thinking when I need to debug something, which in itself is valuable
September 14, 2017
If you're a programmer: read this book!
January 6, 2019
A good systematic way to debug problems, worth practicing. The examples are outdated but nonetheless help the reader to understand the techniques.
February 29, 2020
One of my favorite engineering books because it explains in an easy way the steps to debug machines and systems.
March 3, 2020
Fairly basic, but some fun anecdotes.
Displaying 1 - 30 of 53 reviews