Why Don't Schools Teach Debugging?

Why Don't Schools Teach Debugging?
danluu.com

They all follow a similar pattern of identifying what the problem is, what physical manifestations can actually cause that problem, and then eliminating them one by one. This involves looking at the whole picture to narrow it down. This is not something I learned in school, I just figured it out growing up. I've found friends that don't necessarily know anything about computers, but are mechanically inclined, think similarly to how I do. I do have an innate desire to understand how everything works, and this definitely helps me understand what can physically cause the problem. That said, I did just take an Intro to Math Thought, for my math degree, and while it didn't really teach problem solving as I described above, it dramatically improved the way I thought about proving things rigorously.

My older brother and I went through the same classes and labs together. He brought to the table 15 years of experience playing around with electronics, so when we took labs, he had a clear sense of how to debug hardware.

He would wave his hand over some part of the circuit, and make gnomic pronouncements like, "When the input goes over about 5 volts, this part goes apeshit and starts firing back at it." Then he'd swap out a cap or a resistor, and everything would start working. I just went along for the ride.

I had decent math skills, so I did all right in the program. But I never learned that intuitive, heuristic, holistic way of grokking circuits like my brother did. Nor could I ever see that the school had any way to reward people like him, who "got" things at a deep level.

My sense was always that his approach didn't test well. If you test people for calculating the right voltage, you end up rewarding people who "plug & chug" quickly, even if they don't know what the voltage means, or why it would make some cluster of components go apeshit when it goes over about five volts.

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.