yes, I assumed that to be the book they meant. I read it 25 years ago. I am just surprised that it would be included in this list. I see no connection to the question posed.

I'm not sure why he included it in his list. However I do think that it does a very good job of bringing to light that your customers/users may not be appreciative of buggy code. They want something that "just works" and to not have to deal with vague error messages.

I started reading the book about a year into my first development job and it really brought to light the frustrations my users were having as I was seeing as it was just another interesting problem to me. As I said in my past post I haven't been diligent in reading it so I'm only a quarter of the way through but here's hoping I'll get more insights out of it when I pick it back up.

I do think that what this book talks about can be discovered in other ways, but for people who are just starting in the technology field it's a good primer to be aware of how others experience what you implement.

In a way, the entire book is about debugging, but the target is the author's thought process rather than code. While Robert Pirsig fictionalizes the story, in fact it's closely based on his own life, in which he sought understanding of values (via zen and academics) but somehow went wrong and ended up catatonic and in shock therapy. The plot is a revisit of the mind trek he was on then and a quest to see where he went wrong. Pirsig approaches this not as a psychologist, but as a reductionist philosopher/scientist, trying to identify what troubled him and caused him to fail -- a debugging of the mind.