Reflection on Module Organisation
of possible improvements. Following this, Section 3 details changes made to the module in light of the reflection and Section 4 analyses the changes that this made to student performance. Section 5 concludes the paper.
Reflection on Module Organisation
Some aspects of the module that worked well at the start of the project. The language chosen for the programming portfolio, Processing, is particularly suitable for Foundation Year study. Firstly, the majority of introductory programming courses use Java( Major, Kyriacou and Brereton, 2012), including the Keele first year module CSC-10024 Programming Fundamentals. Processing is based on Java and uses much of the same syntax, meaning that Computers and Programming prepares students for their first year at Keele without replicating Fundamentals of Programming. Additionally, Processing is purposely designed as a language for first-time programmers and is based around visual, interactive media( Processing Foundation, 2019). This is important, since Cunniff, Taylor and Black( 2013) and Milne and Rowe( 2002) found that graphical programming languages can help beginners build a mental model of how programs work and eliminate common bugs. Finally, a typical cohort has a wide range of programming experience. As a less wellknown language, Processing can level the playing field between complete novices and students who may have used some more common programming languages.
The general concept of the program design assessment was also a strong point. The selfdirected coding project that formed the majority of the portfolio marks would take place over an entire semester. Students would decide on a program to make and would then spend the semester determining how best to do this using the taught Processing techniques. While staff assistance would be available in the laboratory
classes, a good project would need a student to spend time developing their code independently. This gives the students a valuable experience of how their future studies could develop.
While the existence of a 20-credit module that is effectively split into two separate parts may appear idiosyncratic, this does afford some benefits in terms of module delivery. For example, it allows for flexible allocation of teaching time according to the needs of each side of the module, while also allowing the students the time to develop their programming skills over two semesters, rather than one. There are also opportunities to draw common threads between aspects of programming and theory, such as the theory of boolean logic and decisions in programs.
The project did, however, identify room for improvement. By the time that I became involved in the theory side of the module( 2015-16), the curriculum needed refreshing. This is not unusual in the rapidly developing field of Computer Science. The biggest issue with the theory side of the module was that it was principally delivered through a single weekly lecture, with only sporadic support from other classes. While lectures are a convenient method for delivering information, they only foster the development of the lower level cognitive skills in Bloom’ s taxonomy( Bloom, 1956). The provision of a single hour of lecturing per week did not allow for the students to apply, analyse, synthesise or evaluate meaningfully, meaning that their understanding of the module content was poorly developed. Furthermore, Kolb( 1984) emphasises the importance of experimentation and reflection in learning, which was not amply provided by a single weekly lecture. All of this is reflected in the relatively low mean exam marks of 51.20 % in 2013-14 and 59.44 % in 2014-151.
The programming side of the module also had scope for potential improvement. Processing was taught in programming laboratory sessions, where a section of the course notes( in. doc format) would be presented to the students, who would then be given the majority of the session to‘ play around’ with Processing. Perkins, et al.( 2013) distinguished between two types of programming students: those who enjoy experimenting and modifying code, and those who stop when confronted with a problem. In a broader review of issues in teaching programming,
24