Supporting students in music technology higher education to learn ...

JMTE 7 (1) pp. 75–92 Intellect Limited 2014

Journal of Music, Technology & Education Volume 7 Number 1 © 2014 Intellect Ltd Article. English language. doi: 10.1386/jmte.7.1.75_1

David Moore Glasgow Caledonian University

Supporting students in music technology higher education to learn computer programming Abstract

Keywords

This article examines methods for supporting students in music technology-related higher education to learn computer programming. The central argument made in this work is that using collaborative activities and encouraging regular reflective writing can benefit novices in their programming. To support this argument evidence from the teaching and learning literature will be presented along with primary research findings by the author. The research findings indicate that the collaborative activities and reflective writing exercise employed on an audio programming module were successful in supporting novices and helped to promote a more active learning environment with evidence of deeper learning and engagement in programming concepts.

collaborative learning pair programming social constructivism reflective writing audio programming experiential learning

Introduction Programming is an important skill in music technology education. It allows students to go beyond the practical applications of music software and learn about the underlying principles of sound generation and signal processing algorithms. Students who become proficient in programming can build custom software applications for creative sound interaction and music composition,

75

David Moore

and can manipulate sound in ways only limited by their imagination. However, programming is a subject that can pose a significant challenge, particularly for those whose primary focus is not computer science. Some compare it to learning a foreign language, only one that deals with the world of algorithms and data structures (Smith et al. 2000). In subjects like music technology where programming is used primarily as a tool to support creative work, forms of integrated learning support are important to help students overcome initial technological barriers (Clarke 2006). Students on music technologyrelated courses often have different motivational goals than computer science students when it comes to programming i.e. some can often be more motivated to learn programming as they can see the creative potential it offers to their future artistic practice, however such students approach the subject from a more creative and less technological standpoint and though may be motivated can find it harder to pick up the programming concepts. There is a need to recognize this and take it into account into pedagogy. This article works towards addressing these points by exploring collaborative learning and reflective writing activities for supporting and enhancing learning of audio programming. It draws upon the educational literature in the fields of music technology and computer science and presents findings from the author’s own pedagogical research at Glasgow Caledonian University, which involved the application of pair programming and reflective blogs in the classroom. Although the teaching and learning of programming has received significant attention in recent years in the domain of computer science (e.g. Robins et al. 2010), relatively few studies examine teaching and learning of programming in subjects on the periphery of computer science such as music technology, and to the knowledge of the author pair programming and reflective journaling have not been examined together in the domain of music technology. As such, it is anticipated that work in this article will go some way to address this point and will help in determining more effective learning environments and teaching in this discipline area.

Learning and teaching programming Two approaches to programming are prominent in music technology education. The first focuses on graphical programming languages such as Max or Pure Data. The second focuses on text-based languages such as Java, Python or C/C++ (see Figure 1 for example). Graphical languages such as Max use the concept of modularity where building blocks of objects are connected together using patch cords. Data flows through the patch cords to each of the objects in sequence. The collection of objects and how they are connected together determines the algorithm. This form of data flow programming is attractive to those teaching in music technology and related fields as software development is visual and can be related to signal routing exercises. Moreover, instantaneous output can be obtained from applications allowing students to interact and engage with sound during the process of development. In comparison, text-based languages are more challenging. Syntactically they are more abstract and require a deeper knowledge of the computer and its operation as well as an understanding of compilers and libraries for real-time audio and MIDI support. However, with text-based programming there is normally more capacity for customizing and finetuning software applications than in graphical programming environments. Both approaches to programming have advantages and disadvantages but

76

Supporting students in music technology higher education …

Figure 1: Programming language examples (textual and graphical).

hichever approach is taken, the initial learning curve is steep and one that w requires the development of an understanding of key programming concepts. It can take time for students to develop mastery and confidence that can potentially impact student motivation and attrition rates. B. Du Boulay (1986) outlines five overlapping areas that students must overcome when learning to program, which apply to both the graphical and textual approaches: 1. 2. 3. 4. 5.

General orientation (what programming is/what it can be used for) Notational machine (understanding the computer and its operation) Notation (code syntax and semantics) Structures (programming constructs/schemas) Pragmatics (specifying, developing, testing, debugging)

These points are not independent of each other so the difficulty often lies in having to deal with all of them simultaneously. Attempting to do so results in tasks with high cognitive load, which even the most persistent can find demanding. Therefore one of the key pedagogical concerns when teaching programming is the structured introduction of the above concepts whilst carefully managing the cognitive load placed on the learner. This can be challenging, especially when domain-specific information is required to be introduced to the student as well, and in the case of music technology this issue can be further compounded by the fact that musical ideas are not always straightforward to specify as code. D. C. Smith et al. (2000) outline further issues students experience learning to program. They suggest that one of the main problems is closing the gap between the representations the brain uses when thinking about a problem, and the representations a computer will accept. This process typically involves several stages, usually starting with a program specification or initial idea, to writing and testing code (Figure 2 illustrates this). As an example, the initial idea could be centred on the design of a software synthesizer. Once

77

David Moore

