Can Pairworking 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 peers
  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_at_sunderland.ac.uk

34
Discussion

• Could pair-working be useful within your module?