Can Pair-working Improve the Student Learning Experience?

1. Can Pair-working Improve the Student Learning Experience? Liz Gandy School of Computing & Technology

2. Objectives • Demonstrate how teaching, research and reach-out can be integrated. • Describe a case study into the use of pair-working in the specific field of introductory computer programming. • Generate discussion on the possible application of pair-working for students on any practical or problem-solving module.

3. The History • Teaching Introductory Programming module. • Reach-out via a TCS Scheme with Engica Technology Systems International Ltd. • Research into eXtreme Programming, a software engineering approach which includes "pair programming". • Is there a way by which these can be linked?

4. The Problem • Attendance - particularly at tutorial sessions. • Confidence - Programming is a difficult topic to grasp at level 1 and many students are easily be put off. • Enjoyment - if students find the module enjoyable then their whole learning experience will be improved. • These factors all contribute to low retention & progression rates.

5. What is Pair Programming? "Two programmers working together generate more code, and better code, than the same two programmers working separately. They can work longer without getting tired, and when they're finished, two people understand everything, instead of understanding just half of everything." [Jeffries et al. (2001)]

6. Existing Research • The Effects of “Pair-Pressure” and “Pair-Learning” on Software Engineering Education. [Williams and Kessler (2000)] • Strengthening the Case for Pair-programming. [Williams et al. (2000)] • In Support of Student Pair-programming. [Williams and Upchurch (2001)]

7. Related Research • Supplemental Instruction - Surgery/workshop sessions provided by students at higher levels. • Kingston University, initially in Computing, Electronics & Engineering. • UCL, Law and Maths • University of Central Lancashire, in Law. • Manchester & UMIST, Chemistry.

8. Aims of Pair Programming • To improve attendance by making tutorials more interesting. • To improve students' confidence. By working together they will hopefully encourage and support each other. • To prepare students for industry. • To improve attendance by giving some responsibility for their own and their peer’s learning.

9. Chosen Group • HND Computing Level 1 • COH106 Software Development (C++ programming) • Module Format • 2 hour Lecture • 1½ hour lab-based Tutorial • 27 Registered students (of these 19 effective participants)

10. Structure of the Trial • Pair-working would be carried out in lab-based Tutorials. • Each pair would be allocated a single computer. • Pair-working would comprise completion of design and programming exercises. • All students would work in pairs to provide equivalent learning experience. • All assessment would be individual.

11. Allocation of Pairs • Pairs allocated by the module leader • Newly arrived L1 students who have not yet formed lasting friendships. • Would enable students to get to know each other. • Comparable to industry. • Pairs changed every 5-8 weeks • Experience with different partners. • Reduce risk of weak students struggling together for the whole year. • This was monitored and adjusted in response to student feedback.

12. Monitoring • Attendance & Results. • Written Questionnaires completed by students. • After week 5 when first pair change occurred. • Week 18. • Observation of pairs as they worked in Tutorial sessions. • External observation by University Learning & Teaching Development Co-ordinator (week 20). • Individual taped interviews towards the end of the module.

13. Attendance

14. Final Results

15. Questionaire

16. Questionnaire(cont.) Following the week 18 questionnaire, those students who wished to remain with their current partner were permitted to do so.

17. Reasons forchanging partner • Get to know other people. • It gives us a chance to share our knowledge with others now that we understand the basics. • Get used to change of partners as in industry • Partners become too static. • It will give me another person's opinion on how things should be done. • Because my partner never turned up, but I got to work with other people which helped me.

18. Reasons forkeeping partner • I had just got used to the way my partner worked. • I felt I had a good partner and may suffer with someone less dedicated to success. • Means having to learn partners skills and starting from scratch. • Just getting to know each others style of C++. • You get used to each other, for example the way each other work. • Work well & get on well with current partner.

19. Good thingsabout current pair • Helps me understand C++ better. Explains things more clearly. • I found that I spent most of my time explaining what I was doing to my partner and this helped me to understand the topics better. • Talking about exercises, solutions etc. • See more than one point of view when programming. If one person is stuck then the other may be able to help. • While writing programming code, the one who wasn't typing was able to point out any mistakes being made. • Allowed information to be shared and so new skills were learned. • My partner has previous experience of C++ programming. • You can help each other, if someone forgets something the other person may remember.