Figure 2: General process of programming. a design for the synthesizer has been created, an algorithm is developed that may require abstraction and problem-solving skills. In the next stage (recipe creation) the programmer would need to draw upon mental models of common programming constructs. For example, branching (conditional statements) or repetition (looping) constructs that determine how audio data is routed or processed. When writing the code, the programmer requires knowledge of code syntax and semantics, and then when testing the code he or she may need to be able to track down and resolve bugs. Rarely does a single pass through this process result in a finished piece of software, so the programmer may need to repeat the process starting from an earlier stage in order to refine the software’s design. Being comfortable in tackling each of these areas is important in order to get from that initial idea to a finished piece of software. Focusing too much on developing notational mastery in the classroom for instance may result in students who can write code but cannot develop or test an algorithm sufficiently. Clearly learning programming is a challenging endeavour requiring a range of complex cognitive tasks related to development, testing and debugging. Furthermore, it can often require the application of complementary skills including problem-solving, abstraction, discrete mathematics and logic. Guiding and supporting development of these skills is therefore an important goal. Several studies have looked at the characteristics of novice programmers. Perkins et al. (1986) note there are two main types of novice programmer that are characterized by what they do when meeting a problem – so called ‘stoppers’ and ‘movers’. When confronted with programming issues, stoppers (as the name implies) simply stop working and seek help, whereas movers keep trying to solve the problem using feedback from their code, either effectively or

78


ineffectively. A. Robins et al. further characterize novice programmers as effective or ineffective stating, ‘[…] effective novices are able to learn to program, without excessive effort or assistance, whereas ineffective novices are those that do not learn, or do so only after inordinate effort and personal attention’ (2010). The authors cite a range of potentially relevant psychological factors that affect a novice programmer’s success, including confidence, emotional response and motivation. These characteristics are surely not confined to programming and are no doubt observable in many other disciplines/subject areas. The challenge is how to deal with them and assist students to overcome them. At a time when the number of students entering higher education is as high as ever, and where much emphasis is placed on independent learning, there need to be suitable methods of support in place for helping students develop skills to become autonomous learners and more effective programmers. Support for learners can come not just from teachers but also from peers and technology (Wingate 2007; Leese 2010). In recent years there has been much more emphasis on teaching the process of programming through activities involving peer interaction and collaboration – particularly to novices in the early stages of their degrees. There has also been exploration into other methods for supporting students and for encouraging a deeper approach to learning, including reflective writing. The following sections examine research in both of these areas.

Collaborative learning Programming is often seen as a solitary endeavour. However, there are increasing opportunities for collaboration in higher education. Collaborative learning provides a platform upon which independent learning is nurtured (Dillenbourg 1999). Underpinning this concept is social constructivism, which states that knowledge and understanding can be co-constructed through interactions with others in social learning environments (Vygotsky 1986). In such environments learners are encouraged to take shared responsibility for their goals and are placed at the centre of the learning activity with instructors normally acting as guiders and facilitators. Through peer interaction students’ metacognition capability can be enhanced allowing them to be more aware of gaps in their thinking (Schraw et al. 2006). Other cited benefits include: enhanced confidence and self-efficacy (Fenci and Scheel 2005), greater retention of learned material (Cortright et al. 2003), diversity of creative thought (Thousand et al. 2002), improved problem-solving capability and critical thinking (Gokhale 1995). It can also help in the development of social and interpersonal skills. When examining music technology literature, it can be seen that collaborative learning is already successfully applied in a number of areas. In the studio group work is the norm with students often completing recording and mixing tasks together (King 2008; Jones and King 2009). Laptop ensemble work is also a collaborative activity focused on the creative output of music (Trueman 2007) with suggestions that it can be effective in the development of transferrable skills (Mudd 2012). Furthermore, collaboration is becoming more prominent in programming work because of a growing focus on open source software development (Myllykoski 2012), as well as the opportunities afforded through live audio coding (Sorensen 2009; Collins 2011) and social coding platforms. In computing education collaborative techniques are well established for supporting programmers in their learning (Robins et al. 2010). One technique that has received particular attention is pair programming where two students team up in regularly rotating ‘driver’ and ‘navigator’

79

David Moore

