The other day, when I had the mini-research breakthrough on the problem that's vexed my student and me for weeks now, I was sitting in front of the computer with this student. We were painstakingly tracing through data generated by some of our code, line by line.
Student: When I ran the program last night, the data was the same up until iteration X. After that, it was different.
Me: OK, let's look at the data from iteration X-1.
[scrolling, scrolling, ... staring at screen]
Me: Well, it looks like the data at iteration X-1 is also different.
Me: Let's go look at iteration X-2....Yep, that's different too.
[this goes on for a few more rounds]
Student: Huh. It all looked ok last night. Of course I only looked at some of the output, not all of the output. I never thought of tracing backwards through all of the steps.
I wish I could say that this was an isolated incident. But it seems like many of the students that I work with, and most of the students that I teach, have no idea how to approach a problem like this. Debug a program? Try randomly changing lines of code and hope that something works, eventually. Verify that the data a program is generating is correct? Just look at 1 or 2 values; that should suffice.
It is easy for me, at this point in my career, to throw up my hands and say "Kids these days! Don't they teach them the scientific method anymore? Don't they know how to conduct an experiment?" Because I view tasks like this--debugging, data checking--as scientific experiments. You have a problem, you form a hypothesis, and then you construct thorough tests to prove or disprove that hypothesis. Lather, rinse, repeat.
But then I got to thinking: How did I learn to think about CS problems this way? Was it because I took years and years of science classes and logged countless hours in the lab? Well, that probably didn't hurt, but I don't think that's the complete answer. I do think that I learned more from experience: from being burned by problems like this before, sure, but also from watching and learning. I learned by observing what my mentors did, what my advisors did, what the smartest students did.
When I think about it this way, I don't feel so frustrated by scenes like the one I described above. Instead, I think of them as opportunities to model good research behavior to the next generation of researchers, to help my students learn how to research by showing them what good researchers do to solve problems.
Did my student learn anything from our interchange? I suspect he did. I also suspect that he'll make similar mistakes many, many times in the future. But I'm hoping this will at least cause him to start thinking a little more carefully about how he's approaching research problems in the future.
Teaching by example is hard! :)