Ability to debug is really a function of general domain knowledge, "skill" of accessing documentation and/or examples, and good understanding of experimentation

Ability to debug is really a function of general domain knowledge, "skill" of accessing documentation and/or examples, and good understanding of experimentation. It's difficult to teach, as different coders approach problems in different ways. First, I'll explain what I think makes one good at debugging: 1. Domain knowledge, which I'll consider code that the programmer has either written herself or has otherwise become intimately familiar with, cannot really be taught. But you can at least prepare a bit so you don't get lost in the woods. I think it's good practise to understand the basic file structure of what your working on and, generally, what is in the files you might be working with. More detailed knowledge of code will come through being able to trace data through files. This is not trivial in larger code bases, again, I recommend using notes or whiteboards. This is necessarily lower when you first encounter significant code that is not your own, and people who can leverage their other skills tend to do better before acquiring knowledge of the surrounding code. 2. I say "skill" at finding documentation in quotes because sometimes, good documentation does not exist. But the only way to increase your knowledge of what's happening in your programs is to start figuring out what the components you are using. Generally, newer programmers tend to find that the code they are writing doesn't operate the way they hope because they have made a mistake in arguments or syntax. Examples really help alleviate this. I'm not certain this can be taught very well except for pointing students towards documentation, but good debuggers tend to understand the benefit innately before too long. 3. If you're having problems with code that you think should be working, you need to be tracing data. At each step, you should know what your variables are and what you expect them to be. This is not trivial, and it can be very difficult to determine just where something is going wrong. But this is also the heart of debugging: being able to figure out where your signals are getting turned around. When you have nothing else, you can just start testing components for correctness and model a cull cycle of your algorithms. I don't think this can be taught, because many bugs are not like one another. After time, you might grow to recognise code that would more probably produce bugs, but I don't think there is a teachable process for finding bugs. Sometimes, things just be broke. But knowing the manner in which things fail, you can find solutions that bypass the sorts of code that cause errors. I'm not saying this is easy, but I'm saying that it's something that you kind of need to learn for yourself.