Programming Pedagogy

I was at the local authority meeting of Computing teachers last week. One of the topics discussed was how we taught computer programming to our pupils. It was such a great discussion I thought I’d share some of the ideas and my own interpretations or opinions on the subject.

With six years of software engineer experience prior to becoming a teacher I feel I am an adequate code monkey. However although I might be able to see patterns, pseudocode and data flow tables from a cursory glance at a problem specification I know that my pupils can struggle to attain the problem solving skills required. Common problems are the mispelling of variable or procedure names, not ending loops or conditional statements, and typing code into Visual Basic 5 (our language of limited choice) without setting up the event definitions first. In short, there is a issue with my pupils’ programming literacy.

In my five years of teaching Higher Computing I have been the second pair of eyes in the classroom, helping pupils debug their programs by pointing out their spelling mistakes and decrying their inability to read a meaningful error message.

At the meeting one possible solution was suggested. One so simple it made my jaw drop. Pupils program in pairs, being the lead programmer and second pair of eyes alternatively. I’ll admit I was a little embarrassed that I’d never tried this strategy before but feel that this might improve error detection if not programming procedure if the pairs are selected carefully.

Other strategies suggested included, in my opinion, the outdated practice of desk checking their program before typing it into Visual Basic. Every. Single. Time. I feel that this method goes against the grain of event-driven programming languages like Visual Basic which are meant to be used for rapid application development. Objects are dragged in from the toolbox, code is quickly constructed and linked, module libraries are knitted into the main program and quickly great things can be happening. In the past few years I’ve taught my Higher Computing pupils how to make MP3 player software, cave-flying games and a homage to Horrace Goes Ski-ing in double-period lessons. These lessons were fun and boosted the pupils’ confidence – where is the fun in desk checking your code for these applications?

A few years  ago a pupil joined my S4 class in the final two terms. He had completed almost all of his practical evidence for Standard Grade Computing Studies… except for programming. As our S3/4 course had changed to Int 2 Info Systems there was no programming in the plan and little time to set aside to teach this one pupil how to navigate their way through Visual Basic. I found some videos on the Internet which introduced the concepts and then adapted program task sheets to allow the pupil to gradually code with less and less support. He taught himself enough to gain a credit grade, but although video lessons are great in a crisis there was little chance for him to gain one-to-one feedback on the issues he was having with his own programs.

So I’m going to try paired programming with a small group of Higher and Intermediate 2 Computing pupils next term and see if their problem solving skills (and reliance on the eyesight of their teacher) make a change for the better. Anyone else in?