||[Oct. 24th, 2007|12:02 pm]
As I was working on figuring out why a webpage wouldn't layout properly yesterday, it occurred to me that debugging problems is one of the purest expressions of the scientific method around. I think kids should learn that in school: if you understand how science works, you'll be able to make things work when they break.|
It's also one of the hardest things to teach. We're working on that right now: I've written a section outline for Friday which consists entirely of the TA writing code to produce "99 Bottles of Beer", starting from scratch -- and making a lot of mistakes as they go. It means that students get to see how debugging works, how you figure out what has actually gone wrong, that kinda thing.
I think it's probably easy to teach the basic principles, but very hard to teach all the patterns and tricks you learn from experience.
Hmm... it's probably also hard to intentionally write code with the kinds of bugs you encounter in real life...
I gave that assignment to my students, when I was teaching web design. I gave them a broken site, and made them fix it and write about the process. They *hated* the assignment. I got the most complaints about it. But, then, inevitably, when it was done, the loudest complainers thanked me. They said they learned more from that project than any other in the class.
It's amazing to me that sometimes scientists don't appear to understand the scientific method, at least in realms that aren't their area of study. When I was debugging systems when working in a lab, I'd start by trying a bunch of different things to try to isolate the problem, and the scientists would look over my shoulder and not get what I was trying to do. And when I figured out what the problem was, they'd think it was a miracle that I could figure it out, rather than sustained application of "hypothesis-experiment-analysis".
It's also pretty frustrating when I'm doing tech support, and I'm trying to include the customer in debugging by explaining what I'm checking and why I'm checking that and what I hope it will tell me, and then they answer me monosyllabically, as if they expect me to read their minds to figure out the problem.
Yes- I do this all the time. Break a problem up, test each bit independently if possible, and write down the details because I'll forget them by tomorrow. When I'm solving a problem I try to treat my "notes file" essentially as a lab book. It's a bit scary, sometimes, the amount of documentation; going back to October 1997. (*hugs emacs interactive search*)
The problem is, it can be a constant battle for me when I'm enjoying "performing science" on the system I'm working on (tweaking parameters), rather than (say) just looking up the answer in the manual, or just understanding the API better. :)
Also, if you understand science, you'll be able to make things break when they're working.
When working with high school students, Chris often comes up against them not wanting to use trial and error. When a stage lamp isn't working, they'll go to him and say "it's broken," like that means they're done. So he'll make them sit down and figure out where the problem is (the bulb, the cord, etc.). It never occurs to them to do this the first time. Which isn't surprising, since many of these kids have parents that won't let them boil water at home, let alone prepare a four course meal. And many of them get whiny when Chris won't give them the answer so they can do their task. I think it kind of blows their minds when they realize that Chris doesn't always have the answers, and that their task is to figure it out. But the ones who make it through this process fall in love with technical theatre.
When I was a student, I hated it when teachers gave me assignments where you not only had to find the answer, you had to find the question first. I was really busy as a student, both with classes and other things, and so I just wanted to learn the material as efficiently as possible. Also, when you're worried about your grades, I think student sometimes even perceive these kinds of assignments as "unfair." When you're expected to do a million things at once, and be perfect at all of them, their isn't as much room for the "error" part of "trial and error."
Does it disturb you that good debugging techniques are often indistinguishable from voodoo? :-)