roles. The driver writes the code, whereas the navigator oversees the overall process checking for errors and guiding the implementation. It is argued that because the navigator is not directly involved in coding, he or she holds a more objective point of view and think more strategically about the direction of the work. Research also indicates other benefits for learning programming in pairs. Quantitative studies have shown that students are more confident in the correctness of their programming solutions than when working alone (Braught et al. 2011) and that the quality of programs produced by pairs is generally higher (McDowell et al. 2003). J. Carver and L. Henderson (2007) found that students agreed that they learnt more when working with a partner than without with the students suggesting that the process of explaining their coursework to another person was useful. Although the authors do not allude to why this might be, cognitive science research shows that the act of verbalizing something can improve understanding and help in the refinement of mental models (Ainsworth and Th Loizou 2003). Other studies have highlighted that pair programming can bring about increased enjoyment in programming and that ‘Pair programming affords the opportunity for increased socialisation, improved comprehension and immediate help and support’ (Liebenberg et al. 2012). There is also some evidence to suggest that students working in pairs are better able to problem-solve and are able to refine and expand their mental models that are vital to becoming better programmers (Hanks et al. 2011). Pair programming has also been shown to benefit teaching staff in terms of efficiency as less grading is required and there is more emphasis on facilitating practical sessions rather than answering one-to-one questions i.e. pairs are more likely to work towards resolving programming problems together (Coleman and Nichols 2011). Of course, pairing is the simplest form of collaboration with knowledge exchange just occurring between two learners. Other forms of collaboration have been explored for programming involving different levels of interaction and group size. For instance, R. Arora and S. Goel (2012) explored a three-staged model where individual, pair and small group activities were structured around a single programming task. This model facilitated different levels of collaboration allowing some emphasis to be placed on solo work. This could be beneficial as it has been suggested that placing too much emphasis on collaborative programming early on can make the transition to solo programming later an issue in terms of confidence (Simon and Hanks 2008). However, more research is required to clarify this point as a study by N. Jacobson and S. K. Schaefer (2008) found no evidence to suggest that collaborative programming was detrimental to students’ performance in future programming endeavours. Peer code reviewing is a lighter form of collaboration. A student undertaking a code review will inspect another student’s code with the aid of a checklist outlining common programming errors. As such, some studies report that students benefit as they are exposed to other coding styles and syntax and develop important low level skills when tasked in correcting errors produced by others (Jenkins and Ademoye 2012). Although there is substantial evidence to support the case for collaboration when learning programming, the potential downsides must also be highlighted. Aside from the possible issue of partner dependence mentioned above, it will always be the case that some students prefer working alone. Also, the compatibility of pairs or groups can be an issue with personality types possibly being a contributing factor to the success or failure of a pair (Katira et al. 2004). Assessing individual contributions to collaborative assignments also needs consideration to ensure that individual contributions are fairly acknowledged

80


Figure 3: Kolb’s experiential learning cycle. (Hahn et al. 2009). However, taken together, the literature provides some evidence that collaborative learning is beneficial for novice programmers. It can encourage students to reflect on their experiences through the processes of interaction and peer review (Søndergaard and Mulder 2012) and can aid in the development of mental models of key programming constructs.

Reflection Reflection is an important aspect of learning. It allows us to examine and analyse our own experiences and ultimately learn from them. In D. A. Kolb’s experiential learning model (Kolb 1984) the learner begins a cyclical process passing though the stages of Concrete Experience, Reflective Observation, Abstract Conceptualizing, and Active Experimentation (see Figure 3). Although this is a simplification of a complex activity, it outlines how reflection features as a key part of the learning process, which allows us to develop, build upon and in some cases change our behaviour and practice. Activities involving reflection encourage more critical and analytical thinking and can help embed a deeper approach to learning and promote independent thought (Hinett 2002). In terms of supporting learners of programming, promising results have been seen in computing education when encouraging regular reflection on activities. S. E. George (2002) argues that keeping a reflective learning journal can encourage deeper learning and stimulate good software development practices. They present qualitative data that demonstrates that students benefited from the process of articulating steps involved in problem-solving in programming. However, the authors also state that there were some students that could not see the benefit in keeping a journal and found it a hindrance to their learning of programming. H. T. Lin and S. M. Yuan (2006) found that encouraging students to reflect on their experiences in a blog had a positive bearing on their programming. Students who reflected regularly on their work had better overall module performance. In the context of music learning, blogging has also been shown to be an activity that can encourage students to be more self reflective helping develop metacomprehension – an awareness of one’s own understanding (Chong 2010).

Design and methodology Primary research was carried out at Glasgow Caledonian University with B.Sc. Audio Technology students undertaking a twelve-week audio processing module. In this module students learn to develop their own Max objects for

81

David Moore

audio processing and effects using Java and mxj/mxj~. Although the students have had experience of Max programming, they have not coded in a lower level text-based language before. In the previous year on the module students were given individual exercises to complete during practical sessions. However, the author noticed that some students struggled with the initial mental leap required when learning a new programming language and when putting theory into practice. There was some evidence of rote learning, and the author observed both stoppers and movers. Towards the end of the module, students started naturally collaborating on the lab tasks so the author decided to explore methods for supporting novice programmers and for formalizing the collaboration observed. Having developed a reasoned argument for implementing collaborative and reflective techniques on the module the author developed new learning activities involving reflective writing in an individual learning journal and pair programming. The two questions to be addressed in this research were: 1. How can collaborative learning methods be designed and delivered to students to result in greater mastery and increased confidence in audio programming? 2. Is a reflective learning journal an effective learning aid for audio programming, and can it be used to successfully complement collaborative learning? When designing the pairing activities a taxonomy of collaborative learning by J. Salmons (2008) was employed, which describes the different levels of collaboration that can be employed with reference to learning activity and trust between collaborators (paraphrased in Figure 4). The levels of collaboration range from dialogue tasks requiring low levels of trust and collaboration, to synergistic tasks that involve high levels of trust and collaboration. Parallel collaboration and synergistic collaboration were used in this research. It could be argued that parallel collaboration is in direct conflict with the driver/navigator procedure of pair programming. However, it was decided

Figure 4: Taxonomy of collaborative learning from Salmons (2008).

82


