Can Pairworking Improve the Student Learning Experience - PowerPoint PPT Presentation

1 / 34
About This Presentation
Title:

Can Pairworking Improve the Student Learning Experience

Description:

Demonstrate how teaching, research and reach-out can be integrated. ... Partner is overly perky! University of Sunderland. University Conference - 19 June 2002 ... – PowerPoint PPT presentation

Number of Views:110
Avg rating:3.0/5.0
Slides: 35
Provided by: lizg9
Category:

less

Transcript and Presenter's Notes

Title: 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?
Write a Comment
User Comments (0)
About PowerShow.com