The other day I was demonstrating some things to my programming students. We’re at the very beginning of a new semester and students are learning the very basics. We were doing a simple exercise to help students understand how assignments work with object properties. The program moves the contents of one picturebox into another when a button was clicked. I took my sample program, added an array and a timer and had it automatically rotate images across the screen.
It looks sort of nice and reminded me of the old idle loop light displays we had “back in the day.” It was something I did just for the fun of it. One might say “because I could.” And then a voice in the back of the room asked in wonder “Are we going to learn how to do that?” And then it hit me that I had done something a bit more interesting than I’d intended. I’d attracted some curiosity with it too!
Students are always willing to work harder to learn something they want to learn. A number of teachers have talked to me about just in time learning where students are taught a concept because they need it then. I tend to push out a concept and then asking them to use it in a project. I think I need to set things up so they pull the concept from me rather than me pushing it out. Doing the right demo may do that. That is something I want to try.
At this point I’m planning on demonstrating working programs first and then talking about the concepts needed to create them. What I want to do is create projects the students want to do so they want to pay attention. Few seem to be interested in learning for the sake of learning. Or even for potential future use. If they see an actual use that seems interesting I think it will be easier.
Ultimately I want to help students motivate themselves to learn rather than me trying to force feed them information.
4 comments:
An RSX customer tried to kill the *IDLE* task because "It runs all the time but doesn't seem to do anything."
My favorite idle loop story is about an old Burroughs computer. It had a huge light display and the idle loop displayed the Burroughs B logo. One customer wanted the lights to display his companies logo. People tried to explain that for the millions of dollars they were spending on the machine seeing the idle loop run was just about the last thing they wanted. In the end they programmed the idle loop they way he wanted because, after all, it was millions of dollars for the sale.
I came into a math department that had a culture of beginning every new "unit" with a real-life problem, and then demonstrating the math that was needed to solve the problem. (Simple example: if we want to know how tall a tree is, we can do something with shadows and similar triangles (as long as we move fast enough that the sun hasn't changed much between the time we measure the shadow of the shorter object and that of the taller object)). It was a compelling way of teaching, as compared to teaching a "pure" algebra concept, practicing it in a vacuum, and then asking students to apply it to word problems near the end of the problem set. We might do some intermediate "pure" practice, to be sure they get it right, but not before we've shown how it will be used, once it's learned. (This is not as compelling as looping lights, of course!)
A problem is there is so often a huge amount of foundation work required before getting to the really fun stuff. The kids want to know how to write something like Angry Birds and yet are not willing to spend the time to learn how to write Angry Birds. For a teacher the tricky part is finding interesting things to do with those basics so the kids will hang around long enough to learn how to write Angry Birds. I am still trying to build a library of projects that are not to simplistic and get the kids to learn programming without boring them stiff.
Post a Comment