that including it could help build confidence in solo programming as well as individual problem-solving. As highlighted earlier, too much emphasis on pair programming could be problematic when students later come to program on their own. Also, using two different approaches would vary the activities for the students and hopefully help sustain interest over the module – variability is a key element to maintaining motivation (Keller 1987). All of the new programming exercises were designed to be subject relevant as it has been highlighted by Forte and Guzdial (2005), having domain-specific programming exercises is particularly important for those whose major focus of study is not programming. Activities included ill-structured programs that students had to fix, problem-based exercises and creative exercises. An example of an early exercise involved students working together to create an mxj~ object for the ring modulation of two signals (i.e. synergistic task). Although ring modulation was an algorithm that students were already familiar with from their work in an earlier module using Max, the author found it to be a good exercise to introduce audio processing loops as they could obtain audio output quickly and relatively easily building positive expectation for success early in the module. Later in the module students developed objects using the synergistic and parallel approaches for more sophisticated audio processing, including delay-based effects. Pair programming guidelines by Williams et al. (2008) were followed in the practical sessions. The guidelines were outlined in the first week and students were given a tutorial exercise that encouraged discussion and reflection on them. This was important as G. Schraw et al. (2006) observe that collaborative learning works especially well when students have been explicitly taught how to collaborate, a point echoed by Kramarski and Mevarech (2003). At first students were assigned partners randomly, then from week 5 they were asked to choose a regular working partner in preparation for coursework. By randomizing partners students would be exposed to different classmates and working styles. New assessments were designed to match the collaborative nature of the module. A formative pair programming assignment was set early in the module so that students could gain detailed feedback on their solution to a programming problem before attempting the summative work. The formative assessment also gave pairs the opportunity to refine their working relationships before summative coursework. For the summative work, two relatively short (threeweek) pair programming projects were given. The first was synergistic in nature involving the creation of a universal comb filter object for implementing timebased audio effects such as vibrato, flanger and chorus through the manipulation of the comb filter parameters. The second project was parallel in nature involving the creation of a first order Ambisonic encoder and decoder. Students worked on the encoder and decoder separately then were asked to combine and refine their efforts as a pair. In both projects, they were encouraged to explore the creative potential of the objects they had developed by including a separate demonstration patch with their submissions. Students were provided with a detailed marks rubric and were asked to agree self and peer marks that were used as a weighting to derive individual marks for the main coursework tasks. To support students in the process of pair programming, the Blackboard Virtual Learning Environment (VLE) was configured so that each pair could collaborate online as well as in the lab. This was important because formal lab time was limited (three hours per week). Online management of the pairs was useful as tutors could monitor students. In future, however, the author plans to investigate other systems like GitHub as they are more geared towards dealing with collaborative/social coding, and are widely used in industry. Using

83

David Moore

such as system would also give students the added opportunity to develop skills in version control. To encourage reflection, and hopefully promote deeper learning, students were asked to keep an individual learning journal to reflect on their weekly work and log information about any programming problems they had encountered and methods they took to resolve them. The assessment requirement for the journal was one post per week focusing on the previous week’s work. A minimum word count of 250 words was set, however this was often far exceeded. The journal was configured as a private blog through the VLE. Students were provided with a guidance document on reflection and were given feedback on early posts plus face-to-face feedback about their code in labs, as well as their use of driver and navigator roles. They were also encouraged to give peer feedback after finishing a lab with a partner although no formal system was put in place to support this. To evaluate the impact of the new collaborative and reflective learning activities, a data-gathering instrument was developed for measuring attitudes towards audio programming. The instrument is based on the widely used Fennema-Sherman Mathematics Attitude Scale (Fennema and Sherman 1976). Although the Fennema-Sherman instrument was originally designed to measure attitudes to mathematics, it has been applied in other areas with success, including computer science for measuring attitudes towards programming (Williams et al. 2002). The instrument consists of nine different subscales each with twelve items measuring different criteria. The subscales can be used together or individually. In this work, only four relevant subscales were used to help answer the research questions i.e. • Confidence in learning programming. This can determine how confident a student is of his or her overall ability in audio programming. • Attitudes towards success in audio programming. This looks at the degree to which students anticipate positive or negative consequences as a result of success in programming. Learners are more likely to be engaged in something if they think they are likely to succeed. • Perceived usefulness of audio programming. This is designed to examine how students view the usefulness of audio programming. If they feel it is useful in their current education and future careers then they would perhaps be more motivated to succeed. • Motivation towards audio programming. This is designed to measure Effectance Motivation that outlines our intrinsic drive to work towards competence and to successfully produce an effect on our environment (White 1959). Some refer to it as ‘competence motivation’ or ‘mastery motivation’ as it highlights that with success or competence in mastery attempts, one gains a feeling of self-efficacy that helps to increase or maintain motivation (Harter 1978). Each subscale consists of a series of positive and negative statements for which students were asked to respond using a five-point Likert scale ranging from strongly disagree to strongly agree. The reliability of the subscales was evaluated for internal consistency using Cronbach’s α (Norton 2009). All values of Cronbach’s α were in an acceptable range (>=0.7) and were in broad agreement with values observed in other research (Williams et al. 2002). The instrument was distributed to the same group of fourteen students pre- and post-module. The need for honesty was stressed and students were informed

84


