I was invited to deliver two lectures for the Multimedia Authoring module on March 20 and 27. The title of the lectures was Lingo Scripting for Games. I was delighted and ready to experiment some new teaching strategies.
One year ago, I delivered the same topic, using on-the-spot teaching method to engage the learners.
In my such delivery, I fumbled and made mistakes but I always managed to get back on track by talking aloud what I was doing. In the lesson, I would first develop the game by hard coding to produce an initial running program and progressively converted it to a more flexible, re-usable and sophisticated one.
The intention of the lessons was to teach problem solving skill rather than a computer scripting language where one would normally teach the syntax and commands. I also wanted to impart program design concept transparently via the apprenticeship learning approach.
Hence, I taught students how to define and specify the problem, and how to represent the problem in diagrammatic forms before coding. I introduced the stepwise refinement method by playing the role of a competent programmer while the students as the apprentices, watched the expert carrying out his job.
This method of teaching was fun and afresh, I was told. But it was no fun to me as I was struggling to get things right on the fly, in front of a live audience. It was taxing and stressful.
The history and purpose of such teaching strategy was entailed in my paper entitled The Art of Computer Scripting.
This year, my teaching strategy largely remained the same except one difference: I fumbled more and not able to recover from it with only 5 minutes left in the session.
Time had me pressured. I was panic and not able to spot and solve the problem. I decided to let it be by presenting it as a challenge for students to solve.
Few days after my lecture, I wrote the first e-learning article accompanied the lesson, entailing what had been covered in the lecture and the bug I encountered. I enticed and challenged the students to beat me in the race of bug finding. That was the first of my three-part email I intended to send.
The objective was to create excitement, tension, and thrill in wanting to beat the lecturer, who was often viewed as perfect and always correct. I was hoping that through this process, students would be fully engaged and acquired a more in-depth understanding of the subject matter.
One day later, I sent the second email out in which I reiterated my unsuccessful attempts to debug the program and expressed concerns as works cropped up with time diminishing.
To my surprise, I received three emails from the same student on his attempts to solve the bug. He confessed to me that he did not attend my lecture and hence did not know what the bug was. He also tried to comfort me and shared with me that he too was under pressure to complete his assigned practical work where he did not have great interest in.
What impressed me, however, was his thinking process: his problem solving skill - it was excellent and commendable given that he was only a first year student. The steps carried out by him, the experiments I referred to in my lecture had eventually led him to the solution.
I was beaten but happy because I had succeeded in engaging students on and off lesson hours.
I teach what I preach - performance-based instructional design.
No comments:
Post a Comment