There is a lot of talk about teaching debugging going on there days. Amy Ko of the University of Washington did a podcast a short time ago on the subject. Amy Ko on teaching debugging. and that started some conversation on social media. Mike Zamansky gave a review and additional thoughts at CS Ed Podcast 3 – Debugging. I left a comment on Mike’s post about the “good old days” when CS students were lucky to get more than one compile a day.
I can hear people thinking “OK boomer” and expecting me to ask people to remove themselves from my lawn.
Seriously though, there was a time when we had to read our code very closely and we had to really try to understand the error messages we were getting. That wasn’t such a bad thing. Today I see a lot of students throwing code in almost randomly in hopes that it will fix a problem they have not really taken the time to understand.
If you are teaching beginners to program you have almost certainly had a conversation like this:
Student: I am getting an error.
Teacher: What is the error message?
Student: I don’t know. I didn’t read it.
You can ask them to read it but they tend to do so as if for your benefit and not out of an attempt to understand it themselves. Now this is not all students of course but it is fairly frequent. They are somewhat spoiled in a way by having a teacher who can explain what an error means to them. This is unlike when I was learning and there was no one around the computer lab (One computer room one computer) to explain error messages.
How do we get students to understand error messages? How do we get them to look closely at their code. So they find the 1 that should be an I or l themselves? It’s a struggle we all face.
SO we try to model good debugging practice. We demo debuggers. We help students understand the error message and ask them to figure out how it relates to their code. And we let them struggle a bit before coming to the rescue before they get to frustrated and give up completely.
Sure there are lots of benefits to being able to compile dozens of times an hour. It lets students experiment and get creative. But sometimes I do miss those one compile a day days.
I do not miss punch cards. It was a hassle to haul the box of cards around. I also cannot type and time on the punch typer was a reservation thing. Forty or fifty cards (intro course, small programs) took me forever. It was one compile a day but that just meant 4 or 5 days of compiles.
ReplyDeleteI think that this is an interesting topic. Like Garth said, I certainly don't miss punch cards. At high school, we were one a day compile and thought I'd died and gone to heaven when we could stand in line and have multiple runs at university. Then, when we got those lovely DEC terminals!
ReplyDeleteI think we also need to be honest here. In the "good old days", we had "easier" problems to solve. In my case, my teachers and professors were really arms length when it came to reading and interpreting error messages. We were left to fend for ourselves. We also learned in a time when flowcharting, structure diagrams, etc were the norm and tracing a program was all required for marks.
We didn't have the luxury of "let's try this and see what happens" which can be a last option or a launch pad for deeper learning.
I think that it's crucial that students need to understand their programming and the logic that goes into it. That isn't always seen as solid pedagogy and I think that's a shame.