Figure 5: Results from the instrument subscales. that strict confidentiality would be maintained. The negative items were reverse coded before calculating the subscale scores (Norton 2009). Having a control group would have been preferable, however having developed a reasoned argument for the benefits of the new learning activities through secondary research, it was decided that this would not be appropriate. A focus group was also conducted with six students post-module to explore specifics in more detail. Although mindful of the so-called ‘experimenter effect’ and associated problems (e.g. bias) (Norton 2009), the author decided to run the focus group to allow detailed follow up to any specific points if needed allowing for a richer set of data to be gathered. As a final form of analysis, the impact of the learning journal was measured using a correlation method. The following sections present the findings, and afterwards the implications of the findings are discussed.

Findings The results from the audio programming instrument were interpreted by comparing the means for each subscale and by using a paired two-tailed t-test for the mean differences. A summary is provided in Figure 5. The results indicate a statistically significant positive difference in confidence (p=0.040), motivation (p=0.017) and the sum of the mean differences for all subscales (p=0.040). The success and usefulness subscales were not significant. Six students took part in the focus group. The data was transcribed then thematic analysis was carried out according to the steps outlined by L. S. Norton (2009). Three major themes were revealed: collaboration, compatibility and reflection.

Collaboration and its impact on learning Comments on collaborative learning were generally positive. Students appeared to find the pair programming experience beneficial with suggestions that they felt more confident in programming, better able to problem-solve, and more capable of producing higher quality work than if working alone: If you’ve got somebody that you’re comfortable with you can bounce off them, and if you don’t understand something they can explain something to you, or you can sit and work it out together, or because you’ve got driver and navigator it’s easier to work out a problem than having to do it yourself. […] we felt that both of us pulled each other up. A good example would be the last help patches we did where I did a bit and then sent it to my partner, then he did a bit and I did another bit on it, it was really good,

85

David Moore

it was collaborative and if I had done that myself it might have been half the thing it was and vice versa. We both added our own inputs. I’d definitely say I’m more confident in programming. I’ve obviously still got issues with it, but bouncing off [x] if I had a problem he would say ‘no this is what you do’ or vice versa. So it’s better having someone that you can talk to instead of having to come to the tutor all the time and say ‘no I don’t get it’. These positive remarks mirror some of those reported in previous qualitative studies that supports the use of pair programming (Ferzli et al. 2002; Williams et al. 2002).

Compatibility of pairs Although pair programming appears to have been a useful experience for students, there was some concern over random pairing and the impact on compatibility: [random pairing] may be a bit intimidating for some people though, there are folk in the class that aren’t as confident or loud and if paired up with someone who is they might feel a bit intimidated. Compatibility is an important issue in collaborative work. In pair programming N. Katira et al. (2004) suggest that 90 per cent of students randomly assigned are compatible. However, they report that perceived technical competence of partners and personality can play an important role. Interestingly they found that students with opposing personality types (according to a Myers-Briggs test) were more compatible. Further remarks were made on the potential benefits of pairing randomly, with one student relating it employability: […] you weren’t just with your friend, you might have worked with someone you don’t usually talk to in the class or someone that doesn’t know anything whatsoever, or some people who really know what they’re doing, so I think it was good that way. I suppose as well if you’re going to work with people you don’t always know them so you have to get used to being just flung in a room with someone and sat at the table. […] you might find out that your strengths are actually their weaknesses and you could pair up together. And that I suppose that’s kind of good from that way.

Reflection and its impact on learning Overall, students appeared to find the weekly process of reflecting on audio programming very useful. It gave you a chance to go over the stuff that we’d obviously learned that week ... and it kind of sinks in a bit because we’re having to write it in our own words. There’s always things that when you come out of a lecture that you’ve taken in x amount until you look back over it and you realise that well there’s something else.

86


Figure 6: Correlation between number of reflections and performance. when you actually vocalise something you learn more from the process of saying it out loud so it’s sort of like that. I think by just having freedom to write about anything you would write more, and it would be in more detail. One student remarked that this activity also enhanced confidence. In a report for the Higher Education Academy, K. Hinett states that ‘Expressing reflection means finding a “voice” by which to express thoughts and inevitably this increases confidence and self-awareness in ability’ (2002). Findings by Grant et al. (2006) support this but more research is required to investigate this in the domain of audio programming. It’s definitely good for confidence boosting as well, like for somebody who’s not as confident at programming (like me) telling themselves every week, ‘I picked this up this week’ it makes you feel better about yourself and makes you feel I can do this instead of thinking god I’m bad at this. To further investigate the impact of the learning journal a Pearson’s correlation test was undertaken to see if there was a relationship between the number of times students reflected, and the mark for their pair programming projects. Figure 6 indicates that there was a significant positive correlation between these parameters suggesting that frequently posting to a learning journal can have a positive impact when learning programming.

Discussion The findings reported suggest that the collaborative and reflective learning activities helped contribute to building more competent programmers who are more confident and motivated. The first research question asked whether collaborative learning exercises would result in increased confidence and mastery in audio programming. The positive remarks from the focus group and the significant difference between pre- and post-module confidence levels for the attitudes survey indicate that this is the case. This finding agrees with literature

87

David Moore

