Five things that made my first-year programming course better.

We’re always looking for ways to make our teaching better – more effective, more engaging and the kind of class that students fight to be in. I recently got the chance to write a new first-year course from scratch and, based on my previous experience, there were five things I did that, from early results, appear to have made a positive difference. Caveats: As always, there’s always the risk that any change will bring about an improvement or that this is cohort variation or many other factors. I’m basing this list on the intersection of things that I did and the things that my students thought made a difference.

1. Modern, appealing design of all course materials. The course materials had the same look and feel, based on a modern design template that used simple typefaces (Helvetica Neue and Courier New) with a straightforward colour scheme. When the lecture approach changed, as we’ll discuss shortly, there were strong cues in the material to indicate that we were in a different mode. My students are surrounded by good design all day, every day: advertising, games, magazines, TV, films, … If the most boring, listless and dull thing they see all day is my visual aids, there will be an association.
2. Lectures had two sections of content, one more lecture-y, one more tutorial, with a five minute break in the middle where we discussed topics of interest from outside the classroom. Every lecture hour contained coursework material, the chance t practice it and the opportunity to see how it all fitted into a bigger picture. Students were very positive in their support of the five-minute ‘distraction’ and it also provided an excellent transition point from ‘lecturing with participation’ to ‘student-focused peer-level activity with lecturer overview’.
3. Giving the students their own ‘interesting things’ space on the electronic forums. We had standard information fora, student questions and a couple of others where students could just chat about things. Participation in the ‘offside’ forums was optional although all students were enrolled at the start. It is some 3 months since the last class and there is still occasional traffic on the interesting things fora. It kept the main lines of communication clear but allowed, in much the same way as the five-minute diversion, space for expansion and thought.
4. We increased the difficulty of the practical work, once we had confirmed basic skills and provided practice in the skills required to approach the harder programming work. After several weeks of small ‘1 week’ scale C++ programming exercises, we dropped a deliberately loosely-spec’d problem onto the students that required them to carry out a proper design, plan their testing and write their code efficiently, over a two week timeframe. Before this we had rewarded design with a few marks and also had the in-class demonstrators discuss and encourage testing, as well as presenting it in lectures. Student feedback on this prac was very positive – challenging but highly rewarding. The code standard of the class jumped up after this. Also, students who had wondered why had been preaching design for such ‘simple’ problems indicated that they now understood that they had been practising design as a process, at the same time that they were practising coding. This startled some of them because we had apparently been thinking hard about the design of the course itself. (Which we had, but it’s nice when people realise it.)
5. We encouraged and rewarded student reflection on process with cold, hard marks. Student were required to provide a written reflection on their software development process at two stages, just after the hard prac and at the end of the course. Both times, most marks were awarded for clarity of communication and addressing key points, rather than any definition of a ‘right answer’. As a result, the final reflections were written at a very high level, showing a clear understanding of the requirement for design and testing, as well as having almost no syntax or grammar errors and, for the most parts, clearly showing evidence of thought and editing.

The class in question did very well but, regrettably, they should have anyway because they were all self-selected high achievers in a small class. There is no quantitative strength in a numerical discussion here (I have measurement elements in place but there is no significance in the results, yet). The qualitative approach is far more interesting, because the student feedback clearly shows participating, engaged and self-aware students who can communicate verbally and in writing. The hardest prac in the course was the most popular, because of the challenge, but it was an achievable challenge. We set the bar higher, the students climbed higher. Most, if not all of them, now realise the reason that we talk about design and testing so much, and how you can use one or both to reduce your development time by reducing your bug load in later phases. That’s not bad at all for the end of their first 12 months and only their second computing course after a rapid-fire grounding in OOP in C++ in a previous semester.

I look forward to running this course again next year with 130 students from a broad range. Let’s see what happens.