If your students don’t do their homework, you can’t move forward.
I had hoped that my students would have spent significant time this week wrestling with material, but that was not the case. <RANT>I must admit, the excuse I like least is “my computer isn’t working.” Personally, I don’t care: get it fixed. Work somewhere else. Buy a Mac. Anything that gets you moving on work for the class you signed up for.</RANT>
It’s one thing when I’m dealing with undergraduates in large quantities; I expect things to be a bit different with a small number of adults. Anyway. I’ll stop ranting.
I think the session was still valuable and productive; we stepped through the drill-and-practice tutorials slowly with respect to how the code the students are writing relates to their interactions with the BlueJ environment. I do think that this is one of the difficult things about teaching programming: learning to see source code as an expression of run-time behavior. When I look at a piece of code, I immediately have a sense for what it will do when the program is running. When my students (who are just learning to program) look at a piece of source code, I have no idea what they think. Clearly, they don’t immediately see what (for example) the constructor does, and the effect of each method (in isolation), as well as the state of the object’s fields depending on the order of method invocation.
In short, I have a machine model in my head, and I can run programs on that machine. By looking at the source code.
Do my students need to learn to do this to learn to program, and if so, how do I help them achieve that? Time to hit the ACM Digital Library on topics like “machine model,” “program tracing,” and “run-time comprehension.” I’m not optimistic about what I’ll find.