highlighting that pair programming can increase confidence levels of novice programmers (Hanks et al. 2011). However, the author is cautious not to overstate the results given the relatively low number of participants in the study. In terms of mastery, it is difficult to say with any certainty whether the collaborative learning activities had more of an impact than individual exercises used in the past. However, the author’s own observations suggest they have. Pair programming helped to promote a much more social and active learning environment where students were better able to support each other. Furthermore, there was a higher level of cross collaboration between students and the cognitive load was shared between two students helping them manage more advanced tasks. The author noted that they were attempting much more sophisticated programming than in the previous years and the overall coursework mark and attendance on the module was improved when compared to the previous year’s cohort (+8 per cent and 13 per cent, respectively). The effectance motivation subscale also suggests that students had higher levels of self-efficacy post-module, which is an indication that they perceived they were becoming more competent in programming. The survey also investigated perceived usefulness and attitudes towards success in audio programming. Although no significant difference was found for either, a very high overall subscale value for usefulness suggests that students see audio programming as relevant and potentially useful for their future careers. For some, this perhaps could have been an extrinsically motivating factor (Ryan and Deci 2000). Overall, the results from the attitudes survey contrast with those by L. Williams et al. (2002) who reported no significant differences preand post-module for the subscales. This finding could be interpreted as reflecting the different requirements and mindset of music technology students when approaching programming when compared to computer science students. Collaboration is perhaps a more natural process to the former given that such students are often involved in collaborative music performance and studio work. However, this would need to be explored in more detail. The inclusion of the reflective writing exercises may also have impacted the survey positively. The second research question asked whether an individual reflective learning journal would be a useful aid for novice audio programmers. Comments from the focus group support the case that regular reflection on programming practice is effective. Students found the process of documenting their weekly work in a blog beneficial and that the act of explaining it in their own words helped them better understand it. Each week many students exceeded the minimum word count and there was direct evidence of deep learning because of the enthusiasm and detail in their posts. Some expressed that having the freedom to write about their experiences in a less formal way (i.e. when compared with a report), would lead them to write in more detail. A range of topics were covered by students in their blogs, including reflection on programming constructs, practical exercises and coursework. The most common post, however, was on errors encountered and steps taken to resolve them. This was encouraging as students could revisit their work if encountering similar programming issues. Interestingly, students also reflected on their collaborative experiences. It appeared to help some students recognize their own working strengths and weaknesses when in a pair and devise strategies for improving them in future practical sessions. This suggests that reflective journaling can complement collaborative work. A positive correlation between the number of blog posts and average programming marks suggests that the blogging exercise improved achievement on the module. This finding is in agreement with the work of Lin 88


and Yuan (2006). However, although this result suggests the number of times a student reflects can be significant, it is not clear whether this is a causal relationship so further research is required to unpack in more detail the specific impact that reflective writing can have on learning programming in a music technology context. The depth of refection and its potential impact on learning also requires further exploration. Others considering using a journal may find it worthwhile investigating an ‘open’ blog system. Although such a system was not explored in this project, the ability to cross comment could potentially encourage even greater interaction between members of the class. However, perhaps this could also deter some students who may view a learning journal as a personal piece of work so using a closed blog may lead to a deeper level of reflective content that may not be present in an open system.

Conclusions This article examined methods for supporting and enhancing learning of programming in a music technology context. Collaborative learning in the form of pair programming was employed in practical sessions on an audio programming module. The results from an attitudes survey and a focus group indicate that the paired activities were successful in supporting students in their learning with evidence to suggest increased confidence and motivation. Increased engagement was also observed by the tutor as a result of the interventions with practical sessions being much more active with evidence of deeper learning of the module content and the development of transferable skills including: Communication, Personal, Interpersonal and ProblemSolving (Jeffcote 1995) skills. There was also less focus on the tutor, and marking was less time consuming meaning that results and feedback could be delivered to students more quickly than before. Reflective writing was investigated as a means of supporting student learners in their programming and as a method of promoting deeper learning of programming concepts. Students were required to keep a weekly journal using a blog. Results from a focus group and correlation analysis between the performance and reflection frequency indicate a positive outcome, although further research is required to explore this in more detail. Furthermore, the tutor found the process of reflecting on student blogs throughout the module useful. Programming problems or misunderstandings could quickly be identified allowing rapid intervention. The results from this project have led to several ideas for future work, including exploring co-creativity in audio programming and systems for supporting online collaboration of programming.

References Ainsworth, S. and Th Loizou, A. (2003), ‘The effects of self-explaining when learning with text or diagrams’, Cognitive Science, 27: 4, pp. 669–81. Arora, R. and Goel, S. (2012), ‘Learning to write programs with others: Collaborative quadruple programming’, in Software Engineering Education and Training (CSEE&T), 2012 IEEE 25th Conference on Software Engineering Education and Training, |Nanjing: IEEE Computer Society, pp. 32–41. Du Boulay, B. (1986), ‘Some difficulties of learning to program’, Journal of Educational Computing Research, 2: 1, pp. 57–73. Braught, G., Wahls, T. and Eby, L. M. (2011), ‘The case for pair programming in the computer science classroom’, ACM Transactions on Computing Education, 11: 1, pp. 1–21. 89

David Moore

