Teaching basic lab skillsfor research computing

Teaching Python to undergraduate geoscientists: A summary of our approaches and experiences over the years

In 2010, a new course commenced at Imperial College London that aimed to teach undergraduate geoscience students how to program in Python. Over the course of five years (2010 to 2014 inclusive) our teaching methodology evolved significantly in response to student feedback and examination performance. The course lecturers (Gerard Gorman and myself, Christian Jacobs) along with several of our Teaching Assistants also undertook Software Carpentry instructor training which offered a fantastic pedagogical insight into how to effectively teach novices how to program. As a result, many of our teaching techniques were influenced by this which helped to greatly improve our course. In this blog post we summarise what we changed throughout the five years and why, in the hope that this will benefit other instructors currently offering, or planning to offer, an undergraduate computer programming course.

To give a bit of context, each class normally comprised about 80-90 geoscience undergraduates, most of whom had no prior knowledge of computing. All teaching took place in a computer lab during a 3-hour time slot each week, for a total of 8 weeks. Initially we decided to adopt a traditional ‘talk and chalk’ lecturing style in 2010, spending most of the 3 hours describing theoretical concepts with very little time for practical exercises. The formal, summative feedback from the students at the end of the course (rating both the lecturer and the content via an online form) indicated a high level of student satisfaction. This was most likely because the traditional lecturing style was what the students were used to. Surprisingly, the examination marks painted a very different picture; a low mean mark of 50.5% in the final exam indicated that the learning outcomes were poor, despite the positive feedback. We quickly realised that, since programming is a practical skill, just like learning to ride a bike or learning how to swim, more time must be allocated for practice.

The main change in 2011 was therefore to introduce an additional 3-hour practical workshop. Significantly more positive comments were received from the students regarding the quality and quantity of support on offer, and the overall high score from the summative feedback was maintained. However, while the mean examination mark of 68.9% was a significant improvement over the previous year, the amount of extra time allocated was unsustainable for future years; this highlighted a common problem of trying to fit in more computing into an already full curriculum (a point that was also noted by Greg Wilson in his SciPy 2014 talk). Furthermore, the trending issue indicated by the students’ comments was that of the pace being too fast.

In 2012 we moved away from traditional lecturing and instead introduced online YouTube videos to deliver the course content. This successfully addressed the aforementioned issue of pace by allowing students to work at their own speed and watch the videos again if necessary. Yet in the summative feedback at the end of the course we realised that the students did not feel supported by this unfamiliar method of content delivery. The students gave the content and lecturer a considerably lower score this year, and largely negative comments were received along the lines of ‘the lecturer is not lecturing us’. It also became clear from the mean mark of 60.3% that this approach offered no benefit to learning outcomes.

After taking Software Carpentry instructor training we became aware of the flipped classroom approach, which we implemented in 2013. This is a type of blended learning in which a brief lecture is given to establish context, followed by a much longer practical session in which the students tackled exercises within IPython Notebooks. The learning outcomes were significantly improved, with examination marks (74.5% mean) being greatly skewed towards the positive end of the scale. Positive summative feedback was received with respect to both support and pace. On the other hand, the majority of the negative feedback was about lecturing style, which once again did not match student expectations.

In light of the success of blended learning we continued to use this approach in 2014, but justified the approach to students and emphasised the benefits throughout. Students felt reassured, resulting in only positive comments regarding lecturing style. We also implemented several other changes:

Rather than having one long practical session, we split up the workshop into ‘bitesize chunks’. This mixed short lectures (10-15 minutes) with multiple, in-class exercise sessions (30-40 minutes) so that students did not become exhausted.

We introduced the use of ‘sticky notes’, a technique frequently used by Software Carpentry workshops. Students were given one red and one green sticky note at start of class. Each student posts the green note on top of their computer monitor when they complete a particular exercise, which acts as a visual indicator of progress. The student posts the red note if they require assistance; this alerts the lecturer and TAs, and allows the student to continue working without keeping their hand raised, thereby improving productivity. Both the green and red notes were also used to provide positive and negative feedback at the end of each workshop.

Once again the exam marks were positively skewed in 2014, and most students did very well in meeting learning outcomes. Overall, we feel that we have converged on an effective teaching methodology involving blended learning and formative student feedback. We hope to conduct a more formal, quasi-experimental pedagogical study in the future using a planned method of data collection from the outset, unlike the present study which was more retrospective in nature.