There are several reasons that this book takes a multidisciplinary approach to debugging. One reason is that people are unique, and different people have different preferred modes of learning. Some people need to see things to learn, others prefer to hear new material, and others have trouble understanding unless they can work something with their hands. In a similar way, some people will relate to some of the lessons of certain disciplines better than others.
When the material in this book was presented in classes for computer science graduate students, I found a wide difference in which disciplines the students found most interesting or helpful. Some absolutely loved the analogy to detective literature. Others were uninterested. Some were fascinated by the study of human error. Others had trouble seeing how it was relevant to them. If you have problems relating to the analogy of one particular discipline, move on to another one, and come back later to the first one.
An undergraduate student who wants to develop debugging skills quickly should probably read chapters 1–4, 7–9, 5, 10, 11, and 15, in that order. Graduate students in computer science should add chapters 12–14 after that.
A professional programmer with years of experience may not feel the need to read the case studies (chapters 5 and 10). If you aren’t sure whether a chapter will be of use to you, read the review at the end of the chapter first.
The material in chapters 6 and 12 is more theoretical than the rest of the book. Chapter 6 gives the rationale for the organization of chapters 7–9. Chapter 12 applies ideas from cognitive psychology that attempt to explain how programmers create bugs.
Make sure that you read chapter 15, and make a plan for applying what you have read.