Carver, J. and Henderson, L. (2007), ‘Increased retention of early computer science and software engineering students using pair programming’, in Software Engineering Education and Training (CSEET), 20th Software Engineering Education & Training (CSEET07), Dublin: IEEE, pp. 115–122. Chong, E. K. M. (2010), ‘Blogging transforming music learning and teaching: Reflections of a teacher-researcher’, Journal of Music, Technology and Education, 3: 2/3, pp. 167–81. Clarke, M. (2006), ‘From SYnthia to Calma to Sybil: Interactive learning in music’, in J. O’Donoghue (ed.), Technology Supported Learning and Teaching: A Staff Perspective, Hershey: Idea Group Inc., pp. 292–307. Coleman, S. a. and Nichols, E. (2011), ‘Embedding Inquiry based learning into programming via paired assessment’, Innovation in Teaching and Learning in Information and Computer Sciences, 10: 1, pp. 72–77. Collins, N. (2011), ‘Live coding of consequence’, Leonardo, 44: 3, pp. 207–11. Cortright, R. N., Collins, H. L., Rodenbaugh, D. W. and DiCarlo, S.E. (2003), ‘Student retention of course content is improved by collaborative-group testing’, Advanced in Physiology Education, 27: 3, pp. 102–08. Dillenbourg, P. (1999), Collaborative-Learning: Cognitive and Computational Approaches (ed. P. Dillenbourg), Bradford: Emerald Group Publishing. Fenci, H. and Scheel, K. (2005), ‘Engaging students: An examination of the effects of teaching strategies on self-efficacy and course climate in a nonmajors physics course’, Journal of College Science Teaching, 35: 1, pp. 20–25. Fennema, E. and Sherman, J.A. (1976), ‘Fennema-Sherman mathematics attitudes scales: Instruments designed to measure attitudes toward the learning of mathematics by females and malesí, Journal for Research in Mathematics Education, 7: 5, pp. 324–326. Ferzli, M., Wiebe, E. and Williams, L., (2002), Paired Programming Project: Focus Groups with Teaching Assistants and Students, http://citeseerx.ist.psu.edu/ viewdoc/download?doi=10.1.1.161.8558&rep=rep1&type=pdf. Accessed 1 June 2013. Forte, A. and Guzdial, M. (2005), ‘Motivation and nonmajors in computer science: Identifying discrete audiences for introductory coursesí, IEEE Transactions on Education, 48: 2, pp. 248–253. George, S. E. (2002), ‘Learning and the reflective journal in computer science’, Journal Australian Computer Science Communications, 24: 1, pp. 77–86. Gokhale, A. A. (1995), ‘Collaborative learning enhances critical thinking’, Journal of Technology Education, 7: 1, pp. 22–30. Grant, A., Kinnersley, P., Metcalf, E., Pill, R. and Houston, H. (2006), ‘Students’views of reflective learning techniques: An efficacy study at a UK medical school’, Medical Education, 40: 4, pp. 379–388. Hahn, J. H., Mentz, E. and Meyer, L. (2009), ‘Assessment strategies for pair programming’, Journal of Information Technology Education, 8: 1, pp. 273–84. Hanks, B., Fitzgerald, S., McCauley, R., Murphy, L. and Zander, C. (2011), ‘Pair programming in education: A literature review’, Computer Science Education, 21: 2, pp. 135–73. Harter, S. (1978), ‘Effectance Motivation Reconsidered. Toward a Developmental Model’, Human Development, 21: 1, pp. 34–64. Hinett, K. (2002), ‘Improving learning through reflection – part one’, The Higher Education Academy, http://www-new1.heacademy.ac.uk/assets/ Documents/resources/database/id485_improving_learning_part_one.pdf. Accessed 28 May 2013. Jacobson, N. and Schaefer, S. K. (2008), ‘Pair programming in CS1: Overcoming objections to its adoption’, SIGCSE Bull, 40: 2, pp. 93–96. 90


