Module delivery

From our own experiences of teaching courses based on the material in Python for Rookies, we recommend a largely practical approach to course delivery. In particular, we have found the following techniques useful:

Writing live code in lectures

We have observed that many students, particularly the weaker ones, suffer when presented with correct, finished programs as lecture material. For these student there is no way of knowing, or finding out, how the programmer derived the finished program from a specification. This makes it difficult for them to develop appropriate, adaptive strategies for their own programming. Where possible, we have tried to write the book in such a way that the thought process during programming is explicitly discussed. Secondly, students benefit from seeing competent programmers encounter and react to interpreter errors and semantic bugs. Students need to learn that much of programming revolves around testing and debugging and that it is "normal" to encounter problems when programming. Without this, many students, especially the weaker ones, can become demoralized and demotivated when encountering bugs in their own programs.

One particular issue is error messages. Unless students have seen the error messages and how programmers should react to and deal with then they can become a "brick wall" preventing students programming successfully. As an example: when Sarah first tried writing code live in lectures, one student exclaimed "Oh, so you get error messages too!". This single incident changed many students for the better.

For any teacher, and particularly those new to teaching, writing code live can seem like a daunting task. We recommend to junior colleagues that they spend time developing confidence in the classroom before trying this technique. One piece of advice we offer is to first motivate the students before using the technique:
- writing code is something they will be required to do, so it is useful to see how professionals do it; and
- encountering bugs and error messages is a fact of programming life and it is useful to seeing how to deal with them.
If these issues are discussed with the students in the first lecture, before they have seen the teacher write any code, they will be sympathetic to the idea that this will help them. In the event that a program cannot be debugged within the time of a teaching session (by either the teacher or the students) then a corrected version should be made available to students after the class.
Pair programming

Students beginning their programming careers start out with differing abilities and develop at vastly different paces. Pair programming, when used in a structured environment can help ameliorate the difficulty of working with mixed ability classes. Pairing weak students with strong students helps both. The stronger students benefit from having to explain code and basic concepts in detail and weaker students often feel more at ease asking peers for help than teachers.

It is true that there is a potential danger that the weaker student contributes little and learns little, simply relying on the stronger student, but we have not found this to be the case.

To use pair programming to its best effect, we recommend the following strategies:
- Only one student at a time should touch the keyboard and mouse. The other student should talk through the code which needs to be written and guide the first student.
- Students should swap roles periodically, and relatively frequently. We find it best if the role change events are driven by the teacher not by the pairs.
- Students should either be marked as pairs, or there should be a clear separation between formative work (which may be completed in pairs) and work to be assessed (which may not).
Multiple choice questions for lecture comprehension

Lectures are an efficient method for teaching delivery but often ineffective in terms of student comprehension. One way of increasing comprehension is to ask students to complete a set of multiple choice questions at the end of a lecture, immediately prior to beginning any practical work. This forces students to actively reflect on the material which has been covered by the teacher. We advise keeping the number of multiple choice questions which students complete as small as possible to cover the necessary material. In our experience students (especially weaker students) will complete online questionnaires in preference to more formative exercises such as writing code, as the former are seen as being easier.
Modal formative work

One difficulty in constructing a program of study for a mixed ability class is setting formative work which stretches excellent or highly motivated students without disadvantaging weaker students. One strategy for dealing with this is to separate formative and summative work into "normal" and "advanced". This needs to be presented sensitively to students. James has had considerable success in setting students minimal and more interesting work.