20. Not so good things about current pair • Works too fast sometimes. Hard to keep up and understand sometimes. • Partner didn't particularly understand anything from the start. I felt I was working by myself half the time due to this as they gave very little input. • One person possibly taking over and not allowing the other time to learn. Or one person lacking in sufficient motivation. • Sharing the work out. Often I work a lot quicker than other people in the group so have to slow down but don't mind helping or explaining items to my pair. • On some occasions I was slowed down having to explain things to the partner. • My partner uses C++ commands that I don't understand. My partner does not explain the more complex commands he uses. • People not turning up. (repeated on 3 questionnaires) • Partner is overly perky!

21. Distribution of Effort

22. Tutor Observations • High student concentration. • A lot of interaction between partners but little between different pairs. • Most students obviously completed the exercises as a pair. • A few students worked individually while their partner looked on. • Fewer questions asked of the tutor. A number of pairs showed determination to solve problems themselves and resented tutor interference! • Questions asked were more of a discussion nature than particular technical problems. • Occasional (good-humoured) arguments arose over how to complete an exercise.

23. Use of Machine • Initially students were allocated a single machine to each pair. • One pair asked if a second machine could be used as a reference to the module website/lecture notes. • This was allowed and most pairs took advantage of this approach.

24. External Observer • Delivery and pace directed by the students and so was most appropriate for their needs. • Students were all participating and engaging with the module. • Students demonstrated a level of maturity and willingness to work way beyond their level of study. • Clear evidence of student learning taking place. • Students were really learning from each other. • Students interrogated each other on very relevant topics and problems. • Obvious that real deep learning was taking place. • Students were obviously enjoying it.

25. Taped Interviews • Describe two good things about working in pairs. • Describe two problems or difficulties you have encountered while working in pairs. • Describe two ways working in pairs has helped you. • Give two examples of how you approached working together on a problem. • You were required to change partners on a regular basis. Give examples of how these changes helped or hindered your progress. • Have you learnt C++ or another programming language using a different approach? If so, what was this approach and how would you compare it to pair-programming as a method of learning programming?

26. PositiveObservations • New friendships. • Confidence boost. • Different approaches. • Understand more by explaining to others. • Relaxing approach. • Two heads better than one.

27. Difficulties • Attendance of partner. • Different levels of experience. • Can make you lazy and rely on others. • Disagreements (not necessarily a bad thing). • Speed of progress of partner.

28. Approaches • Bouncing ideas off each other until a solution is reached. • Taking turns to code and offer advice. • Debate on best solution. • One person does pseudocode design, the other codes. • Division of labour for speed. • Division of labour to make progress.

29. Comparison • Most students cited Visual Basic as another programming language. • Visual Basic is taught on their programme using the traditional individual tutorial approach. • Of the 7 students interviewed: • 5 stated preference for pair programming. • 2 did not express a preference.

30. Conclusions • Lecture attendance and results have improved. (Data for Tutorial attendance was not reliable). • No conclusive proof that this can be attributed solely to pair programming. • Student feedback indicates that: • Their confidence has increased. • They have enjoyed pair programming. • They have developed new friendships. • They have gained skills that will be useful in future careers. • Tutor feedback indicates that: • Both strong and weaker students can gain benefit from each other. • Pair programming encourages student-centred learning.

31. Potential Dangers • Non-attendance of a partner. • Some students may be inclined to sit back and let their partner do all the work. • The pairing of a particularly strong student with a particularly weak student can lead to frustration on both sides. • Students of differing abilities can work well provided the difference is not too great.

32. The Future • Analyse the results in more detail. • Extend the trial to cover the degree version of Software Development (COM168) which has approximately 100 students. • Put in place procedures to automate the allocation of partners, vital for a larger group. • Continue to monitor progress and obtain more reliable results from a larger group size.

33. Contact Details • Slides and references will be made available from homepage: http://osiris.sund.ac.uk/~cs0ega/welcome.html • Email address: liz.gandy@sunderland.ac.uk

34. Discussion Could pair-working be useful within your module?