Jeffcote, R. (1995), ‘Transferable skills and affective learning outcomes’, Capability, 1: 4, pp. 49–53. Jenkins, G. L. and Ademoye, O. (2012), ‘Can individual code reviews improve solo programmming on an introductory course?’, ITALICS, 11: 1, pp. 71–79. Jones, C. and King, A. (2009), ‘Peer learning in the music studio’, Journal of Music, Technology & Education, 2: 1, pp. 55–70. Katira, N., Williams, L., Wiebe, E., Miller, C., Balik, S. and Gehringer, E. (2004), ‘On understanding compatibility of student pair programmers’, in Proceedings of the 35th SIGCSE Technical symposium on Computer Science Education (SIGCSE 2004), Norfolk, Virginia: ACM, p. 7. Keller, J. (1987), ‘Development and use of the ARCS model of instructional design’, Journal of Instructional Development, 10: 3, pp. 2–10. King, A. (2008), ‘Collaborative learning in the music studio’, Music Education Research, 10: 3, pp. 423–38. Kolb, D. A. (1984), Experiential Learning: Experience as the Source of Learning and Development, Englewood Cliffs, New Jersey: Prentice Hall. Kramarski, B. and Mevarech, Z. R. (2003), ‘Enhancing mathematical reasoning in the classroom: Effects of cooperative learning and metacognitive training’, American Educational Research Journal, 40: 1, pp. 281–310. Leese, M. (2010), ‘Bridging the gap: Supporting student transitions into higher educationí, Journal of Further and Higher Education, 34: 2, pp. 239–251. Liebenberg, J., Mentz, E. and Breed, B. (2012), ‘Pair programming and secondary school girls’ enjoyment of programming and the subject Information Technology (IT )’, Computer Science Education, 22: 3, pp. 219–36. Lin, H. T. and Yuan, S. M. (2006), ‘Taking blog as a platform of learning reflective journal’, in W. Liu, Q. Li, and R.W.H. Lau (eds), Lecture Notes in Computer Science, Heidelberg: Springer, pp. 38–47. McDowell, C., Werner, L., Bullock, H. E. and Fernald, J. (2003), ‘The impact of pair programming on student performance, perception and persistence’, in Proceedings of 25th International Conference on Software Engineering, Washington: IEEE Computer Society, pp. 602–07. Mudd, T. (2012), ‘Developing transferable skills through engagement with higher education laptop ensembles’, Journal of Music, Technology & Education, 5: 1, pp. 29–41. Myllykoski, M. (2012), ‘Open-source software projects in music education: Stakeholders, structure and the development cycle’, Journal of Music, Technology & Education, 5: 2, pp. 159–70. Norton, L. S. (2009), Action Research in Teaching and Learning: A Practical Guide to Conducting Pedagogical Research in Universities, Oxford: Routledge. Perkins, D., Hancock, C., Hobbs, R., Martin, F. and Simmons, R. (1986), ‘Conditions of Learning in Novice Programmers’, Journal of Educational Computing Research, 2: 1, pp. 37–55. Robins, A., Rountree, J. and Rountree, N. (2010), ‘Learning and teaching programming: A review and discussion’, Computer Science Education, 13: 2, pp. 137–72. Ryan, R. M. and Deci, E. L. (2000), ‘Intrinsic and Extrinsic Motivations: Classic Definitions and New Directionsí, Contemporary educational psychology, 25: 1, pp. 54–67. Salmons, J. (2008), ‘Expect originality! Using taxonomies to structure assignments that support original work’, in Student Plagiarism in an Online World: Problems and Solutions, IGI Global USA: Information Science Reference, pp. 208–27. 91

David Moore

Schraw, G., Crippen, K. J. and Hartley, K. (2006), ‘Promoting self-regulation in science education: Metacognition as part of a broader perspective on learning’, Research in Science Education, 36: 1–2, pp. 111–39. Simon, B. and Hanks, B. (2008), ‘First-year students’ impressions of pair programming in CS1’, Journal on Educational Resources in Computing, 7: 4, pp. 73–86. Smith, D. C., Cypher, A. and Tesler, L. (2000), ‘Programming by example: Novice programming comes of age’, Commun. ACM, 43: 3, pp. 75–81. Søndergaard, H. and Mulder, R. A. (2012), ‘Collaborative learning through formative peer review: Pedagogy, programs and potential’, Computer Science Education, 22: 4, pp. 343–67. Sorensen, A. (2009), ‘Impromptu: An interactive programming environment for composition and performance’, in Sorensen, A. (eds), Proceedings of the Australasian Computer Music Conference, Victoria: Australasian Computer Music Association, pp. 2–4. Thousand, J. S., Villa, R. A. and Nevin, A. I. (2002), Creativity and Collaborative Learning: The Practical Guide to Empowering Students, Teachers, and Families, Baltimore: Paul H. Brookes Publishing Company. Trueman, D. (2007), ‘Why a laptop orchestra?’, Organised Sound, 12: 02, p. 171. Vygotsky, L. S. (1986), Thought and Language – Revised Edition, rev. ed., Cambridge: The MIT Press. White, R. W. (1959), ‘Motivation reconsidered: The concept of competence’, Psychological Review, 66: 5, pp. 297–333. Williams, L., Wiebe, E., Yang, K., Ferzli, M. and Millar, C. (2002), ‘In support of pair programming in the introductory computer science course’, Computer Science Education, 12: 3, pp. 197–212. Williams, L., McCrickard, S., Layman, L. and Hussein, K. (2008), ‘Eleven Guidelines for Implementing Pair Programming in the Classroom’, in Agile 2008 Conference, Washington: IEEE Computer Society, pp. 445–452. Wingate, U. (2007), ‘A Framework for Transition: Supporting “Learning to Learn” in Higher Education’, Higher Education Quarterly, 61: 3, pp. 391–405.

Suggested citation Moore, D. (2014), ‘Supporting students in music technology higher education to learn computer programming’, Journal of Music, Technology & Education 7: 1, pp. 75–92, doi: 10.1386/jmte.7.1.75_1

Contributor details David Moore is an Audio Technology Lecturer at Glasgow Caledonian University. He commenced this post in 2009 after completing his Ph.D. thesis at the University of Huddersfield. His main teaching and research areas include: Audio Processing and Synthesis, Spatial Sound, Studio and Concert Hall Recording, and High Performance Audio Computing. He is director of the AudioLab research group and is a committee member for the Audio Engineering Society Scottish Section. Contact: Department of Computing, Communications and Interactive Systems, Glasgow Caledonian University, Glasgow, G4 0BA, UK. E-mail: [email protected] David Moore has asserted his right under the Copyright, Designs and Patents Act, 1988, to be identified as the author of this work in the format that was submitted to Intellect Ltd.

92