1

Perceptions by young people of Pair Programming when learning text languages

James Peter Franklin

MA in Computing in Education, King’s College London

August 2015

2

Abstract

This study investigated the perceptions of Key Stage 3 students when pair programming in four after

school sessions. It also aimed to establish the most effective way in which pairs could be

constructed.

Students learnt how to program with a text language using pair programming. Students were paired

with partners of similar or differing abilities in each session.

A mixed-methods approach was undertaken making use of questionnaire and interview data along

with observations and test results. This study introduced the use of a clock to help students know

when to change the partner in control, along with the use of a two keyboard setup.

Results from attitudinal survey questions determined that students enjoy pair programming and

would like to do it again. Where students are partnered with someone they perceive to have similar

ability to themselves, they enjoy sessions more and perceive their partnerships to be more

successful. Pairs with differing abilities will only work where the two partners have strong

friendships and request to work with each other.

The majority of students liked the use of a clock and felt that it contributed to fairness and resolving

pair conflict. Students also enjoyed the use of two keyboards with more collaborative behaviours

being observed.

This study finds that students perceive similar ability partners to be preferable as they are able to

assist best with debugging computer programs; a unique difficulty for novice programmers.

The outcomes of this study improve our knowledge of pair programming with secondary aged

students, leading to the recommendation that pair programming be utilised in the teaching of

programming of text languages. Pairs are recommended to be constructed from similar ability

students or friends. A timer should be used to allow equal time for each student with a two

keyboard setup being preferable.

3

Table of contents

Chapter 1 - Introduction ................................................................................. 8

1.1 Background, context and rationale ............................................................................................... 8

1.2 Purpose of the study ..................................................................................................................... 9

1.3 Aims and research questions ...................................................................................................... 10

1.3.1 Scope .................................................................................................................................... 10

1.4 Structure of the study ................................................................................................................. 11

Chapter 2 - Literature Review ...................................................................... 13

2.1 Outline of the Literature Review ................................................................................................ 13

2.2 Collaborative learning – A Theoretical Basis for Pair Programming ........................................... 13

2.3 Pair Programming – What is it? .................................................................................................. 16

2.4 Effectiveness of Pair Programming ............................................................................................. 18

2.5 Perceptions of Participants in Pair Programming ....................................................................... 19

2.6 Criteria for Pair Compatibility ..................................................................................................... 22

2.7 Summary ..................................................................................................................................... 25

Chapter 3 - Methodology ............................................................................. 26

3.1 Outline of the Methodology ....................................................................................................... 26

3.2 Approach ..................................................................................................................................... 26

3.2.1 Instruments deployed .......................................................................................................... 27

3.2.2 Overview of the data ........................................................................................................... 29

3.2.1 The method of teaching Pair Programming deployed and overview of study .................... 30

3.2.2 Teaching materials ............................................................................................................... 33

3.3 Data Collection Instruments ....................................................................................................... 33

3.3.1 Tests ..................................................................................................................................... 33

3.3.2 Questionnaires ..................................................................................................................... 34

3.3.3 Observation and programming code ................................................................................... 36

4

3.3.4 Semi-structured interviews .................................................................................................. 36

3.4 Ethical Considerations ................................................................................................................. 38

3.5 Sampling ...................................................................................................................................... 39

3.6 Limitations, Validity and Reliability ............................................................................................. 40

3.7 Summary ..................................................................................................................................... 41

Chapter 4 - Results and findings ................................................................... 42

4.1 Outline of chapter ....................................................................................................................... 42

4.2 Findings ....................................................................................................................................... 42

4.2.1 Perceptions towards the method of Pair Programming ...................................................... 42

4.2.2 Perceptions of pairing combinations ................................................................................... 47

4.2.3 Pair Programming as a social constructivist method ........................................................... 52

4.2.4 Progress of students in Pair Programming .......................................................................... 55

4.3 Summary of Findings ................................................................................................................... 63

Chapter 5 - Discussion .................................................................................. 64

5.1 Outline......................................................................................................................................... 64

5.2 What are the perceptions that students in secondary education have towards Pair

Programming? ................................................................................................................................... 64

5.3 What are the most constructive ways to pair students together? ............................................. 66

5.4 Summary ..................................................................................................................................... 71

Chapter 6 - Conclusion ................................................................................. 72

6.1 Outline......................................................................................................................................... 72

6.2 Key findings ................................................................................................................................. 72

6.3 Limitations ................................................................................................................................... 74

6.4 Recommendations and Implications........................................................................................... 75

Chapter 7 - Appendices ................................................................................ 77

Appendix A – The Moodle course ..................................................................................................... 77

Appendix B – Quiz questions ............................................................................................................ 79

5

Appendix C – End of session questionnaire ...................................................................................... 90

Appendix D - End of all sessions questionnaire ................................................................................ 91

Appendix E – Student booklet for all four lessons ............................................................................ 94

Appendix F – Extension work for higher ability students ............................................................... 111

Appendix G – Slides for initial introduction presentation .............................................................. 113

Appendix H – Student and Parent Information Sheet .................................................................... 114

Appendix I – Student and Parent Consent Form ............................................................................ 116

Appendix J – Headteacher Information Sheet ................................................................................ 117

Appendix K – Sample email to all students ..................................................................................... 119

Appendix L – Code classification tree with frequency analysis ...................................................... 120

Appendix M – Codes and meanings ................................................................................................ 122

Appendix N – Interview 1 ................................................................................................................ 124

Appendix O – Interview 2................................................................................................................ 136

Appendix P – Interview 3 ................................................................................................................ 149

Appendix Q – Quiz results distributions ......................................................................................... 162

Appendix R – Raw results for pair type and success ....................................................................... 164

Appendix S – Descriptive statistics for pair success ........................................................................ 166

Chapter 8 - References ............................................................................... 167

6

Table of Figures and Tables

Figure 1 – Phases of data collection ..................................................................................................... 28

Figure 2 – Dual keyboard setup ............................................................................................................ 31

Figure 3 – Clock, programmed in Python, showing remaining time for Right partner to have control32

Figure 4 – Pair success with homogeneous pairs ................................................................................. 47

Figure 5 – Pair success with higher ability partner ............................................................................... 48

Figure 6 – Pair success with lower ability partner ................................................................................ 48

Figure 7 – Enjoyment of sessions by ability .......................................................................................... 51

Figure 8 – Responses to social constructivism indicator questions ...................................................... 53

Figure 9 – Result of changing variable for angle of a square ................................................................ 54

Figure 10 – Tasks carried out in the Navigator role .............................................................................. 55

Figure 11 – Where pairs help to overcome problems .......................................................................... 56

Figure 12 – Where pairs hinder the overcoming of problems .............................................................. 56

Table 1 – Creation of a new procedure ................................................................................................ 58

Table 2 – Customisation of a fractal algorithm ..................................................................................... 59

Table 3 – Creation of a Snow procedure............................................................................................... 60

Table 4 – Use of code found on the internet ........................................................................................ 61

Figure 13 – Use of nested IF statements .............................................................................................. 62

Figure 14 – A strategy to pair students in Pair Programming ............................................................... 75

Figure 15 - The course layout ................................................................................................................ 77

Figure 16– Example of teacher area to collect Python source code .................................................... 78

Figure 17 – Day 1 Quiz .......................................................................................................................... 79

Figure 18 – Day 2 Quiz .......................................................................................................................... 83

Figure 19 – Day 3 Quiz .......................................................................................................................... 87

Figure 20 – Day 4 Quiz .......................................................................................................................... 88

Figure 21 – Standard questions asked at the end of each session ....................................................... 90

Figure 22 – Final quiz ............................................................................................................................ 91

Figure 23 – Student booklet .................................................................................................................. 95

Figure 24 – Extension sheets .............................................................................................................. 111

Figure 25 – Initial presentation ........................................................................................................... 113

Figure 26 – Code classification tree .................................................................................................... 120

Figure 27 - Quiz 1 marks ..................................................................................................................... 162

Figure 28 - Quiz 2 marks ..................................................................................................................... 162

Figure 29 - Quiz 3 marks ..................................................................................................................... 163

7

Figure 30 - Quiz 4 marks ..................................................................................................................... 163

Table 5 - Enjoyment of sessions for different ability partners ............................................................ 166

Table 6 - Success of partnership for different ability partners ........................................................... 166

8

Chapter 1 - Introduction

1.1 Background, context and rationale

As the first person outside of the television industry to deliver the MacTaggart lecture, Eric Schmidt

(2011), the then chairman of Google Inc. was “flabbergasted” (p.1) to learn that Computer Science

and programming were no longer being taught in schools. The education sector had already shown

dissatisfaction with the ICT curriculum through a grass roots organisation “Computing At Schools”

and the publication of a Royal Society report by Furber (2012) suggested the introduction of

Computer Science in place of ICT.

As chairman of Google, Schmidt’s comments pushed the debate to the forefront and resulted in

Gove (2012) announcing at the BETT show in January 2012 that the ICT Programme of Study would

be disapplied, leading to compulsory teaching of Computer Science from September 2014. A heavy

emphasis was to be given to programming with the need for students to use “two or more

programming languages, at least one of which is textual” (DfE, 2013, p.1).Furthermore, the very first

purpose stated for the new programme of study was that of “Computational thinking” (DfE, 2013,

p.1).

This study which looks at typical first time learners of text languages at the start of secondary

education is therefore highly relevant as is its contribution to the most effective pedagogy that

teachers can employ.

Within this context, it is also necessary to take into account the current economic climate in which

school’s are facing predicted cuts of 7-12% in real-terms over the course of the next parliament

(Sibieta, 2015). Any methods which result in reduced expenditure will have a far higher chance of

implementation and adoption.

The study presented in this dissertation shows that the implementation of Pair Programming in the

secondary school classroom has major benefits for students and teachers. Not only does this result

in more engaged learners, but as a pedagogical technique it could allow schools to reduce their

expenditure. Findings are consistent with Pair Programming studies in the tertiary sector and

industry, albeit with adaptations being required for young adolescent sensibilities.

9

1.2 Purpose of the study

With it now being compulsory for all students to study a text language in Key Stage 3, it is clearly of

important to study the way in which they learn such languages. A common technique in which to

learn programming is by Pair Programming. In this technique, computer code is produced by a pair

of programmers. Typically, one programmer takes the role of Driver and writes code, whilst the

other takes the role of Navigator and reviews the code as it is entered whilst offering suggestions for

alternative ways to solve problems (Salinger & Prechelt, 2013).

Pair Programming has been widely used for programming in industry within the techniques of

Extreme Programming (XP) and Agile Programming (Wells & Williams, 2003). Whilst the idea of a

pair of programmers developing computer code was first used in 1953, it wasn’t until an influential

study into programming methods by Copline in 1995 that the technique became popular

(Phongpaibul, 2007).

In tertiary education, Pair Programming as described by Williams et al (2000) quickly showed

benefits in improving the experience of learning to program (Nagappan et al, 2003) and in producing

better quality programs with a higher course completion rate (McDowell et al, 2002). Research over

the last decade has extended these findings to look at both student perceptions of the technique

(Hanks, 2006) and also pairing combinations. Katira et al (2005), Lui & Chan (2006) and Braught et al

(2010) have shown the most productive pairings are with students who have similar abilities to their

partner. Williams et al. (2006) have shown that students also prefer such pairings.

Research in secondary education has been limited. Little is known as to how well students achieve

when Pair Programming and research into perceptions is also limited. Research by Lewis (2011)

hypothesises that pairings should be with similar ability partners; however, it does not study this

further. In secondary education Physics classes, Carter & Jones (2006) show how pairing secondary

aged students in heterogeneous (high with low) ability pairings results in more productive pairings

with no negative perceptions in the Science classroom. This effect is replicated in Biology by Saleh et

al (2005). These findings conflict with the hypothesis made for Pair Programming in younger

students by Lewis (2011) and with the findings of Lui & Chan (2006) with adult students.

There is a clear need to resolve these conflicting findings and with the introduction of a new

curriculum, studying novice programmers at the start of secondary school is the most appropriate

age group.

10

1.3 Aims and research questions

Student perceptions towards Pair Programming in young adolescents are important for a number of

reasons. It must be established what the most effective way is for them to learn programming. Given

the differences between young adolescents and adults, it is important to also study customisations

in the method of Pair Programming which make it more age appropriate. Finally, it is important to

ascertain whether students enjoy learning this way as a key element of the introduction of

Computing at this age group is to inspire Computer Scientists and Engineers of the future.

Given the limited research in Pair Programming at the secondary level and the conflicting research

into how to pair students with differing abilities, this study will focus on the effects of different

ability pairings along with student perceptions of Pair Programming. Specifically, the following

research questions will be investigated:

1. What perceptions do students in secondary education have towards Pair Programming?

2. What are the most constructive ways to pair students?

It is clear that learning how students perceive learning through Pair Programming will assist in

modifying the technique to the most appropriate for teaching in the classroom with this age group.

Furthermore, understanding the most productive pairings of students will enable clear guidance to

assist teachers with how to pair students in their classes.

1.3.1 Scope

Currently, the most likely scenario for secondary schools is that they will be teaching pupils a text

based language formally for the first time in Key stage 3. It is possible that pupils will have studied

this in a primary school, but less likely as there is not a requirement for this in the Programme of

Study for Key Stage 2.

Some children will have studied programming outside of formal education. To try and have the study

reflect as accurately as possible the typical class in the UK, the scope of investigation will be those

who are either completely new to text programming, or those who have not studied text

programming formally in school before.

11

The study needs to be time limited and as such will only attempts to gain findings for the first 4

hours of programming acquisition. These early stages have unique issues such as the need for

perfect reproduction and creation of code to conform with strict syntactic rules of text languages.

Care should therefore be taken in extrapolating the findings beyond novice programmers.

There are many aspects that can be studied regarding pairings of students. These fit into two broad

categories of personality type and ability. It is beyond the scope of a dissertation to study both of

these in depth, and as such, the most constructive student ability combinations were looked at in

depth. Personality type was not researched in this study; however, the importance of friendship in

partners was identified from interviews.

1.4 Structure of the study

This study sets out to look at the perceptions of students towards Pair Programming and the most

constructive ways to pair students together. Quantitative data would be useful for making

comparisons with other research, but for a study into perception this would be reductionist as an

approach. Gorard & Taylor (2004, p.7) suggest that “Combined approaches can be particularly useful

when the background theory for an investigation is minimal, and where one of the main purposes of

the study is to generate useable theory”. Given the lack of research with this age group, particularly

with respect to how to construct pairs, a mixed-methods approach is used in this study.

In chapter 2, a literature review is carried out to establish a theoretical basis for Pair Programming as

a Constructivist approach. Consideration is then given to Pair Programming within industry, tertiary

education and secondary education. This chapter lays out a clear basis as to why Pair Programming is

a successful method of learning. At the same time it considers the conflicting research into how to

pair students together.

Chapter 3 looks at the data collection methods employed. Quantitative data was collected through

questionnaires and test results at the end of each session. Qualitative data was obtained through

class observation, open questionnaire questions, interviews and program source code. Each of the

phases of the study feed into each other which is a key characteristic of a mixed-methods approach

(Teddlie & Yu, 2007).

12

In chapter 4 results from the study are presented and analysed. These results are interpreted in

chapter 5 with comparisons made to the existing body of research. In particular a theory as to why

certain pairings are preferable is given based on a social constructivist pedagogy.

Chapter 6 presents an overarching conclusion to the study giving answers to the research questions,

along with limitations of the study. Clear recommendations for the teaching of programming are

also presented.

13

Chapter 2 - Literature Review

2.1 Outline of the Literature Review

This literature review first looks at a theoretical basis for Pair Programming. It considers the theories

of Piaget and Vygotsky, as the underpinning for a social constructivist view of learning. Paperts

application of Piagetian pedagogy to programming is considered along with the works of Bruner.

The origins of Pair Programming are presented along with various methods which are deployed in

both industry and the education sector. A thorough consideration is given to the effectiveness of the

technique along with age related differences which are observed.

The subsequent two sections deal with the perceptions of students when Pair Programming and the

criteria for effective pairs. Given the limited research base with secondary aged children, research

will also be considered in particular from studies at university level.

The final part of the literature review justifies why further research is required in this field,

particularly with secondary aged children.

2.2 Collaborative learning – A Theoretical Basis for Pair Programming

Piaget made a significant contribution to the way in which we view the learning of children. In

particular, he considered that children learn in four distinct stages which are reached at different

ages. The most relevant of these for secondary aged children are the last three: preoperational

thought which deals with reciprocity and moral feelings; concrete operations which include logical

thought; and formal operations which include abstract thought (Piaget, 1936). The ages at which

these stages occur have been criticised, often occurring later than Piaget proposed (Shayer and

Wylam 1978). Although the stage of concrete operations should be complete by early adolescence,

Wason & Johnson-Laird (1972) showed how undergraduates still had difficulties in logical thought,

with 92% making a simple logical mistake regarding reversibility. Seigler & Ellis (1996) show that not

all children conform to the Piagetian model and will use different strategies to learn. In light of these

criticisms we must consider whether the stages are valid. Bruner (1966) and Papert (1980) felt that

the stages were the most important part of constructivism. Given their importance in applying

14

constructivist theory to information technology and programming these are views which cannot be

ignored.

In order to construct knowledge a conflict between thought and experience is required. This

disequilibrium requires an element of surprise or confusion to be induced (Wadsworth, 1978). Social

interaction and collaboration also give rise to disequilibrium. It is therefore important that the

method in which programming is learnt allows opportunities for cognitive conflict in conjunction

with peer collaboration. As such working with others is a key component in learning to program.

Piaget’s epistemology considered knowledge as “a process rather than as a state” (Piaget, 1972, p2).

Just as with a real language, ‘knowing’ how to program requires the ability to partake in the process.

Methods of assessment of programming at GCSE and A-level predominantly still use written

examination. As such, the inherent epistemology of Piaget’s theories may be somewhat at odds with

English assessment methods.

Learners are only able to solve certain tasks independently. Vygotsky (1978) showed that harder

tasks were possible to be solved “under adult guidance or in collaboration with more capable peers.”

(Vygotsky, 1978, p86). This difference in achievement was named the Zone of Proximal Development

(ZPD). This difference was not trivial, but one where an eight year old could tackle tasks and

concepts of a twelve year old with a More Knowledgeable Other (MKO) in contrast to that of a 9

year old if they developed independently (Vygotsky, 1978). This concept allows learners to work

beyond their expected Piagetian stage.

Teale (1981) shows that for speech in children, parents can be part of the ZPD. Vygotsky (1982)

concurs with this when stating that it is “adult guidance and help” p.117 which allows for harder

tasks to be solved within the ZPD. Despite this, Shayer (2003) warns that teachers are often far from

young adolescents in their development levels and often have explanations which are too advanced

to be understood.

Teachers have often interpreted the ZPD as scaffolding activities; however, Daniels (2002) states

clearly that the ZPD is not the same as scaffolding.

Social learning was fundamental to Vygotsky’s theories. Learning takes place first in the social plane

and then in both the psychological and intrapsychological planes (Vygotsky, 1981).

Both Piaget and Vygotsky subscribed to a genetic theory of psychology. Specifically the process of

developmental construction, where to understand something the learner had to understand the

process to reproduce it. (Newman et al, 1989).

15

Like Piaget, Vygotsky (1978) emphasised the importance of play in learning. Newman et al (1989)

developed the concept of the Construction Zone Activity (CZA) as a method to foster learning. They

felt that this had both Piagetian and Vygotskian components. In particular, the CZA has a component

to create cognitive conflict which requires teacher mediation. Suggested ideas for the CZA are small

group activities, talk, experimentation and whole class sharing of results or experiences.

Bruner (1979) criticised Piaget’s emphasis on logic. His theory of learning was grounded in

Information Technology and combined Piaget’s constructivism with Vygotsky’s social interaction to

create social constructivism (Wood, 1998).

Bruner developed three stages of learning which are successively progressed through. These are

enactive – learning through play, iconic – mental images and memory, and symbolic – abstract ideas

and critical thinking. The More Knowledgeable Other (MKO) is seen as fundamental with the

teacher’s role one of scaffolding the activity. Bruner felt that the three stages could be revisited in a

spiral curriculum. In contrast to Piaget’s stages, “any subject can be taught to any child at any age in

some form that is honest” (Bruner, 1996, p119).

Arguing against extrinsic motivators, as they caused conformity of thought, Bruner saw the

importance of discovery in learning with the learner being a constructionist helping “him to learn

how to go about the very task of learning.” (Bruner, 1979, p.87). The underlying epistemology of

Bruner is that knowledge is the ability to learn, which matches with the broader goals of

Computational Thinking.

Bruner (1986) felt that language or speech was a tool for learning and that language was essential

for achievement in the ZPD. Bruner also felt that Vygotsky was hinting at the need for scaffolding, in

contrast to Daniels (2002) views.

Papert (1980), having studied under Piaget in Geneva, applied Piagetian learning to programming in

his influential book Mindstorms. Using an applied genetic epistemology, Papert saw his use of the

turtle as a “vehicle for Piagetian learning; which to me is learning without curriculum.” (Papert,

1980, p31). Whilst Papert felt that a curriculum was not necessary, he still felt that support for

children was required and that learning should not simply be spontaneous with free-form

classrooms. Bryant (2003) felt that in Mathematics, which Computing can be seen part of, there are

both inferences and inventions. Inferences can be learnt by discovery but inventions need to be

taught.

Papert (1980) felt that Piagetian learning applied to programming created a concept of ‘New Math’

where learners could try out concepts in a Mathland. The Turtle World was therefore a specific type

16

of microworld which stimulated a “computational-method theory of thinking” (Papert, 1980, p225).

Papert agreed with Piaget and Vygotsky that children needed activity to learn and were better at

finding things out themselves referring to this process as constructionism (Papert, 1991).

Hattie (2012) in his meta-analysis of pedagogy, shows an effect size of a staggering 1.28 from

Piagetian programs. Cooperative work has an affect size of a significant 0.59 and peer influences

0.53. Hattie gives caution that activity in the classroom during individual work is 10 times the activity

of pair work, with group work performing even worse. Galton and Rogers (1990) warned that pupils

being in groups doesn’t mean they learn in groups. As such, care must be used in constructing Pair

Programming activities to make sure that learners are active.

Whilst Piaget has been criticised by those who support Vygotsky, it is clear that constructivism and

social interactionism can be integrated (Marti and Rodriguez, 2012). This dissertation takes the view

that the similarities and congruence of Piaget and Vygotsky dictate using the term social

constructivism to encapsulate both. Combined with the work of Papert, these create a sound

theoretical basis for how young adolescent children best learn programming within the context of

Computational Thinking.

2.3 Pair Programming – What is it?

Pair Programming has roots in industry as one of twelve methods employed in Extreme

Programming (XP) (Wells & Williams, 2003). The technique involves a Driver, who enters code at the

keyboard, and a Navigator, who corrects defects such as syntax errors or suggests alternative design

strategies. This technique has been shown to produce better quality code in a shorter period of time

whilst boosting the enjoyment software development (Williams & Kessler, 2003). These ideas have

been enthusiastically incorporated into education at tertiary level, leading to higher course

completion, an increase in mastery, greater confidence and improvements in attitudes towards

programming and Computer Science (Braught et al, 2010).

Although the roles of Driver and Navigator seem well defined within the literature, Chaparro et al.

(2005) show that in observations of university students that role change is frequent when new ideas

occur. This blurring of roles also occurs in industry where the use of dual keyboards or frequent

keyboard switching is observed (Chong and Huributt, 2007).

17

Coman et al. (2014) believe there is a lack of consensus on the best use and benefits of Pair

Programming within industry, seeing the technique more as a formalisation of naturally occurring

interactions. It is important to note, however, that the technique could encourage good practice

where it may not naturally occur. Whilst there is much evidence of Pair Programming helping to

reduce errors, Jadud (2006) finds that most errors are of syntactic nature rather than semantic.

Little is known about Pair Programming in children of secondary school age (Denner et al, 2014).

Denner and Werner (2007) studied 126 girls in an after-school summer program learning Flash and

ActionScript. They found that the girls used the collaboration in debugging, tinkering, random

exploration and testing hypothesis. These findings are reminiscent of those found by Papert (1980).

Furthermore, the girls were also interested in exploring the software’s features and not just finishing

the solution as quickly as possible. This suggests the technique corresponds closely with a Piagetian

learning style which doesn’t revolve around a curriculum.

Lewis (2011) studied students in sixth grade during a summer enrichment project. This compared a

class of solo programmers with a class of pair programmers learning Scratch and Logo. Lewis (2010)

found that there were difficulties for students in defining the roles of Driver and Navigator which

wasted time and needed constant teacher intervention and mediation. The 2011 study assigned

students the letters A and B whilst making use of a 5 minutes countdown clock to tell students when

to change role. This eliminated most difficulties in determining who the driver was. Those in the

Navigator role would often lose focus and need to be reminded to concentrate. This behaviour is not

found in tertiary education.

To help to foster collaboration, pupils high-fived when changing partner, along with asking them

what they were working on for 28 seconds. During this time, custom-made curtains were pulled

across the screens to force the discussions to take place and discourage the distraction of

computers.

In the tertiary sector, pairing students together for a terms work was problematic with regular pair

rotation removing dysfunctional pairs. Pair rotation, did though create an administrative burden for

the teacher (Srikanth, 2004). Lewis (2011) assigned pairs randomly each day, suggesting that pair

assignment needs to be made more often for this age group.

18

2.4 Effectiveness of Pair Programming

Research into Pair Programming at university level has shown that learners produce better programs

in less time. Equally, students who pair program have a higher course completion and are more

likely to gain a C or better (Williams et al, 2000; Nagappan et al, 2003; McDowell et al, 2003; Braught

et al, 2011). McDowell et al (2002, 2003) and Cliburn (2003) found that the results in final exams,

taken independently, were the same whether students had pair or solo programmed. McDowell et al

(2006) and Mendes et al (2006) found, more favourably, that both exam results and project results

were higher for those who pair programmed. Improvements in individual programming skills are

observed consistently across ability ranges. Braught et al (2008, 2011) show these gains in students

with lower SAT scores and McDowell (2002) also show the gains in higher ability students.

Slaten et al (2005) suggest that time is well spent Pair Programming as it results in superior program

quality. Muller (2007) though shows that students make as many algorithmic mistakes as solo

programmers, reducing only syntactic mistakes.

Retention rates increase when Pair Programming is employed, as do students opting to major in

Computer Science (McDowell et al, 2003; Carver et al, 2007). In particular, retention rates for

women are greater if Pair Programming is used. This is thought to be due to the technique breaking

the perception of programming as a solitary and competitive activity and instead viewing it as a

collaborative exercise (Werner, 2004).

Students undertaking Pair Programming are more self-sufficient with instructors observing more

productive and less frustrating lab sessions (Williams et al, 2002; Nagappan et al, 2003). Pair

Programming as a teaching method reduces the assessment burden (Cliburn, 2003). Hanks (2008)

found that with Pair Programmers, the number of problems requiring instructor intervention fell to

25% of that of solo programmers.

The problems solved unaided by pairs were not simply mechanistic, but evenly distributed, showing

that Pair Programming helped in all areas. This is in contrast to the findings of Muller (2007). Wiliams

et al (2002) show, in qualitative results, that students who pair program demonstrate an increase in

higher order thinking skills. VanDeGrift (2004) concurs with this, finding that students spend more

time reflecting on code and making use of new vocabulary.

Pair Programming is not a guaranteed panacea. One of the classes studied by Hanks (2006) had

students less positive towards Pair Programming than solo programming. This was particularly the

19

case for women in the class. The study suggests that the instructor of a class can easily influence the

attitudes of students towards Pair Programming.

A distinction must be made between cooperative work and collaborative work. Cooperative work

allows for a task to be split up and completed separately if necessary. Collaborative work is where

programmers are both working together to try and find the best solution. Coman et al (2013) find

that, in both university and professional programmers, solo work is more efficient for cooperative

work with Pair Programming being superior for collaborative work.

In secondary schools, Pair Programming led to better fluency whilst aiding debugging and higher

order thinking skills such as exploratory talk and meta-cognitive monitoring (Werner, 2005; Werner

et al, 2009). Interactions within pairs had the potential to both promote and undermine effective

problem solving. In a study with 320 middle school children, Denner (2014) found that Pair

Programming was good for Computational Thinking and programming knowledge, especially for less

experienced students.

Most studies in Pair Programming compare students in pairs against students working

independently. Lewis (2011) set out to compare Pair Programming with other forms of collaboration

at secondary level. One group studied independently with a 30 second discussion with their

neighbour every 5 minutes. Discussions tended to not be meaningful, but enhanced student

relationships so they were confident to ask each other questions. The other group used Pair

Programming, changing role every 5 minutes. Test results were identical for both tests, but Pair

Programmers had a higher range of results. These results are similar to Braught et al (2011) who

found other collaborative techniques to be equally effective as Pair Programming.

Lewis (2011) finds that the lowest ability students underperform, in contrast to studies into Pair

Programming which suggest that peer scaffolding helps such students. Lewis (2011) suggests that

with younger age students they do not have the same ability to ask for explanations from their peers

and in Pair Programming there was an increased likelihood of conflict and frustration.

2.5 Perceptions of Participants in Pair Programming

At tertiary level and in industry, Williams et al (2000) showed how Pair Programming creates happier

and more confident programmers. McDowell et al (2003) found that students enjoyed Pair

Programming more than solo programming and were more confident in their solutions. VanDeGrift

20

(2004) found that students perceive the benefits of Pair Programming to be social structure, peer

help, reduced frustration and reduced workload. Not only do students find Pair Programming to be

fun, they also want to do it again and believe that they learn more when they are paired (Hanks,

2006). Mendes et al (2005) show that the positive outcomes of Pair Programming occur even when

labs are not part of a formal course.

Slaten et al (2005) found that Pair Programming creates more effective learning opportunities,

improves student confidence and empowers students to learn. Carver (2007) supported these

findings, showing that students view Pair Programming as beneficial to their learning experience.

This result fits with the epistemological basis of Piagetian learning. Students not only enjoy learning

from peers but believe that this prepares them for learning in the real world (Williams et al, 2007).

McDowell et al (2006) confirmed findings of increased confidence, especially in women. Pair

Programming increased confidence from 75%-90% in men and from 63%-87% in women when

compared to solo programming. Gains were more significant for women and almost eliminated the

gap with men. These findings are consistent with those of Werner et al (2004) who find that women

are more likely to persist with programming if they have Pair Programmed. However, Braught et al

(2011) find in student perception surveys that whilst Pair Programming gives greater confidence,

there is no evidence for greater confidence for women. They do however find that female students

have reduced frustration when Pair Programming. Enjoyment of Pair Programming is shown to not

only be consistent for male and female students, but also with minority and majority students

(Williams et al, 2007). Salleh (2012) shows that Pair Programming not only increases enjoyment of

programming but also motivation.

Srikanth et al (2004) found that the majority of students do not want to stay with the same partner

for extended periods of time and prefer pair rotation. As discussed previously, the roles of Driver

and Navigator tend to be blurred. Chao and Atli (2006) find that student perceptions agree with this,

believing that there should not be fixed roles. In their study they found that one student would be

on the keyboard whilst the other was on the mouse. Roles were interchangeable with the keyboard

slid from one student to another. Despite non-rigid roles, students still enjoyed Pair Programming

classes more than solo programming and collaboration skills were promoted.

Braught et al (2011) found that in labs where individual programming was employed the lab was

silent. This was in stark contrast to Pair Programming sessions where the “room buzzed” (Braught et

al, 2011, p.17). Syntax and type errors were solved without the need for help. Assistant time was

21

instead spent engaged in discussion with students as to the efficiency or elegance of a solution. As

such, labs were more enjoyable for both staff and students.

Sometimes, pairs occur where one student is not as motivated as the other. Srikanth et al (2004)

found that students saw peer evaluation as an effective way to provide feedback of partner

performance to teaching staff, but they did not feel it was an effective way in motivating students.

Simon and Hanks (2008) found that not only do students employing Pair Programming get stuck less

frequently, but they also explore more ideas. As such they believe that Pair Programming has helped

them. The same study though reveals some unexpected results which would appear to conflict with

other studies. Students who solo program felt they were more confident and understood their

programs better. Whilst it would appear that these findings are in conflict with others, it is important

to note that these students had already undertaken an introductory course where they Pair

Programmed. As such these findings show that for more experienced programmers, solo

programming may be preferable. These findings are consistent with those of Coman et al (2013)

which suggest that Pair Programming can be less productive than solo programming when

programmers are more experienced and not involved in a project where true collaboration is

required.

Lewis (2011) found that sixth grade students during a summer enrichment programme rated topics

as easier if they had pair programmed. However, in contrast to findings at tertiary level, they had

stronger feelings in wanting to continue to study Scratch or Computer Science if they had solo

programmed rather than pair programmed. This was attributed to conflicts with partners and a

decreased sense of ownership. These findings do seem to have some similarities to those of Simon

and Hanks (2008) regarding university students on a second course. The findings regarding sixth

grade students also make use of Scratch as the programming language. Due to Scratch being a visual

programming language it does not have issues of syntax which present difficulties for novice

programmers. Therefore a specific advantage of Pair Programming is removed.

Denner (2014) looked at middle school students between the ages of 10 and 14. Pair Programming

was compared with solo programming using the Alice programming language. Whilst Alice is a more

complex language with the ability to employ a more advanced Object Oriented paradigm, it still

invokes visual drag and drop to program, thus eliminating syntax difficulties. The study found that

whilst Pair Programming was advantageous for computational thinking, particularly for less

experienced students, those students who were more positive to collaboration had their

programming knowledge decrease. It was hypothesised that this was the result of difficulties

22

working with a partner less interested or willing to collaborate. For this age group, familiarity and

comfort in a partner resulted in more learning.

2.6 Criteria for Pair Compatibility

At tertiary level, Thomas et al (2003) compared homogeneous and heterogeneous pairs by

confidence levels. They found that students with high self-confidence do not enjoy Pair

Programming as much as other students. Students work best when they are in pairs where they have

similar self-confidence levels. Students with the least self-confidence enjoyed Pair Programming the

most. The confident programmers disliked Pair Programming even more if they were paired with the

least confident. Students produced their best work when they worked with students of similar levels

of confidence. These findings are in conflict with Hanks (2006) who found that the most confident

students liked pairing the most and least confident students the least. No explanation is given as to

why this is the case, however, the results, whilst positively correlating were not found to be

statistically significant.

Katira et al (2004) found that it was the perception of the partner’s skill level which had significant

influence on pair compatibility. Graduate students worked best when partnered with a similar actual

skill level, whereas for first year students, they worked better with partners who had different

personality types in the dimensions of introversion and intuition. They found, in contrast to Thomas

et al (2003), that self-esteem was not a big influence on pair compatibility. Most importantly it was

the students own perception which was important and “educators cannot predict this perception

nor can pairs be formed based on this fact.” (Katira, 2004, p.10). Matching by similar skill improved

compatibility for all students including minorities. Whilst perception of skill level was most

important, it was also found that pairing by actual skill level was likely to result in compatible pairs.

Mixed gender pairs though were likely to be incompatible (Katira, 2005). Williams (2006) found that

students prefer to partner with students who have the same or higher skill level. They found that

pairs who had the sensor-intuitior learning style were also compatible. “Sensors prefer information

gathered through experience and are attentive to details, while intuitors prefer abstract concepts

and are bored by details, preferring innovative thoughts instead” (Williams et al, 2006, p4). The

personality dimensions of: introvert/extrovert; thinking-feeling; judging-perceiving, all had no effect

on pair compatibility, however, pairs with a differing work ethic were not compatible. The study did

not find that similar actual skill levels (e.g. from SAT tests or GPA) made a difference to compatibility,

23

however, similarity of perceived skills was important. GPA for Computer Science was seen as a

predictor of perceived ability and hence could be used.

Salleh et al (2012) criticised the inconsistencies in the effects of personality to pair compatibility.

They found that conscientiousness and neuroticism do not affect pair performance, whilst openness

was significant in pair performance. These findings are consistent with those of Chao and Atlie

(2006). They find the effect size of openness to experience to be between 0.24 and 0.3.

Braught et al (2010) studied 259 students on their first Computer Science programming course. They

paired students by demonstrated ability, randomly or solo. The lowest quartile of students who pair

programmed performed better than those who were randomly paired or worked individually. They

hypothesise that pairings of strong students with weaker ones are unproductive as they do not

expose weaker students to difficulties they would have gained individually or with a weaker partner.

In general it is seen that the stronger partner takes over and the weaker one becomes passive in the

task. By contrast, students of similar ability collaborate.

Chaparro (2005) also found that pairs need to have matching skill levels and that this influences pair

collaboration. Student’s views are that they want to work with others of a similar skill level and that

this has a positive influence on collaboration. Students are only reticent to work with a partner of

similar skill level if neither partner understands what they are doing. Pairing two high achieving

students is also not successful when the work is too easy and doesn’t require collaboration to solve

the problem. In heterogeneous pairs where large skill gaps are present, the low ability students

perceive that they are learning more in pairs, however, the high ability report that they learn less.

Chao and Atlie (2006) concurred that homogeneous pairs by ability obtained substantially higher

scores than heterogeneous ones. They found that personality traits of the partners resulted in no

differences in code quality, however, those with open minded and responsible traits performed

better. Matching skill levels was seen as more important than personality for successful pair

compatibility.

Lui & Chan (2006) studied the effect of pairs in industry, finding similarities to studies in tertiary

education. Novice-novice pairs were found to be more productive than novice solo programmers.

However, expert-expert pairs were not as productive as solo programmers as they already knew

how to solve the task and therefore working together was not as efficient.

Studies into Pair Programming at the secondary level are extremely limited, with findings into pair

compatibility even more sparse. Hence studies in other subjects are considered. Hooper & Hannafin

(1988) studied heterogeneous and homogeneous groups based on ability whilst students learnt a

24

Mathematical topic. They found that heterogeneous groups led to a significant improvement in the

achievement of low ability students with no negative effects on the more able. Ernst and Byra (1998)

support this finding for pair ability. Learner likeableness was found to have a significant effect on

outcomes. Saleh et al (2005) studied students in fourth grade Biology comparing homogeneous and

heterogeneous groups. They found, by contrast, that the average ability students performed better

in homogeneous groups with high ability students performing equally well in either type of grouping.

Heterogeneous groups had higher proportions of individual talk and discussion, whilst homogeneous

groups gave more collaborative talk. Carter and Jones (2006) studied fifth grade students in Physics

with the concept of balance. They found that low ability achieved greater results and spoke more

words when paired with high ability partners. They also exhibited less distracting behaviour. High

ability students spoke more words when in heterogeneous pairs rather than homogeneous ones. No

achievement differences were found for high ability regardless of their partner’s ability which is in

agreement of the findings of Saleh et al (2005). As such, Carter and Jones (2006) conclude that

heterogeneous grouping is beneficial to low ability partners without being detrimental to high ability

students. Whilst results of ability pairings differ slightly between studies, the research suggests that

heterogeneous pairings are broadly preferable. This conflicts with the findings of Pair Programming

at tertiary level and within industry.

Lewis (2011) when studying Pair Programming, paired sixth grade students by random assignment of

partners. Where students progressed slowly they were paired with a higher achieving student in an

attempt to push them forward. They found that this was not successful and “may have increased the

difficulty for students who were not progressing as quickly as their peers” (Lewis, 2011, p23). Denner

et al (2014) studied middle school pupils aged 10-14 finding that, students with more experience

with computers than their partner, had more positive attitudes and confidence to Computing. Pair

Programming was still beneficial for both, but stronger gains were made for those with low prior

knowledge. Pairing students who have different attitudes toward collaboration was not successful

with those who preferred working alone undermining their partner’s progress.

25

2.7 Summary

There are a number of factors which aid pair compatibility with partner ability being a key variable.

Research at tertiary level finds that contrary to conventional wisdom homogeneous ability pairs are

superior for Pair Programming, particularly for weaker students.

Research of Pair Programming with secondary aged students appears to be inconclusive and

conflicting. Lewis (2011) had negative results with heterogeneous pairs hypothesising that pairings

should be made with homogeneously. Studies in other subject conclude that heterogeneous pairings

are most profitable for low achieving students with no negative effects for higher achieving. These

are in stark contrast to studies at tertiary and industry levels which suggest that for Pair

Programming homogeneous pairings are best. It has yet to be established if Pair Programming is a

unique case for pairing combinations or whether secondary aged students differ from adults.

Studies into the perceptions of students towards Pair Programming at university level show that

they enjoy it, feel more confident, are more efficient and spend more time on higher level thinking

skills. With younger secondary aged students evidence is limited to their perceptions of Pair

Programming. Lewis (2011) shows that students find topics easier when Pair Programming.

However, it is also shown that Pair Programming reduces students wanting to continue studying

Scratch or Computer Science compared to solo programming. This directly conflicts with the

research at tertiary level. It is hypothesised that conflicts with partners may be the cause of some of

these negative effects. Students were paired randomly or heterogeneously which may have resulted

in pair conflict. With no alternative studies into student perceptions, it is clear that further research

is required. Research has shown that pair compatibility is linked to the perception of a partner’s

ability (Katira et al, 2004). This study’s research questions look at ability pairings and student

perceptions, which the academic literature suggests are closely intertwined. As such they aim to

answer a clear gap in the research literature.

26

Chapter 3 - Methodology

3.1 Outline of the Methodology

This chapter considers the approach taken to the research in light of the most relevant research in

secondary schools and Pair Programming. The data collection instruments are outlined along with an

overview of the data and contextual information.

The method of Pair Programming used in this study has unique adaptations for this study which are

detailed along with their reasoning. The teaching materials used are also presented.

Each of the data collection instruments are presented in detail, with methods of recording and

analysis outlined. Sampling strategies and limitations are then covered. Finally ethical considerations

are discussed with strategies which were employed to reduce any risks.

3.2 Approach

The research questions under consideration are:

1. What perceptions do students in secondary education have towards Pair Programming?

2. What are the most constructive ways to pair students?

We must first be precise in the meanings of these questions before outlining the methodology taken

in this study. In terms of perceptions we are considering participant views in several areas which

constitute pair programming. The method of Pair Programming used in this study has unique

adaptations to those used by Lewis (2011) and student perceptions to these are important. Student

perceptions tie in closely with the second question in that these will be considered strongly when

determining the most constructive way to form pairs. Of course, in analysing how students perceive

pair programming, it is important to consider how they perceive programming in general. This is in

order to establish whether pairs alleviate or contribute to difficulties encountered by novice

programmers. Obviously, it is important to understand student’s perceptions of Pair Programming

overall in terms of their enjoyment and their desire to undertake programming classes in the future.

27

With regards to the second research question, it is important to first define what is deemed to be a

constructive pairing. Outcomes of such a pair would be efficiency in code production, enjoyment of

sessions, and consideration to alternative ways to solve problems along with reduced frustration. In

establishing the complexity of code tackled during sessions the Progressions Pathway (Dorling &

Walker, 2014), published by the Computing At School’s group (CAS) will be used. Evidence of

Piagetian learning will also be used in determining constructive pairings.

This study is based on a mixed methods approach, this allows the most pragmatic paradigm for the

study whilst giving richer answers to the questions (Johnson et al, 2007). There are a number of

methodological instruments deployed in the study which feed into different phases of the study. As

such the study covers many of the seven domains of mixed methods research given by Tashakkori

and Teddlie (2010).

3.2.1 Instruments deployed

The data collection instruments used are shown below in Figure 1. This diagram also shows each

phase and how data feed into each subsequent phase.

28

Figure 1 – Phases of data collection

Mixed methods is not just a combination of qualitative and quantitative methods but one of a new

paradigm (Onwuegbuzie and Leech, 2005). Tashakkori and Teddlie (2006) show that the number of

methodological approaches is important in mixed methods. This pluralist approach is employed in

this study.

The first stage consisted of four pair programming sessions. At the end of each session a test was

given consisting of 10 questions which were auto-marked by the school’s Moodle system. The

results of these tests were ranked and then used create homogeneous pairs. The first session was

intended to employ random pairings; however, many students expressed a desire to pair with

friends which was permitted. Homogeneous pairs were used for the second and third sessions. In

session 4, friendship pairs were permitted where these were requested by students.

29

At the end of each session a short four question questionnaire was also given considering the

perception of each participant toward their partner’s ability, pair success and enjoyment of the

session.

Program code produced by each pair was electronically submitted at the end of each session and

observations were made in each session and recorded in a notebook.

The final phase of the first stage was a longer questionnaire containing both open and closed

questions.

An initial analysis of this data resulted in selection of six students to take part in three interviews.

These were recorded and transcribed, with each subsequent interview either considering a new

topic or seeking to verify points already discussed.

3.2.2 Overview of the data

The study was undertaken in a non-selective independent secondary school located around 25 miles

West of London. Around 200 students were invited to sessions by email and visits to tutor groups

and ICT lessons. 20 students participated in the programming sessions with between 12 and 15

attending each session. 10 students attended all four sessions. Return rates for electronic

submission of source code, tests and end of session questionnaires were 100%. The final

questionnaire was completed by all 15 participants who attended the final session along with a

further 1 participant who had attended the three previous sessions and completed the

questionnaire at home. 3 girls and 17 boys participated in the study.

Students participated voluntarily and were self selected from years 7 and 8. Almost all participants

were in year 7 with ages of participants being 11-13. None of the participants had studied

programming with a text language in formal school lessons, however, a few had used VBA for Excel

in an after school club. Scratch had been taught to students in formal lessons. No participants had

programmed using Python before the sessions.

Each session consisted of 50-60 minutes of programming with a further 10 minutes to complete

questionnaires and tests. Sessions were held in an ICT classroom. Although I was the teacher for the

sessions, none of the students had been taught by me. Sessions took place after school between

4~5:15pm.

30

All six students recruited for the three interviews attended. Interviews lasted 27-33 minutes and

were undertaken during a lunch break. Interviews took place in the same classroom as the sessions,

but in one case the final 10 minutes had to be continued in a departmental office due to the

classroom being required by another teacher.

All research was carried out in the summer term, with interviews given 2 weeks after the

programming sessions due to a half term break between these phases.

3.2.1 The method of teaching Pair Programming deployed and overview of study

The concept of Pair Programming was explained to the students with a slide of a presentation to

describe the process (See Appendix G). Pupils were briefly shown how to complete the first turtle

example using the Python language, including how to write, save and execute the code.

Students had two keyboards connected to the same computer with the computer in the middle of

the two children so that neither child was “in control”. Keyboards had been arranged so that they

pointed inwards to create the implication that collaborative would be required (See Figure 2).

31

Figure 2 – Dual keyboard setup

Before pupils started, they were shown the clock which would indicate the partner who was in

control. Purposefully, the terms Driver and Navigator were not used. Students were told that if they

had control then they could type or use the mouse. If their partner wished to type or use the mouse,

they could, but only if the partner in control allowed it. It was intended that this would enable a

more natural sharing of control whilst allowing pupils a method of resolving conflict. The use of

Right/Left being displayed was an adaptation of Lewis’ (2011) use of A/B with student assignment.

The clock counted down from 5 minutes, after which an alarm rang and the clock was reset. The

words Left and Right alternated with each turn. An example of how the clock appeared to students

from a computer is given in Figure 3.

32

Figure 3 – Clock, programmed in Python, showing remaining time for Right partner to have control

Three practices of using the clock to changeover were given. Each time students were encouraged to

high-five and shout “awesome”. This was adapted from Lewis (2011) however, students were not

required to discuss their work in this study, and the language used was felt to be more appropriate

for English participants.

At this point the students were given the workbooks and allowed to work through the tasks. In each

session, students had around 50 minutes of programming time.

After each session, students connected their keyboards to individual computers to complete tests

and questionnaires. After the first session, students were able to create the dual keyboard setup

themselves with teacher supervision. This reduced the setup burden for the teacher.

33

3.2.2 Teaching materials

For the first three sessions, activities were based around the Python turtle library. This allowed

similarities with both Papert’s (1980) and Lewis’ (2011) studies to be made.

The activities set allowed for students to experience entering code, code creation and debugging. A

variety of programming concepts were given in examples, including assignment, procedures,

selection, functions and recursion through the use of fractals.

It has been argued (Turbak et al, 1999) that recursion be taught within a functional language

paradigm prior to procedural methods. Whilst this has positive results, it is felt that many

participating students are unlikely to be at Piaget’s Formal Operations stage and may have difficulty

with such concepts. Furthermore, the ability to program recursively is at the highest stage of

progression for Key Stage 3 students (Dorling & Walker, 2014). As such, examples of recursion were

given in fractals, but students were not expected to create recursive functions.

The final session allowed students to program an adventure game where they learnt selection

through if statements. Simple Boolean logic was also presented.

3.3 Data Collection Instruments

3.3.1 Tests

Summative tests were given at the end of each session to establish ability. These were 10 self

marking questions of fill in the blank and multiple choice styles. Different tests were given at the end

of each session. The primary purpose of the tests was to allocate students to homogeneous pairs in

each subsequent session.

The secondary purpose was to establish whether lower ability students made similar progress to

higher ability students. As students would have all been in the same class, other variables remained

constant. Unfortunately, with only 10 students participating in all four sessions it was not possible to

perform this analysis and differences for higher or lower ability students were not found.

34

As the tests were primarily used to pair students together in subsequent sessions, it was hoped that

a suitable range of scores would be obtained. Had this not been achieved, then tests would have

been altered during the study, however, this was not necessary as tests were able to differentiate

between high and low achieving students.

The tests were a form of continuous summative assessment, and advice from Black & Wiliam (1998)

was taken into account in not giving students their scores even if they requested them. This

prevented students from becoming demotivated and allowed them to focus on any formative

feedback given by their partner or the teacher.

Gronlund (1990) stresses the importance of potential items discriminating those who do and don’t

understand a topic. It is suggested that questions are piloted to check for discriminability, however,

this was not possible due to difficulties in recruitment with the target age group.

The tests involved made use of fill in the blank style questions to test for keywords rather than trivial

language as advised by Hanna (1993). Further advice by Aiken (2003) was implemented in ensuring

that potential answers to multiple choice questions were all plausible with only one single correct

option.

Tests were administered by the school’s Moodle system, ensuring that consistent layouts were used

which participants were familiar with. The appearance was consistent with recommendations of the

World Wide Web Consortium (W3C, 2014).

3.3.2 Questionnaires

Two types of questionnaire were used in the study. The first was a smaller questionnaire of four

questions given at the end of each test (see Appendix C). These established student perceptions of

their partner’s ability along with their enjoyment of the session and their perception of how well the

pair worked. At the end of the final session a longer 20 question questionnaire was also given (see

Appendix D).

The smaller questionnaire was asked at the end of each session as pair combinations changed each

day. This increased the sample size for perceptions of partner ability, pair success and session

enjoyment to 54. Questions for the smaller questionnaire were administered immediately following

the test to improve return rates, as such they are labelled questions 11 to 14.

35

Questions 11 and 12 made use of a Likert scale. Whilst Likert scales typically have 5 answers with a

neutral response (Likert, 1932), the options given in this questionnaire only had 4 options with only 1

negative response. Friedman and Amoo (1999) suggest that this can skew results, however,

experience of teaching programming had suggested that students enjoy this type of programming

and it was felt that a finer gradation of positive answers was required. Results showed that no

students selected a negative response in these questions and only 2/52 responses were for the

second lowest response of “okay”, supporting the decision for 4 answers. Cohen et al (2011) states

that where an odd number of options are given, participants will often select the middle one. Hence,

an even number of options were presented.

The final questionnaire at the end of the fourth session probed deeper into student’s experiences of

Pair Programming. As a social constructivist methodology, other standard surveys were considered.

Within the Science classroom, both the Constructivist Learning Environment Survey (CLES) and

Constructivist-oriented learning environment survey (COLES) were rejected due to length. Johnson &

McClure (2004) found that a shortened version, the Constructivist Learning Environment Survey

(CLES2), was just as valid. Four questions regarding student negotiation in class were felt applicable

to Pair Programming and these were used in the final questionnaire. As no solo programming control

group was used, it was not possible to compare the results between solo and pair programmers. It

was though possible to analyse the results to see whether they obtained indicators of high or low

levels of social constructivism.

Multiple choice questions were used in the final questionnaire wherever possible to make analysis

easier. Where answers and opinions were not obvious open responses were sought using a textbox.

This follows advice by Bailey (1994) and Oppenheim (2000). Dillman et al (2003) suggest that the

order of answers can affect results and this was taken into account in the analysis. Branching

questions were avoided as the can confuse respondents (Redline et al, 2002).

More time was allocated to the completion of tests and questionnaires than actually required. This

prevented participants feeling pressured to complete them quickly. Response rates were high,

however, in a few cases it was felt that students had rushed their tests or questionnaires.

All questionnaires were piloted as suggested by Oppenheim (2000) by completing in the Moodle

System to check that they functioned correctly and how long they would take to complete. Further

piloting with students did not take place. This would have been beneficial as in question 15 many

students could not think of anything they didn’t like about working in a pair. As such they selected

36

“other”, when the option “None” would be more appropriate. This was taken into consideration

during the analysis.

The final questionnaire was used to determine levels of enjoyment of pair programming along with

perceptions to the methods used during sessions. As such, simple analysis of percentages and bar

charts illustrate these perceptions clearly. For open questions, results were coded as part of the

analysis.

3.3.3 Observation and programming code

Observations, as an ethnographic method, are a valuable instrument adding depth to the data and

allowing a closer reconstruction of the events which happened (LeCompte and Preissel, 1993).

Observational notes were written in a notebook as events occurred or as soon as possible

afterwards as suggested by Lofland (1971).

Acting in the role of both teacher and researcher created conflicting pressures on my time during the

sessions. As such, the role of teacher was given primacy given the numerous other forms of data

collection for the study; results from observations are therefore illustrative but limited. On a few

occasions, pairs were studied as they programmed with observations lasting several minutes. These

were selected where it was felt that the observation would provide an illustration of a key aspect of

what was occurring in the classroom.

Programming source code was submitted electronically via the Moodle system for each pair. All

saved programs were submitted.

Both of these methods were used for a qualitative analysis to give examples of phenomena

witnessed in sessions along with evidence of the working level of pairs.

3.3.4 Semi-structured interviews

Three semi-structured interviews were carried out after the programming sessions and

questionnaires had been completed. Kerlinger (1971) suggests that interviews are a good approach

to follow up previous findings and also reveal unexpected results. The interviews concurred with

both these points.

37

Students undertook the interviews in pairs so that they would not feel threatened or intimidated by

the situation. They sat the interviews in the same classroom which the sessions had taken place so

that the environment was familiar. Of the six students selected, participation was 100%. Although

Siedman (2013) advises interviews of 90 minutes in length, this was felt too long for children

especially in light of the length of a 1 hour lunch break. As such, interviews were around 30 minutes

each.

Interviewees were selected to look at three specific areas. The first studied students who had

consistently worked well with others in all their partnerships. The second used students who had not

worked well in at least one of their partnerships. Care was taken to make sure that the two students

selected had not worked with each other so that they could speak more freely about the reasons

that unproductive pairs had occurred. The final interview studied two girls to see if the perceptions

were supported across genders.

The interviews had topics, structure and themes worked out in advance as suggested by Patton

(2014) and Kvale (2008). Whilst there was some structure within themes, an open dialogue was

encouraged and as such the interviews were semi-structured.

Morrison (2012) shows that in an interview it is possible to control out other variables by eliminating

each of them with subsequent questions. This method was employed within the interviews, in

particular regarding ability pairings where the technique worked well. Stylianou (2008) suggests that

this technique allows for good probing and getting attitudes and prejudices and these were borne

out in the quality of the interviews. The technique also reduced the influence or bias of the

interviewer towards participants.

At the end of each interview, the interview was transcribed. This assisted in designing the structure

and themes for the next interview based on areas where verification of ideas or further information

was required.

A substantial amount of data was collected. Miles & Huberman (2013) suggest that data overload is

reduced by coding. Open coding was carried out in an inductive manner allowing a grounded theory

of perceptions to be revealed. Use of NVivo was considered, but with only three interviews it was

felt that this would detract from the intimacy with the data that manual methods would provide.

Gibbs (2008) suggests that there is too much emphasis on coding. However, it was felt that coding

was useful in identifying themes in this study.

Once coding was completed a frequency analysis of codes was undertaken to assist in determination

of the most important codes (Appendix L). Codes and meanings are available in Appendix M.

38

3.4 Ethical Considerations

This study uses human participants who are children under the age of 16. As such much

consideration was given to ethical issues presented in the study. The goal of teaching programming

is one which would be seen as low risk and positive for participants. The research literature suggests

that Pair Programming is a productive way of teaching this, as such, no known negative effects were

expected in participants.

A number of considerations were made to reduce risks further. An electronic application was made

and approved through the university REMAS system. Sessions were voluntary and carried out after

school. Results and progress did not in any way affect student’s school performance. The school’s

Computing Head of Department was consulted in this process, and although programming will be

taught to the participants, the project themes are not covered in the current schemes of work. As

such no repetition will be caused for participants in the future.

Participants test results could not be kept anonymous as they were used for pairings in subsequent

sessions. However, students were not given test results even when they requested them. Results

from mini-questionnaires were required in the pairings and so again not anonymous. By contrast,

the results from the large questionnaire where anonymous. Pseudonyms were used in this study

once data collection was complete.

An email (Appendix K) was sent to year 7 and 8 students. A Student/Parent information sheet was

attached to this email (Appendix H). Students were visited by the researcher during their ICT lessons

or tutor groups to give the opportunity for them to ask any questions and to explain the study. The

permission of class teacher or tutor was sought before each visit. The class teacher was present for

each of these talks to ensure no pressure was exerted on students to attend. Information sheets and

parent/student consent forms (Appendix I) were given out to any students who were interested. All

students had to have signed consent from themselves and a parent before they could participate.

Provision was made with another teacher to house any extra students who could not be

accommodated as the sessions may have been oversubscribed with 31 students taking consent

forms. This was not required as 15 was the maximum participants in any session.

Rehearsals for the school play and revision for examinations the following week both conflicted with

this study. The Heads of Year for years 7 and 8 were both consulted and stated that this would not

adversely affect any student who wished to participate.

39

The head teacher, as gatekeeper, was sent an information sheet (Appendix J) and gave permission

for the study to go ahead.

3.5 Sampling

Ideally this study would have used participants in their normal lessons; however this was not

possible as the lessons available were not covering programming. After school sessions had the

advantage of reducing ethical harm, however, care must therefore be taken with the results and

findings as they apply to a small sample of self selected students.

An effort was made to include girls, however, they only made up 3 out of 20 of participants. Whilst

the school has a mixed ability composition, the self-selecting nature of the sample may well have

resulted in a sample skewed towards higher motivated students with a propensity towards

Computers. Comparisons with Lewis (2010, 2011) are valid as in these studies students were

undertaking a summer enrichments programme.

The presence of an imminent school play along with conscientious students wishing to revise for

examinations the following week may have reduced the skewing effect towards high ability or

motivated students.

Year 7 and 8 students were recruited with the majority being year 7. An exclusion criteria that

participants had not previously studied programming with a textual language in a formal setting was

applied, however, this did not exclude any volunteers from participation.

The sample size was sufficient to gain meaningful qualitative data from pairs. Attendance varied

between 13 and 15 at each of the sessions which was adequate to simulate a typical class, albeit

smaller than most classes in England.

Although only 24 unique pairs were created in sessions (with one group of three), 54 responses were

given in each of the after session questionnaires.

Three interviews occurred with two students in each. These were selected on the basis of successful

partnerships, unsuccessful partnerships and gender respectively. The limited number of interviews

makes them unsuitable for quantitative frequency analysis; however, they are suitable for gaining

qualitative depth and insight.

40

3.6 Limitations, Validity and Reliability

Denzin (1970) supports a mixed methods approach as a method of triangulation enabling

convergence of results (Campbell and Fiske, 1959) and a more holistic view (Mortimore et al, 1988).

Although Fielding and Fielding (1986) argue that validity and reliability are not increased by

triangulation, Denzin (1997) believes it does.

The use of a standard constructivist questionnaire (CLES2) has already been shown to be valid and

reliable in giving evidence of social constructivism in the classroom. Further questions regarding

perception allowed a number of opinions to be expressed both in closed and open form. Piloting the

questionnaire would have increased reliability in the responses to one question.

Completing questionnaires at the end of sessions with ample time allocated led to a perfect

completion rate. Not all students were present at the final session and given that ethical approval

had not been requested to follow these up with requests to complete, there may be some opinions

which were not collected. However, responses on the long questionnaire are consistent with

observations and responses in other questionnaires, so results are likely to be valid.

Data collection instruments were employed on 7 distinct days, with each feeding into the next. The

use of interviews to follow up results and questionnaires contributed to the validity of the data.

Douglas (1985) suggests that 25 participants for interviews is a good estimate for where data beings

to become reliable. Rubin & Rubin (2011) suggest that rather than the number of interviews being a

measure of reliability, when interviewees begin to verify similar results there is no gain in continuing

with more. There was significant congruence in interview responses suggesting validity and reliability

in the process. It is though accepted that a greater number of interviews would improve reliability.

41

3.7 Summary

This chapter has studied the data collection instruments in detail along with explaining why they

were used followed by the methods of analysis which were undertaken. Decisions taken in teaching

resource production were discussed. An overview of how potential harm was minimised to a

negligible amount was given in the ethics section. Considerations to samples, limitations, validity and

reliability were all given suggesting that whilst improvements can be made to the study, the results

gained are valid and reliable.

42

Chapter 4 - Results and findings

4.1 Outline of chapter

This chapter shows the results and findings obtained from all the data collection instruments. The

findings section is divided into subsections which cover the perceptions of the method of pair

programming by the students and their perceptions towards pair construction. Results show

evidence of social constructivist learning, along with evidence of progress during pair programming

sessions. At the end of the chapter key findings are summarised.

4.2 Findings

4.2.1 Perceptions towards the method of Pair Programming

Enjoyment of Pair Programming

Participant’s responses in interviews were unanimously that they enjoyed working in pairs. Reasons

given were the motivation, enjoyment and diversity.

“Fun, it’s more fun with a partner.” (Jack)

“Yeah – it’s more enjoyable” (Josh)

“If you’re on your own, you can get a bit bored typing away, they keep you entertained.” (Josh)

The final questionnaire asked for any other relevant comments in the final question. All comments

made about Pair Programming were positive.

“I have enjoyed learning python” (Oliver)

“I really like the idea... I love it when I am with someone whom I know and I work well with.”

(Benjamin)

“IT WAS AWESOME. And I hope I do it again” (Joseph)

43

“The whole experience was amazing--- I love ICT and would really like to program some more!”

(Matthew)

Students were asked at the end of each session if they enjoyed it. Of 54 responses, 81% rated the

session excellent, regardless of how they were paired. When asked if they would like more

programming lessons in school, 15 out of 16 participants (94%) replied “Yes – that would be

excellent”.

The use of a clock

The clock was a major tool used within the sessions showing students which partner had control

along with a 5 minute countdown.

In the final questionnaire 88% liked having the clock to tell them when to change partner.

Observations made during the sessions showed that students consistently referred to the clock to

see how much time they had left in control, and as a reminder as to which partner should currently

be in control. The clock was consistently used as an arbitration tool and one of fairness for time

allocation. 69% of students felt it was helpful in changing control. 50% felt that it prevented

arguments compared to 6% who felt it created them.

“Some people may just want to do like everything so this way it’s like fair, so this person goes on,

then this person, but you both get the same amount of time” (James)

“I thought it was very good. I think the techniques which you use with the stop-watch are really,

quite, effective and efficient; because then there was no arguing and wasting time; because there

was an easy split and it was equal” (Josh)

The length of time each partner had control was set at 5 minutes. This worked well in the sessions

and no comments were observed that it was too short or too long. The questionnaire revealed that

31% of students felt it was the correct amount of time and 19% would have liked longer. A low

response in this question may have been due to it being at the end of a long list of multiple select

answers. All students agreed with the length of time in the interviews.

“I also thought it was a good amount of time. I think maybe if it was only two minutes it would be

a bit too short and might get a bit annoying but if [it] was like 10 minutes then the same person

might be typing for ages” (James)

Surprisingly, the clock created urgency in students and caused them to come up with alternative

solutions.

44

“Well sometimes I thought of a complicated solution to the problem, then I saw how much time

we had left on the clock and so I suddenly just thought of a simpler solution to it.” (Thomas)

Allowing students to blur the roles of Driver and Navigator eliminated issues with fixed roles. In

answer to whether the clock made working worse, Thomas said:

“No not really. Unless you’re in the middle of typing, but your partner will probably just let you

carry on.”

The clock was also deemed to be important in preventing students from taking over. Asked whether

the clock was important, James responded:

“Yeah definitely.”

“Because otherwise it would just end up with just one person hogging it.”

Positive views towards the clock were given by both genders.

The use of two keyboards

Two keyboards were connected to each computer allowing both students to type at the same time.

81% of the students preferred using two keyboards, with only 12% preferring one keyboard. 50% of

students found they typed about half each, with 44% finding that it depended on the pair they were

in.

The open questionnaire question was coded and revealed that the highest reason for liking a dual

keyboard setup was for efficiency (38%).

“Because you don’t have to move it around all the time and you can easily negotiate between

whom is typing.” (Benjamin)

“Because then we can just switch and not have to faf around.” (Emily)

This was confirmed in interviews:

“... it saved the time of having to move the keyboards around” (Thomas)

The use of keyboards led to a more collaborative approach and greater responsibility. It was

observed that the use of dual keyboards also allowed for the partner to take control quickly if they

45

had an idea. This was revealed by 38% of students preferring to change control themselves rather

than with the clock. Confirmation was found in interviews:

“I liked the fact that we had two keyboards... some of the time we typed something and we didn’t

know what to type and they could just type it on their keyboard instead of having to move it.”

(Emily)

One dislike of two keyboards was due to a space limitations:

“...when you move the mouse it might not have reached, so we had to push all the keyboards

down to do it and that was annoying so I preferred just using one.” (James)

It was observed that the use of dual keyboards could also cause disruption if typing occurred against

the wishes of the partner in control. This was observed as a greater issue where at least one partner

was lower ability.

“The two keyboards was (sic) good to an extent. When you were working with someone bad they

would just misuse it.” (Josh)

Students also hypothesised this as a problem even if it hadn’t occurred to them:

“I could see it personally becoming an issue if your partner was kind of a destructive mindset then

it’s constantly typing random letters and stuff”.

Unplugging the second keyboard was the solution if this occurred.

“At one point I did have to unplug the keyboard” (Jack)

“I’d start by asking them to stop, then if it happened then I’d probably end up unplugging their

keyboard.” (Thomas)

The changeover

At the changeover, students were asked to shout “Awesome” and high-five each other. 50% of

respondents liked both aspects, with a further 19% liking the high-fiving but not the shouting of a

word. Only 12% did not like either aspect.

Age appropriateness was raised:

46

“for younger students like us it would probably be a good thing, but for older students they might

not like it.” (Thomas)

“I think it’s more like a year 7 to 8 thing coz it’s more like kiddy friendly” (Sophie)

From an observational perspective, these techniques allowed the teacher to clearly see any pair who

had forgotten to change and also made it more obvious to students that a changeover had occurred.

“The only thing is it makes it obvious, so for example, if you missed the ding. ... if you see people

high fiving around you then you can tell.” (Thomas)

“I think it’s actually better if you do it and then you can see who’s quite enthusiastic and who’s

relaxing; it would be clearer to the teacher.” (James)

In importance, high-fiving was rated below the use of dual keyboards, but above the importance of

shouting “awesome”.

Some inappropriate behaviour was observed during changeovers.

“Also it makes people get a bit giddy and overexcited. And they just stop working.” (Josh)

An unexpected result raised in interviews was that of timewasting:

“I just think it wastes a bit of the time. Because if you add up all the time you spent high fiving,

well it kind of adds up.” (Josh)

Alternative ideas

Alternative ideas were raised for having a short 30 second discussion at the changeover. This wasn’t

seen as productive:

“... we’d just be going over the same stuff we’d already talked about then just before that.”

(James)

Some confusion was initially observed with the arrangement of a 3 swapping with the person to

their left or right.

“Well it got slightly confusing at one point as we didn’t all entirely understand what we would

do... but then we tried it for a bit and we realised that everyone did get the same amount of time”

(Thomas)

47

An alternative idea of each student moving up one was suggested, which may be less confusing to

understand.

The girls raised many suggestions for customising the topics to be more girl friendly. These were

beyond the scope of the research questions. See Appendix O for a full transcript.

4.2.2 Perceptions of pairing combinations

Ability pairings

The strategy for pairing was to pair students by similar ability as tested at the end of each session.

Many partners were perceived to be dissimilar though.

The final questionnaire found that 81% of students wished to be partnered with someone with the

same ability in programming as themselves. 19% wished to have a partner who was better than

themselves and no one wished for a partner who was lower ability than their own.

At the end of each session, participants were asked how they perceived their partners ability and the

success of the partnership. 51 responses were gathered.

Responses were analysed in SPSS assigning each answer to an ordinal scale from 0 (Bad) to 3

(Excellent). The mean average showed that highest enjoyment of sessions was for homogeneous

pairs. Means and standard deviations for both enjoyment of session and partnership success are

given in Appendix S.

81% of those who were paired with someone who they felt had the same ability rated the

partnership as excellent (See figure 4)

Figure 4 – Pair success with homogeneous pairs

0

10

20

30

40

Excellent Good Okay Bad Nu

mb

er

of

stu

de

nts

Success of partnership

Partner perceived to be same ability

48

Where the partner was perceived to be more able, perceptions of success were inconsistent. (See

figure 5)

Figure 5 – Pair success with higher ability partner

Partners who were paired with someone less able all responded that they found the partnerships to

be excellent. Only 6 of the participants felt their partner was lower ability so this sample size is very

small. In addition, during two of the sessions, two higher ability students specifically requested from

the teacher to not be partnered with someone who had lower ability suggesting that unsuccessful

pairings are possible.

Figure 6 – Pair success with lower ability partner

In the first session, pupils were allowed to create pairs based on friendship. 83% of participants

perceived their pair to be ‘Excellent’, with the remainder ‘Good’. 100% of participants felt their

partner had the same ability. It is important to note that these are perceptions of ability and all

students were new to programming in Python.

0

1

2

3

4

5

6

Excellent Good Okay Bad

Nu

mb

er

of

stu

de

nts

Success of partnership

Partner perceived to be more able

0

2

4

6

8

Excellent Good Okay Bad Nu

mb

er

of

stu

de

nts

Success of partnership

Partner perceived to be less able

49

In the second and third sessions, participants were paired on the basis of their test results. In the

second session this led to only 43% of partners having similar ability resulting in 29% of partners

giving the lowest rating “Didn’t work well” to their pair – the only time this view was expressed. 75%

of the time this negative view was expressed was when the pair was heterogeneous.

Session 2 was observed to have far more arguments amongst participants and to be more disjointed

with an improved atmosphere being progressively observed in subsequent sessions. It is felt that the

use of multiple quiz tests to determine later pairs will have increased pair allocation. One student

didn’t want to be paired with another in session 3 as they weren’t friends. They were given a

homogeneous pairing and surprisingly, at the end of the session they said that their pair had worked

well and they had enjoyed the session.

67% of pairings in the final session were homogeneous; all heterogeneous pairs were at participant

request due to friendships. This session had the highest pair satisfaction with 93% rating their pair as

Excellent.

The raw data (Appendix R) is clear in showing the relationship between pair success and the type of

pairing.

In the interviews, a preference for partners with the same ability was clear.

“I’d go for someone who has the same ability as me, because if they have done it longer and

they’re more experienced at it they know a lot better than me; they might just take over and not

let me do anything. If there is someone that has less ability than me, then they might just sit back

and watch me do everything, so I wouldn’t like that either.” (Jack)

This preference for homogeneous pairings by ability was consistent in all 6 interviewees. The issue of

a partner taking over or sitting back was expressed numerous times and compounded by egotistic

behaviour.

“... if she was better then she might be thinking like, she can keep doing things and not letting me

have a go, because she might be on top of herself a bit.” (Sophie)

Being in homogeneous pairs seemed to also increase the possibility of learning.

“If you’re sort of the same level and you don’t know much about it, it’s good to like work together

and find out what you’re supposed to do... you can just like bounce off each other with like

things.” (Emily)

Even when other variables were taken away, a propensity for homogeneous pairings existed.

50

“I would say the same amount still. It makes me feel comfortable.” (Jack)

This feeling may have been due to trust in the partner as they wouldn’t be egotistic.

“....the other person’s like, the same level, so you know like you can trust each other” (Emily)

In addition feelings of inferiority or self-esteem were relevant.

“... if they’re really good you could just feel like you’re stupid because you can’t do anything

compared to them.” (Josh)

“if, the other person knows a lot then they might just be like, that’s wrong, that’s wrong, that’s

wrong, and not say anything if it’s right, so you just don’t learn from your mistakes.” (Emily)

Partnering had some complexities. In some situations participants would like to go with someone of

higher or lower ability.

“I’d choose the person who has more ability than me so I could erm learn from them; then next

time I could choose someone who has less ability. At least I could pass down that knowledge.”

(Jack)

Altruistic behaviour was cited as a major reason for wanting to pair with lower ability:

“I think I’d be doing good because I’d be helping them and giving them skills and teaching them

and I’d feel really good about myself.” (Josh)

Participants wanted to pair with students who were similar but not identical. They were consistent

in not wanting extremes of lower or higher ability. Commenting on someone much higher than they

were, James replied:

“Because I think they’ll do things just too complicated for us to understand and we won’t grasp

what they’re doing.” (James)

Conversely for pairing with someone who was well below their ability

“If they’re too worse then it might be me who’s explaining it to them and I think that would be a

bit annoying sometimes.” (James)

Unconstructive pairs tended to be predominantly due to disruption of a partner.

“Someone that would try to just take over. They wouldn’t listen to what you had to say and might

just be annoying when it’s your turn and just keep typing random things.” (Jack)

51

“they’d be really cocky and just mess around. And when it’s their go and you’re doing something,

they wouldn’t help, they’d talk to someone else.” (Josh)

Homogeneous pairs also had a positive effect on the enjoyment of the session (see Figure 7). Where

a partner was perceived to be the same ability, 89% of participants felt that the session was

excellent. This was the case in only 67% of sessions where the partner was perceived to be of a

higher or lower ability.

Figure 7 – Enjoyment of sessions by ability

Alternative methods of pairing

Few other alternatives of how to pair were given by interviewees. One mention of random pairings

was given as a possibility, however, observations in the classroom would suggest that this would

only be suitable in the case of no other information. Interviewees did raise the importance of

personality, interests and friends as compatible partners.

“I would put first personality because if you get on with them and they’re really fun then you

might work more effectively together.” (Josh)

“... they [your partner] enjoy the same things as you, but not completely. They don’t unanimously

like the same thing as you, they have some different interests. That gives you some diversity which

allows you to, just makes it different.” (Jack)

0% 10% 20% 30% 40% 50% 60% 70% 80% 90%

100%

Yes - It was excellent

Yes - It was good

Yes - It was okay

No

Nu

mb

er

of

resp

on

de

nts

Response

Did you enjoy today's session?

Homogeneous

Heterogeneous

52

There was no definitive consensus on how to pair girls and boys and in the sessions all girl pairings

were always successful and in some cases seemed to visibly make girls relax when they were told

they would be paired with another girl. However, interviews suggested that girls were open to

pairing with boys and could also see advantages.

“I would probably go with the guy, ... coz everyone thinks that if you’re a girl you have to go with

a girl, it’s just saying that you don’t have to go with a girl.” (Sophie)

“so I’d have sort of girl boy girl boy coz then, otherwise it’s, if it’s girl boy boy girl or boy girl girl

boy the people in the middle could just talk.” (Emily)

4.2.3 Pair Programming as a social constructivist method

Four questions in the final questionnaire dealt with indicators of social constructivism in class. These

were taken from the CLES2 questionnaire.

The results to these questions were given a ordinal value and then analysed in SPSS to produce a box

plot (figure 8). 4 was the highest response (“Almost always”) and 0 the lowest (“Almost never”).

53

Figure 8 – Responses to social constructivism indicator questions

Students showed high levels of social constructivism in solving problems, explaining ideas. This

contrasted with a variation of responses in asking and being asked by partners to explain ideas which

may be related to a variety of maturity levels observed in participants. Results for the first three

questions are all high though.

Examples of social constructivism were consistently raised in interviews. Comments of helpful

behaviour, explaining and discussion were numerous.

“I’ve used Scratch so I kind of understand, but I didn’t understand it in Python, so I kind of asked

him to explain.” (James)

“I’d ask him, like, exactly what everything is so I can learn more of what he’s doing so that I can

understand.” (James)

In answer to how often they talked with each other:

54

“Pretty much whenever we had a problem we’d discuss it and someone would work it out.”

(Thomas)

The method was seen to produce “definitely more” (James) talking than had they worked on their

own computers.

Experimentation with the software was also raised in interviews:

“I had a lot of fun just fiddling around with all the code and everything.” (Jack)

This finding was supported from observations in the sessions. For instance, having solved a problem

with five squares one pair changed the variables to see what would happen. They made a hypothesis

before the code was executed which was then validated by the result in Figure 9:

James: “[I think] the square will turn to the left”

Josh: “yes, that’s it”

Figure 9 – Result of changing variable for angle of a square

A conversation illustrating the creative and collaborative nature of pairs was also recorded:

William: “that looks so cool... I like that... Put a hole in the middle... You could have a bigger

size... It looks like Mario... Harry, we made a mushroom... I’ll try 75 for the size... that’s a tree!”

Harry: “How many branches?”

William: “Just 3.”

It was evident in the interviews that working in pairs had aided a social constructivist style of

learning.

55

“so if it was my go I knew more, then we switched so I helped her sort of like get the first bit of it

and then when she got that bit she knew more and helped me so we just sort of went back and

forth with knowing more knowing.” (Emily)

4.2.4 Progress of students in Pair Programming

Types of problems Pair Programming solves

The tasks carried out by those in the Navigator role were varied and are revealed in figure 10.

Making suggestions to improve the problem were somewhat surprisingly the highest reported role

at 94% of participants. This shows an improvement to the iterative nature of developing programs. It

is interesting to note that in half of participants they had requested to takeover using the 2nd

keyboard. Interviews revealed that this had been aided by having two keyboards.

Figure 10 – Tasks carried out in the Navigator role

It is common when programming individually to be stuck on a problem of syntax which is difficult to

debug for beginner programmers. Finding bugs was an activity carried out by 63% of those in the

Navigator role and was reported frequently in observations.

63%

88%

50%

94%

50%

13%

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

Pe

rce

nta

ge o

f re

spo

nse

s

Tasks carried out in Navigator role

56

In the final questionnaire, participants were asked where they felt Pair Programming had helped

them. This was an open question which was coded into four categories. 50% mentioned a problem

related to syntax as their example (see Figure 11).

Figure 11 – Where pairs help to overcome problems

By contrast, when asked how a pair made it harder to overcome a problem, a clear majority (69%)

could not think of any examples of Pair Programming making it harder to overcome problems (see

figure 12).

Figure 12 – Where pairs hinder the overcoming of problems

0 1 2 3 4 5 6 7 8 9

Syntax Fun Ideas Help with problem solving

Nu

mb

er

of

resp

on

de

nts

Category of example

Coded examples of where working in a pair helped to overcome a problem

0

2

4

6

8

10

12

None Ignored by partner

Partner exhibited

selfish behaviour

Different opinions

Partner didn't trust

idea

Both stuck Nu

mb

er

of

resp

on

de

nts

Category of example

Coded examples of where working in a pair made it harder to overcome a problem

57

Illustrations of help solving syntax errors were numerous.

“I probably missed something and then they found it and they put it in and it worked... it was a

different thing where it was a colon and I just completely missed.” (Josh)

“I forgot to put the bracket bracket and then James pointed it out to me.” (Thomas)

Interviewees felt that the use of Pair Programming was efficient and allowed for cooperation whilst

reducing workload.

“I don’t think that having a partner is so that you can sit back. I agree that you need to relax while

it takes a bit of the weight off your shoulders and everything is better done in twos. I think that

you should both equally help each other out... I work better in partners.” (Jack)

Progress

Whilst no control group was studied, it is possible to show progress of students by the quality of

code they were producing. No help in programming design or ideas was given by the teacher during

the sessions, beyond a 5 minute whole class introduction. These solutions should be contrasted with

the simple examples given in the student booklet (Appendix E).

58

Code (Daniel & James) Output

Table 1 – Creation of a new procedure

The code in Table 1 shows the development of a new procedure called triangle. The pair then

realised that they could call triangle from within a new procedure of their own naming, “woob”. This

showed a high level of understanding of procedures after just 40 minutes of programming

experience.

59

Code (Samuel & William) Output

Table 2 – Customisation of a fractal algorithm

A tree fractal had variables changed to customise it, along with an adaptation to make the root

branch spiral (Table 2). Further customisation shows the extent of experimentation. This code is

from Session 3 after around 2.5 hours of programming experience.

60

Code (Thomas & James) Output

Table 3 – Creation of a Snow procedure

Code for a Koch fractal (snowflake) was given. The adaptations in Table 3 show the development of a

new procedure snow() which can call the Koch fractal function. Creativity is again evident. This code

was completed after session 3.

61

Code (Jamie & Sam) Output

Table 4 – Use of code found on the internet

62

In session 3, Jamie’s pair found a different fractal along with other functions from the Turtle API to

produce an original shape (Table 4). This shows confidence in reusing other code.

Figure 13 – Use of nested IF statements

The use of while and nested if statements were evidenced in Thomas, James and Daniel’s group of

three.

63

4.3 Summary of Findings

This chapter has looked at the results and findings from questionnaires, observations and interviews.

Key findings are as follows:

1. Students enjoy programming in pairs

2. Students would prefer to program in pairs rather than individually. Partners assist them in

explaining concepts and discussing ideas

3. Partners have a major contribution in helping to debug code and find syntax errors reducing

frustration in novice programmers

4. The use of a clock in giving control to each partner is seen as fair and reduces arguments in

pairs

5. The use of two keyboards improves the efficiency of changeovers and increases

collaboration in pairs

6. High-fiving and shouting “awesome” at the changeover has mixed effects. It assists in

delineating each turn but can cause disruption. It is only appropriate for pre-teen students

7. Students want to be paired with a partner who they perceive to have the same ability as

themselves

8. Students rate their success of a partnership higher if they are paired with a partner who they

perceive to have the same ability as themselves

9. Students enjoy Pair Programming more when they are paired with a partner who they

perceive to have the same ability as themselves

64

Chapter 5 - Discussion

5.1 Outline

The structure of this chapter matches the two research questions. Student’s perceptions of the

method employed in Pair Programming are first discussed. Although perception of partner ability

was found to be significant, these are discussed in section 5.3 when answering the second question

on the most constructive ways to pair students together. In this section, heterogeneous and

homogeneous pairings by ability are discussed. A theory is developed as to why Pair Programming

requires homogeneous pairs. Finally, to show that Pair Programming and pairing by ability is

constructive in the progress made by students, program code is compared against common

standards.

5.2 What are the perceptions that students in secondary education have towards

Pair Programming?

Overall perceptions of Pair Programming

Students overwhelmingly enjoyed their experience of paired programming. This was consistent

across data collection instruments with superlatives given in some descriptions and the majority of

students rating sessions as excellent. Students also showed how they overwhelmingly wanted to pair

program again in the future. These findings are consistent with improved learning experience found

in the tertiary sector by Nagappan et al (2003), Hanks (2006) and Salleh (2012).

Participants commented about partners assisting with the efficiency and refinement of programs.

These are again consistent with findings at university level by Williams & Kessler (2003) & Slaten et

al. (2005). Pair Programming has been shown to lead to improved attitudes towards programming

and Computer Science at tertiary level (Braught & Wahls, 2011) along with improved retention rates

along with increases in students choosing Computer Science as a major (McDowell et al, 20003;

Carver et al, 2007). This study did not compare Pair Programming against solo programming so direct

comparisons are not possible. However, exceptionally positive responses were given towards Pair

Programming and levels of enjoyment across all data collection instruments. Comments were given

65

in person and by email for weeks after the study requesting more programming sessions. The results

suggest that Pair Programming could increase the take up of Computer Science in later years and it

has been demonstrated to provide a positive experience across gender and ability. Mendes et al

(2005) find that positive outcomes of Pair Programming occur even when not part of a formal

course. This study supports the finding at secondary level.

Students often stated in interviews that having a partner helped them to explore more ideas in the

same way as Simon & Hanks (2008) found in the tertiary sector. The amount of peer help given was

high in all sessions. Williams et al (2002) and Nagappan et al (2003) found that they had more

productive and less frustrating lab sessions at tertiary level. Observations during sessions and

interviews would partially support this finding at secondary level. When pairings were successful,

sessions would almost run themselves with a high level of productivity and little frustration to

students or teacher. However, if incompatible pairs were made and arguments occurred, then this

could negate the harmonious atmosphere of the class. Through careful behaviour management, this

was not a major problem in the study; however, the results shows that findings from the tertiary

sector are not always perfectly applicable to this younger age group.

Perceptions of the method used for Pair Programming

Lewis (2010) found that a large amount of time was spent in mediation of pairs gaining control. Most

difficulties were eliminated (Lewis, 2011) by the use of a 5 minute clock and assigning A/B letters to

each student. This study found agreement with the length of time at 5 minutes with participants

perceiving this to be a fair amount of time which would prevent them from getting bored in either

role. Changing partner assignment from A/B to Left/Right in this study led to elimination of

confusion and teacher mediation was almost never required.

Lewis (2011) found that the Navigator role lost focus and had to frequently be reminded to pay

attention. This was not observed or commented on in this study. Less rigidly defined roles and a dual

keyboard setup are likely to have been responsible for this reduction. Students were positive in their

reaction to using two keyboards during interviews. They did occasionally mention difficulties of

“spamming” keyboards with random keystrokes and other disruptive behaviour by a partner. Whilst

this was an observed disadvantage, it was easily managed with teacher intervention and in extreme

cases one keyboard could be implemented for a particular pair. The use of two keyboards was an

efficient way to cede control to a partner. This finding is consistent with tertiary education where

66

students interchange the role of Driver and Navigator (Chaparro et al, 2005) and industry where

blurring of roles is common with dual keyboard use (Chong & Huributt, 2007).

The use of a high-five was found to assist in the delineation of which partner was in control. Lewis

(2011) used 28s discussions to help assist students to collaborate. This was proposed in one

interview, but not seen as favourable, instead it would simply be used to repeat points already

made. High levels of discussion and help were observed in sessions and additional time for

discussion is not seen as beneficial unless it has a specific purpose such as evaluation. Students felt

in interviews that the use of high-fiving and shouting “awesome” during the interchange was third in

importance to the clock and dual keyboards. They felt that this would only be appropriate for pre-

teen students. Observation showed that this could be disruptive with some pairs; however, it did

provide an additional mechanism for delineating that changeover had occurred. The technique also

made it clear to the teacher any students who had not changed role. Students raised the same

advantages and disadvantages.

5.3 What are the most constructive ways to pair students together?

Pairing by ability

This study found striking evidence for homogeneous partnerships being best suited to Pair

Programming in secondary age students. It is important to emphasise that it is the perception of a

partner’s ability which is important, not their actual ability. This confirms that findings at tertiary

level by Katira et al (2005), Luid & Chan (2006), Braught et al (2010) and Williams et al (2006) apply

to secondary students too.

Student’s perceptions at the end of each session were that “Excellent” pairs had been created in

83% of homogeneous pairings but this rating was only applied to 61% of heterogeneous pairs. For

those who rated their pair homogeneous, the sample size was 29; for heterogeneous, the sample

size was 18. Whilst this sample is small, triangulation of other data collection methods converged on

this finding.

The two sessions which were most successful were session 1 and session 4. The first session

contained only homogeneous pairs. Whilst the final sessions had some heterogeneous pairs these

were due to participants requesting them to maintain friends as partners are due to previous

successful partnership.

67

By contrast, the second session was observed to be the most challenging in regards to arguments

from pairs and most challenging behaviour of the class. In this session, 57% of participants were in a

heterogeneous pair – the highest number of any session.

In the final questionnaire, 81% of respondents wished to be partnered with someone of the same

ability. Whilst the remainder wished to be paired with someone better than themselves, this is in

conflict with findings from end of session questionnaires but consistent with findings from Williams

et al (2006) at tertiary level.

Where partners were perceived to be more able, 33% of the participants rated the partnership as

“Bad”. This was the only time that this category was selected during the study. Interviews revealed

that participants wished to be paired with someone of more ability as they could learn from them.

However, they cited major negatives of partners with high ability which appear to have led to

unsuccessful pairings. Issues of trust and self-esteem seem to be major issues when a partner is

perceived to be higher ability. Where the partner is a friend, this provides the necessary trust and

comfort for learning and a successful partnership to flourish.

The finding that pairs should be homogeneous conflicts with studies in other Science subjects. Whilst

these studies find that heterogeneous pairings are preferable overall, they do not find this

consistently across all ability ranges. Carter & Jones (2006) found that heterogeneous pairings were

best for low ability partners with no detriment to their high ability partner. For middle ability

students, homogeneous pairs worked. These findings are still in conflict with those found in this

study and suggest that results from other Science subjects cannot be applied to the domain of

programming.

It is possible to form a theory of why Pair Programming in particular requires homogeneous pairs.

Jadud (2006) finds that for novice programmers in university, most problems which partners help to

solve are syntactic rather than semantic. Muller (2007) finds that the number of algorithmic

mistakes are the same for Pair Programming and solo programmers, but that syntax errors are

reduced. The partner’s role in debugging code at secondary level was evident from the findings of

both Denner & Werner (2007) and Werner et al (2009). The findings of this study agree that

debugging code was a key Navigator role, with 63% of participants doing this during the study. When

asked in an open questionnaire question how a pair helped to overcome a problem, by a significant

margin, syntax related examples were given. These made up 50% of all examples given. Syntax

examples were also raised in interviews as a source of frustration which was alleviated by having a

partner.

68

Programming in a text language is unique in that it requires a perfect solution to be created. For

novice programmers, they must deal with not only the syntax of a new language, but also

algorithmic problem solving techniques. When minor errors are made, the compiler or interpreter is

unforgiving. This can lead to a high level of frustration and cause some students to give up.

Furthermore, cryptic diagnostic error messages use language beyond the knowledge of a beginner

programmer. A partner is therefore preferable for novice programmers. It is felt that this partner

needs to be of similar ability for a number of reasons. Firstly, they would get frustrated if constant

syntax errors were made which they found elementary. If though they are the same level, then

trying to find the error becomes an intriguing opportunity for surprise or confusion. This

disequilibrium is required for a Piagetian style of learning (Wadsworth, 1978).

A further reason for students to work better in homogeneous pairs is that of the Zone of Proximal

Development (ZPD). Teachers are seen as too far from the development levels of young adolescents

to be within the ZPD (Shayer, 1997). This was found to be true in the wishes of interviewees in this

study not to be paired with someone as capable as a teacher. Clear comments were made in

interviews that whilst lower or higher abilities were okay they should not be extreme. These

comments alluded to a child interpretation of the ZPD. Vygotsky (1978) defines the ZPD as a 9 year

old being able to achieve that of a 12 year old with a more knowledgeable other (MKO). Within

normal activities and learning this may be possible. However, programming with a text language

requires a high cognitive load and many concepts must be understood and assimilated in the early

stages of learning to program. It is therefore felt that programming has a tighter ZPD than perhaps

other subjects do. This leads to a greater need for homogeneous ability pairs. Given the large

number of concepts to learn and the imperative of code being perfect, it is felt that collaboration

with similar ability peers is preferable to more capable peers.

The activities created scaffolding for programming concepts as advised by Bruner & Schmidt (2011).

This scaffolding allowed for such discoveries as user created procedures and recursion. The first of

these was discovered by some pairs, but none discovered how to create recursive functions –

although many were capable at using them. Recursive functions are seen as examples in

programming of the Piagetian Formal Operational Stage. Inhelder & Piaget (1958) felt this began at

age 11, and given the participant ages and their inexperience of programmings, it is unsurprising that

they did not master this concept.

Lewis et al (2011) paired secondary level students randomly for each session. In this study, the only

session which attempted to do this was the first; however, students were allowed to pair themselves

and did so by friendship. All of these partners were deemed to be perceived as the same ability. In

69

the final session students were paired by same ability or if they requested by friendship. This had

equally successful pair compatibility. The findings suggest that random pairs should only be

employed in the presence of no other information and no existing friendships. The interviews

revealed the importance of friendship to the extent that where friendships didn’t exist, it would be

preferable to facilitate friendships before programming began:

“Let the students do a bonding activity so that they can get to know each other very well.” (Jack)

Play and Constructionism

In discussing pairings being constructive, we should not ignore the number of times which play was

identified in the study. This was seen in class observations and commented upon during interviews.

Play had importance to Vygotsky (1978) and learning through play was one of Bruner’s (1972) three

stages of learning. There were numerous examples of students discovering concepts for themselves

in this study and a high level of congruence with Papert’s (1980) “constructionism” was evident.

Questions from the CLES2 survey indicated high levels of social constructivism being employed.

Reduction in teacher burden

Williams et al, (2002) and Nagappan et al (2003) reported more productive and less frustrating lab

sessions. This study found the same to be true in most sessions except session 2. Where pairs were

mainly heterogeneous, arguments were increased to a level which caused much frustration and

decreased productivity. With young adolescents, it is felt that the advantages of Pair Programming

are only fuller realised with homogeneous or friendship pairings.

Cliburn (2003) found that the burden on the instructor at tertiary level to help solve problems

reduced by 25% for Pair Programmers. This was due to participants being able to solve their own

problems. Whilst this study did not compare pair and solo programming it does reveal results about

teacher burden. Where pairs are homogeneous, the teacher burden was extremely low with

students consistently able to solve their own problems. With heterogeneous pairs, these sometimes

needed more assistance, but this was not arduous if the pair had requested to be partnered,

typically due to friendship reasons. Where heterogeneous pairs were forced on participants this led

to a significant extra burden on the teacher which negated any benefits which Pair Programming

may have produced. Younger students have more difficulties in controlling their egotistic behaviour

and often present disruptive behaviours when content is too difficult. It is likely that this contributes

to the less productive behaviours when heterogeneous pairs are deployed.

70

In addition to helping to debug code, this study found evidence of higher order thinking skills and

reflecting on code similar to the findings of VanDeGrift (2004) with older students. A highly

unexpected result found in interviews was that the countdown timer forced some participants to try

and complete an idea within a time limit. This led to them considering different solutions which were

easier and more elegant. Simon & Hanks (2008) found that more ideas were explored in Pair

Programming at tertiary level, and this was in observations and interviews in this study.

Progress of students

It is possible to show some level of progress through the test results at the end of each session (See

Appendix Q). Some participants achieved full marks or very high marks in these tests with some

questions being far from trivial. Other students achieved low results showing low levels of progress.

Had this study had more participants it would be possible to perform a quantitative study in whether

lower ability students progressed to the same degree as high ability, but with a sample of only 10

completing all sessions this was not possible.

It is not possible to show in this study how progress of students alters between pair and solo

programming as no solo group was studied to make comparisons. Nevertheless, to some degree,

such a comparison would have its own validity issues. Papert saw a Piagetian style of learning as

“learning without curriculum.” (Papert, 1980, p31). As such examinations and tests do not in

themselves reveal the whole array of education and learning which takes place in a collaborative

learning style.

It is clear that participants learnt many additional soft skills such as conflict resolution, alternative

solutions and collaborative learning which are difficult to assess in a quantitative analysis. We should

also not ignore the positive effects of Pair Programming on the perception of enjoyment of sessions

(81% rated it as “Excellent”) and also the willingness to have more programming lessons in school

where 94% felt this was “Excellent”.

Given under 4 hours of programming experience, many programs evidenced programming concepts

in the upper levels of expectations for Key Stage 3. The progression pathways (Dorling & Walker,

2014), endorsed by CAS have 8 levels. Although these are not numbered, the following analysis

numbers them with 1 as most simple and 8 as most advanced. Daniel & James in the first session

realised that they could produce a new procedure named “woob” employing a procedure call later

in the program. Writing and debugging procedures is level 4. All pairs showed experience of high-

level textual languages which is level 5. Jack & Joseph in the fourth session demonstrated use of

71

nested if statements which is level 6. Thomas & James showed an accomplished level of parameter

passing with a Koch fractal to make a snow() procedure which is level 7.

These vignettes of achievement illustrate the high levels of progress in programming evidenced. It is

without doubt that the pairs worked in a constructive manner and made excellent progress.

5.4 Summary

This discussion has shown a high level of similarities between the research literature in Pair

Programming and results of this study. Student’s perceptions of Pair Programming at the secondary

level are that they enjoy it and would like to do it again.

Students find that a clock which instructs them to change control every 5 minutes is useful and

arbitrates disagreements. They see this as the most important technique to encourage successful

Pair Programming. A dual keyboard is useful in students being able to share control and increases

efficiency amongst pairs. It must be cautioned that partners need sufficient self control to prevent

the development of behavioural issues. Emphasis on changeovers beyond a clock buzzer is

important, though does not have to be employed in the manner given in this study. For older

students the method of changeover used in this study is not appropriate.

The findings show that students prefer to be paired in homogeneous pairs which correspond to

findings of Pair Programming in the tertiary sector. When paired this way, students have a higher

probability of being in a constructive pair. Students believe there should be diversity in pairs;

however, this is more for ideas rather than ability. For novice programmers, the ZPD appears to be

tightly confined. These findings differ to studies in other subjects with secondary level students. It is

likely that the unique nature of text programming with its requirement to implement perfect syntax

contributes to this difference.

72

Chapter 6 - Conclusion

6.1 Outline

In this chapter the original research questions are considered taking into account the results,

analysis and discussion. An answer is offered to these questions and in the case of ability pairings a

theoretical explanation is posited. In the limitations section, alternative ways in which these

conclusions could be found are suggested along with the limitations of the methods employed.

Further areas of study are suggested.

The final section of this chapter shows not only how these conclusions contribute to knowledge of

Pair Programming, but also the implications of this within the Computer Science classroom. Finally,

recommendations are given as to how programming can be taught in the secondary classroom using

text languages.

6.2 Key findings

The first research question considered the perceptions that students in secondary education have

towards Pair Programming. These perceptions were found to be remarkably similar to those of

students in the tertiary sector. Positive perceptions were in improved learning experience, as found

by Salleh (2012), improved attitudes towards programming (Braught & Wahls, 2011), and high levels

of a desire to program in the future similar to the findings of Carver et al (2007).

We cannot assume that young adolescent students, as studied in this research, will react identically

to those of adult students though. Lewis (2011) made a number of additions in how Pair

Programming should be deployed in the classroom. The refinements made to these in this study

were overwhelmingly supported by students. In particular, a clock was helpful in creating fairness

amongst partners. The use of left/right rather than A/B eliminated problems associated with

remembering letters. A method of improving changeover was employed in this study with some

success; however, feelings towards high-fiving and shouting ‘awesome’ were mixed. With pre-teen

students, this can be considered effective, but alternatives which a teacher is more comfortable with

may be preferable. With teenage students this method is not seen as age appropriate.

73

The use of dual keyboards within this study increased the level of collaboration from students. It

assisted in the efficiency of changing partner and helped to blur the roles of Driver and Navigator.

This is a catalyst for encouraging collaborative behaviours seen at tertiary level (Chaparro et al,

2005) and industry (Chong & Huribult, 2007).

The second research question considered the most constructive ways in which students are paired

together. This study focussed upon the ability of students. It is clear from the results and analysis

that students have a preference for partners of the same ability. Furthermore, participants who have

been in homogeneous partnerships rate the pair’s effectiveness significantly higher than those in

heterogeneous partnerships. These findings support the hypothesis of Lewis (2011) and findings

with adults by Braught et al (2010) and Williams et al (2006).

Differences with young adolescents are evident. Friendships are important for young adolescents

and feeling safe or comfortable is key to allowing students to freely participate in discussion and

learning in a pair. Within a friendship, heterogeneous pairings can be successful. By contrast, where

friendship has not been established, the more able student will “take over” due to frustration, whilst

the less able partner will “sit back” to protect self-esteem.

This study found that the highest success in partnerships, as perceived by participants, was to pair by

perceived ability and friendships. Pairing by ability was successful as long as the data for pairings was

sufficiently robust. Pairing randomly was not likely to generate the best quality partnerships and this

should be avoided where possible.

Pairs were shown to be constructive by the quality of source code produced which tackled difficult

topics. Many of the concepts tackled were at the higher end of expectations for Key Stage 3

students, despite this being their first formal experience of programming and the majority of

participants being in year 7.

The finding that the best way to pair students is by homogeneous pairs is successfully framed within

a Piagetian learning style. Participants in interviews gave a desire for partners to be in a range of

similar abilities analogous to Vygotsky’s ZPD, albeit a tighter range than normally expected.

74

6.3 Limitations

The research questions were answered by a mixed methods approach with results triangulating

upon a common theme. Whilst this has had some success, there are clear limitations. The sample

size was not large enough to see whether Pair Programming with homogeneous pairs had a positive

effect across ability ranges and further study into this area would be beneficial. This study does

however show that partnerships by friendship are successful and could be suitable for low ability

students where they are possible.

Coman et al (2013) find that for professional programmers and more advanced university students,

solo programming can be more efficient when cooperative work is required instead of collaborative.

This study considered novice programmers in their first 4 hours of programming. Caution should be

made in extrapolating the results for longer periods of time. A longitudinal study would be welcome

to study this effect.

Students were self-selected in their participation. It is possible that they had higher motivation

towards computer related subjects and higher ability overall, however, test results show a range of

abilities amongst participants.

Results of the method suggested the clock and dual keyboards to be particularly advantageous.

However, these judgements were made qualitatively from perceptions and observations. A

quantitative study using a control group could study the effect size of each of these variables to

obtain a more conclusive result.

This study aimed to study ability pairings and as such was set up to investigate this variable.

Inductive open coding of interviews resulted in the importance of friendship in partners being

revealed, a result borne out from the data in end of session questionnaires. This and further factors

such as personality type could be investigated in more detail.

75

6.4 Recommendations and Implications

This study finds significant results in how young adolescent students should study Pair Programming.

The following recommendations are therefore made:

1. A clock should be used with a 5 minute countdown. This will assist students in having a fair

amount of time in control of the computer

2. Two keyboards should be used to improve the efficiency of ceding control to a partner. In

addition this improves the collaborative nature of programming

3. Students should be paired by similar ability. If they have a preference for pairing with a

friend then this should be allowed

Figure 14 – A strategy to pair students in Pair Programming

76

Figure 14 shows a strategy to be employed in pairing students for Pair Programming.

These findings have significant implications for the teaching of Computing in secondary schools. In

the current economic climate, school budgets are under increasing pressure. The general

expectation is that IT suites should have one computer per student. This may have been true for ICT

as a subject, but the findings of this study suggest that for novice programmers, one computer

between two is a superior allocation. Having experienced this method, the majority of students

would prefer to continue Pair Programming in the future. As such, ICT suites could be converted to

Computer labs with modest cost savings in the quantity of hardware required.

Word count: 19,958 words

77

Chapter 7 - Appendices

Appendix A – The Moodle course

Figure 15 - The course layout

The information sheet was made available before, during and after the course running. This meant

that if students lost their sheet for any reason they would still be able to access a copy. The course

was only accessible by myself as teacher and researcher and any participants who had said that they

would attend sessions. Pupils could see participants in the course, but no other information such as

student work.

78

Students submitted python programs they had written in pairs to the system. This recorded the

name of the person who submitted. Pairings were recorded, with only one submission required for a

pair.

Figure 16– Example of teacher area to collect Python source code

79

Appendix B – Quiz questions

Four quizzes were setup as post-tests at the end of each session. Each of these is given in full here as

they appeared in the Moodle system:

Figure 17 – Day 1 Quiz

80

81

82

83

Figure 18 – Day 2 Quiz

84

85

86

87

Figure 19 – Day 3 Quiz

88

Figure 20 – Day 4 Quiz

89

90

Appendix C – End of session questionnaire

A questionnaire of 4 questions was given at the end of each session. This was included at the end of

the test so that students wouldn’t forget to complete it and to see a higher return.

Figure 21 – Standard questions asked at the end of each session

-

91

Appendix D - End of all sessions questionnaire

At the end of all four sessions, one questionnaire was given to each student to be completed

through Moodle.

Figure 22 – Final quiz

92

93

94

Appendix E – Student booklet for all four lessons

The following 16 pages are a copy of the student booklet. This was handed out to each pair in

physical form. They also had access to the booklet via the Moodle system and could download it in

the sessions or at home.

95

Figure 23 – Student booklet

96

97

98

99

100

101

102

103

104

105

106

107

108

109

110

111

Appendix F – Extension work for higher ability students

Figure 24 – Extension sheets

Extension

You probably want to change the turtle speed by using alex.speed(100) to make the fractals appear

faster.

Define a procedure to make a Koch fractal:

Now call the procedure

First call the Koch procedure with the most basic

fractal.

Now change how you call it

Change how you call it again so that it looks like

one side of a snowflake

112

Now make a new definition called snowflake

which will make a snowflake

Now make a new definition called snow which

will make multiple snowflakes appear

Finally – make a copy of your forest python file.

Adapt it so that it has snow inside it

113

Appendix G – Slides for initial introduction presentation

Students were initially shown slides that showed them the topics which would be covered in the four

sessions. The method of Pair Programming was also explained.

Figure 25 – Initial presentation

114

Appendix H – Student and Parent Information Sheet

INFORMATION SHEET FOR PARTICIPANTS

REC Reference Number:LRU-14/15-0851

YOU WILL BE GIVEN A COPY OF THIS INFORMATION SHEET

Perceptions by young people of Paired Programming when learning text languages We would like you to participate in this postgraduate research project. You should only participate if you want to; choosing not to take part will not disadvantage you in any way. Before you decide whether you want to take part, it is important for you to understand why the research is being done and what your participation will involve. Please take time to read the following information carefully and discuss it with others if you wish. Ask us if there is anything that is not clear or if you would like more information. The aim of this project is to find out perceptions of young people when learning how to program using a technique called Pair Programming where you work together with a partner. It aims to find out what aspects you like or dislike about the technique and how it helps you to learn. It will also investigate how teachers can best implement this technique to improve learning for you and other students. You have been selected to take part in the study because you are in Key Stage 3 and have not yet studied a text based language in school. If you agree and are selected to take part you will attend the following 4 sessions after school: Monday 18th May 4:00~5:15 Tuesday 19th May 4:00~5:15 Wednesday 20th May 4:00~5:15 Thursday 21st May 4:00~5:15 Within this time you will have a lesson where you learn how to program. At the end of each lesson you will have a short quiz on what you have learnt. This will take around 5-10 minutes and not affect your official academic grades in any way. During the lessons observations of your group and class will be made and notes will be taken. At the end of the fourth session you will also receive a short anonymous questionnaire to complete. About half of the people who participate will be asked to attend a focus group with 2-4 people at a time so you won’t be on your own. This will last about half an hour and be at a convenient time to you either within or after the school day. This focus group will be audio recorded so that it can be transcribed after which it will be erased. You may withdraw any data you provide through class observation or focus groups as long as this is before 2nd July 2015. Upon submission of the anonymous questionnaire, you will not be able to withdraw the responses provided in it. All sensitive information that could identify you or the school will be removed from any writing. Your identity and that of the school will only be known to the researcher and their supervisor.

115

There are no known risks to taking part in this research. There are benefits to taking part in this study in that you will learn how to program and also enable other teachers to improve the way in which they teach. You will be provided with a small snack or biscuits towards the end of each session in case you are hungry. If you have any questions or require more information about this study, please contact me using the following contact details: James Franklin james.franklin@kcl.ac.uk If this study has harmed you in any way or if you wish to make a complaint about the conduct of the study you can contact King's College London using the details below for further advice and information: Mary Webb mary.webb@kcl.ac.uk Thank you for reading this information sheet and for considering taking part in this

research.

116

Appendix I – Student and Parent Consent Form

CONSENT FORM FOR PARTICIPANTS

Please complete this form after you have read the Information Sheet and/or listened to an explanation about the research.

Title of Study: Perceptions by young people of Paired Programming when learning text languages King’s College Research Ethics Committee Ref: LRU-14/15-0851

Thank you for considering taking part in this research. The person organising the research must explain the project to you before you agree to take part.

If you have any questions arising from the Information Sheet or explanation already given to you, please ask the researcher before you decide whether to join in. You will be given a copy of this Consent Form to keep and refer to at any time.

I understand that if I decide at any other time during the research that I no longer wish to participate in this project, I can notify the researchers involved and be withdrawn from it immediately without giving any reason. Furthermore, I understand that I will be able to withdraw any data provided by class observation or focus groups up until the 2nd July 2015. Upon submission of the anonymous questionnaire, I understand that I will not be able to withdraw the responses provided in it.

I consent to the processing of my personal information for the purposes explained to me. I understand that such information will be treated in accordance with the terms of the Data Protection Act 1998.

I consent to my focus group being audio recorded and I agree to maintain the confidentiality of focus group discussions.

Participant and parent statements: I ____________________ [pupil name] agree that the research project named above has been explained to me to my satisfaction and I agree to take part in the study. I have read both the notes written above and the Information Sheet about the project, and understand what the research study involves. Pupil signature: ____________________________________ Date______________ I ___________________ [parent name] agree for my son/daughter to take part in the study. I have read both the notes written above and the Information Sheet about the project, and understand what the research study involves. Parent signature: ____________________________________ Date______________ Researcher’s Statement: I James Franklin confirm that I have carefully explained the nature, demands and foreseeable risks (where applicable) of the proposed research to the volunteer. Signed________________________________ Date______________

117

Appendix J – Headteacher Information Sheet

INFORMATION SHEET FOR HEADMISTRESS

REC Reference Number:LRU-14/15-0851

Perceptions by young people of Paired Programming when learning text languages

I would like to invite LVS Ascot to participate in my research project, which I am carrying out

as part of my Masters in Computing in Education dissertation studies at King’s College,

London. In the information that follows, I hope to make clear the aims of my project, how I

would involve your children, and how I would ensure their anonymity in any published work.

Aims of the Research

The aim of this project is to find out perceptions of young people when learning how to

program using a technique called Pair Programming. It aims to find out what aspects

students like or dislike about the technique and how it helps them to learn. It will also

investigate how teachers can best implement this technique to improve learning for you and

other students.

I have designed this study to be suitable for year 7 and 8 students as they have not yet had

any experience of programming with text languages.

What the students will be expected to do in the research

They will attend the following 4 sessions after school:

Monday 18th May 4:00~5:15

Tuesday 19th May 4:00~5:15

Wednesday 20th May 4:00~5:15

Thursday 21st May 4:00~5:15

Within this time they will have a lesson where you learn how to program. At the end of each

lesson they will have a short quiz on what they have learnt. This will take around 5-10

minutes and not affect your official academic grades in any way. During the lessons

observations of your group and class will be made and notes will be taken.

At the end of the fourth session they will also receive a short anonymous questionnaire to

complete.

About half of the people who participate will be asked to attend a focus group with 2-4

people at a time so you won’t be on your own. This will last about half an hour and be at a

convenient time to the participants either within or after the school day. This focus group will

be audio recorded so that it can be transcribed after which it will be erased. Data provided

through class observation or focus groups may be withdrawn as long as this is before 2nd

118

July 2015. Upon submission of the anonymous questionnaire, participants will not be able to

withdraw the responses provided in it.

All sensitive information that could identify a child or the school will be removed from any

writing. Their identity and that of the school will only be known to the researcher and

supervisor.

There are no known risks to taking part in this research. There are benefits to taking part in

this study in that the children will learn how to program and also enable other teachers to

improve the way in which they teach.

Participants will be provided with a small snack or biscuits towards the end of each session

as I appreciate that they may be hungry. This will be at my own expense.

I hope this makes clear how the children would be involved in my research project and the

benefits they will gain from it.

In line with the ethics policy of King’s College, I can assure you that your children would not

be identifiable in my research. Names of the school, the children and any teachers will be

changed to assure anonymity.

The findings of my research will be written up for my dissertation by August 2015. You will

be more than welcome to a copy of my research for the school. Any child involved in the

research would have the right to withdraw from the project at any time without giving a

reason.

If you have any questions or require more information about this study, please contact me

using the following contact details:

James Franklin james.franklin@kcl.ac.uk

If this study has harmed your children in any way or if you wish to make a complaint about

the conduct of the study you can contact King's College London using the details below for

further advice and information:

Mary Webb mary.webb@kcl.ac.uk

Thank you for reading this information sheet and for considering taking part in

this research.

119

Appendix K – Sample email to all students

Dear Year 7/Year 8, Are you interested in learning how to program Python and also help with some research? If so there is a great opportunity for you to learn some basics in programming after school from Monday 18th May to Thursday 21st May from 4:00-5:15pm. You will not only learn something but also be able to help other teachers learn how best to teach you. If you are interested then take a look at the information sheet attached. Then complete the following consent form below.

[A copy of the consent form in Appendix I was given below this in the email]

120

Appendix L – Code classification tree with frequency analysis

Figure 26 – Code classification tree

121

122

Appendix M – Codes and meanings

Codes regarding the method of Pair Programming employed

CLOCK 5 minute timer to show when to switch driver/navigator role

EFFICIENCY Effect on the efficiency of the pair in programming

ARBITRATION Technique effect in arbitration of disagreements

FAIRNESS Fairness of a technique

DUALKEY Use of two keyboards on one computer

SHOUT Technique of shouting "Awesome" when changing driver/navigator role

AGEAPPROPRIATENESS Appropriateness for an age group

BELL Use of a bell or alarm to signal changeover

CHANGEOVER Changeover of partners

SHAKEHANDS Alternative to shake hands rather than high five

HIGHFIVE Technique of high-five at changeover

ROOMSPACE Roomspace for arrangement of keyboards and mice

DUALMICE Use of two mice on one computer

ALTERNATIVEIDEA An alternative idea for a technique

LENGTH The length in driver/navigator role before a changeover

THREE A group of three on one computer

30SDISCUSS Alternative 30 second discussion at changeover

WORD The word shouted at changeover

GENDERTOPIC Different topics more suited to girls

Codes regarding how to construct pairs

FRIEND A friend as a partner

FEAR A fear as to a certain partner

DIVERSE Diversity of partner

ARGUE Arguments in a partnership

KNOWLEDGE Knowledge of a partner

SELFISH A selfish partner

INTERESTS The interests of a partner

SAMEABILITY The same ability of a partner

TAKEOVER A partner taking over all the work in a partnership

SITBACK A partner doing nothing in a partnership

COMFORT Feeling comfortable in a partnership

EGOTISM A partner showing egotism within a partnership

ENJOY Enjoyment of Pair Programming or working in a partnership

INFERIORITY Feeling inferior to a partner

LISTEN Listening to a partner

DISRUPTIVE A disruptive partner or pair

ZPD Zone of Proximal development

123

SELF-ESTEEM Partners contribution to self-esteem

RANDOM Random assignment of partners

RELATIONSHIP Relationship of partners

ABILITY Ability of a partner

PERSONALITY Personality of partner

MOTIVATION Motivation of a partner or pair

ALTRUISM Altruistic behaviour or propensity

FRUSTRATION Frustration with partner

COOPERATE Cooperation of partners

PAIRPREF Preference for a pair

WORKLOAD Workload within a pair

EFFICIENCY Efficiency of a technique

HIGHERABILITY Pairing with someone of higher ability

LOWERABILITY Pairing with someone of lower ability

ATTENDANCE Reasons for not attending all sessions

GENDER Gender comments

PRODUCTIVE Productivity of a partnership

CHOOSE Ability to choose own partner

PAIR General comments on a pair

Codes regarding social constructivism

EXPERIMENT Experimenting with the computer language or play

IDEAS Generation of ideas within a pair

EXPLAIN Partner explaining a concept or idea

TEACH Partner teaching

HELP Partner helping

DISCUSS Partner discussing idea or concept

UNHELPFUL Partner being unhelpful

LEARN Partner learning from partner

ASK Partner asking question

SHARING Partners sharing task or learning

EXPLAINOTHERGROUP Explaining something outside of pair

Codes regarding programming issues

SOLVPROB Help solving a problem

SYNTAX Help solving a syntax problem

ALGORITHM Help designing an algorithm

124

Appendix N – Interview 1

Interviewer: Welcome back. You have been invited to a follow up

interview today because you attended one or more of

the Pair Programming sessions last half term. This is

voluntary so you are free to leave now or at any time

during the interview. This interview is being recorded. It

will then be written down and the recording will be

deleted. Your names will be changed when it is written

down so anything you say will be anonymous. If you

don't want a comment included then you can tell me

during this interview, or at any time up until the end of

term. This interview will allow you to give more

information about what you thought about the sessions

on Pair Programming. Do you have any questions or is

there anything you would like clarified?

Josh & Jack: No

Interviewer: So we're going to look at three topics. First of all to do

with partners and then the method if we have time.

Interviewer: My first question to you before we start though is, what

do you think of everything overall?

Josh: I thought it was very good. I think the techniques which

you use with the stop-watch are really, quite, effective

and efficient; because then there was no arguing and

wasting time; because there was an easy split and it was

equal.

ENJOY CLOCK

EFFICIENCY

ARBITRATION

FAIRNESS

Jack: Well it was actually a lot of fun. I had a lot fun just

fiddling around with all the code and everything. I made

this weird game or something and, yeah, like Josh said,

since there were no arguments over keyboard control

because of the stop-watch.

ENJOY

EXPERIMENT

ARGUE

ARBITRATION

CLOCK

Interviewer: Okay we'll come back to some of those bits later. I just

want to look at the aspect of partners first. Obviously

you can work with lots of different people. This is

looking at how you choose those partners. What would

be your ideal partner to work with?

Josh: It would be a friend that you know really well, so that

you, so then you can speak through with them your

ideas. Sometimes if it's someone you don't know you

get a bit nervous and you don't really speak freely.

FRIEND DISCUSS

FEAR

125

Jack: Like Josh said, a friend that you know really well and

someone basically that has an open mind so they won't

just not let, stop you doing what you want and just do

what they want; so someone with an open mind and a

friend.

FRIEND OPEN

SELFISH

Interviewer: Okay let's say that I gave you 15 different people to pick

as a partner and all of them were your friends. They are

all equally your friends and you know them the same

amount - I know that's hard to imagine - They are

exactly the same and you feel you can talk with all of

them. Now who would you select from those 15? What

sort of things would you be looking for?

Josh: I'd look for someone who thinks the same as me on

some aspects, but differently on others, so you have

quite a bit to discuss about, but you don't if you thought

differently completely you would just keep arguing

which would not be good.

DIVERSE ARGUE

DISCUSS

Jack: Like Josh, some sort of diversity. A bit of diversity, but

you also need to be able to think the same, like Josh

said.

DIVERSE

Interviewer: What sort of diversities would you think...?

Jack: Well different, well basically you think differently, do

things differently. But not to the extreme where you're

unable to cooperate, but just, you know.

DIVERSE

Interviewer: What dort of things will create an extreme?

Jack: Well someone that will only do it their way, no one

elses way; won't accept what you want and what you

have to say about it. That's the extreme.

SELFISH DIVERSE

Interviewer: Let's say now that on the extremes, those 15 people are

not only all good friend, and you're quite happy to say

what you think. You have no problems, you'll say your

view, they'll say their views. You have no problems with

them and it's very equal. What else might you look for?

[pause]

Interviewer: I know this is a difficult question; but what do you

reckon Josh?

Josh: Erm. Well I think someone who you've known the

longest.

FRIEND

Interviewer: I've taken that out though. You're all friends and you've

known them the same length of time and you can speak

freely with them and they won't take over and will give

you the right amount of time. You both said that you

want differences. How much difference do you want

and what will those differences be?

126

Josh: Well, sort of, the differences would be, so they have

different methods of doing things, but the similarities

would be, you don't argue, you like the same things, so

if you're doing a game and you like the same things, you

wouldn't argue about what to have in it.

ARGUE DIVERSE

INTERESTS

Jack: Same as Josh.

Interviewer: Let's look at people's abilities now. Obviously everyone

is different, in every class some things people are better

and some people are not so good. You said that you

wanted diversity, you said that you wanted people to

have different ideas, but thinking of their ability,

assuming everything else is the same, what sort of

person would you go for?

Jack: I'd go for someone who has the same ability as me,

because if they have done it longer and they're more

experienced at it they know a lot better than me; they

might just take over and not let me do anything. If there

is someone that has less ability than me, then they

might just sit back and watch me do everything, so I

wouldn't like that either.

SAMEABILITY

TAKEOVER

SITBACK

Interviewer: Let's say that they didn't take over and they didn't sneer

back, so you now have the perfect person, but you have

this ability difference. You can now choose out of these

14 people they have all different abilities, but you know

that they're not going to take over, they're not going to

sit back, they're going to be a perfect partner; you have

all different abilities though. Which one are you going

to go for?

Jack: I would say the same amount still. It makes me feel

comfortable.

SAMEABILITY

Interviewer: What makes you feel comfortable?

Jack: Well if we forget something they'd be able to help me

out and I'd be able to help them out. In the middle it's

just like, you'd be a bit more comfortable; I can't

explain.

HELP COMFORT

Interviewer: That's okay, it's a difficult question. Josh what do you

reckon? Work with someone the same or different?

Josh: Well I would reckon the same, because if they were too

good for you; if they weren't good enough, so they

didn't have a very good ability then you might just take

over completely and then get into your own head and

become quite cocky because they do nothing and you

could start calling them dumb and stuff. And if they're

really good you could just feel like your stupid because

you can't do anything compared to them.

SAMEABILITY

TAKEOVER

EGOTISM

INFERIORITY

127

Interviewer: Okay. So if I said you've got a choice, everything else is

equal, you've got a choice of high ability, same ability,

lower ability, what would you pick?

Josh: Same SAMEABILITY

Jack: Same SAMEABILITY

Interviewer: If I now gave you a choice, and I said to you, out of

these 15 people you only have 7 who are better than

you and 7 who are worse than you, what would you

pick now?

[Long pause]

Jack: How many, how big can one group be?

Interviewer: Oh no - so you're picking one person from the group,

but half the group are better than you and half the

group are worse than you. Which one would you go

for?

Josh: I'd probably pick the one better. Actually no, the one

who isn't as good as he is, because then I would help

them along and make them the same as me, I'd like

teach them all the knowledge that I had so that then we

could work together.

HIGHERABILITY

LOWERABILITY

TEACH

Interviewer: Why do you think you said better first?

Josh: I thought for a minute that maybe I could... I said the

wrong thing.

Interviewer: What do you reckon [Jack] - you can disagree or agree

Jack: I'd pick the person that had a worse ability than me,

because like Josh said I can teach them and maybe the

person that's better than me might not be, well they

wouldn't teach me everything they know.

LOWERABILITY

TEACH EGOTISM

Interviewer: Okay. There would undoubtedly be some people who

you really wouldn't want to partner with. What would

that person be?

Jack: Someone that would listen to you. Someone that would

try to just take over. They wouldn't listen to what you

had to say and might just be annoying when it's your

turn and just keep typing random things into.

LISTEN TAKEOVER

DISRUPTIVE

Interviewer: And what do you think?

Josh: Mostly the same; and they'd be really cocky and just

mess around. And when it's their go and your doing

something, they wouldn't help, they'd talk to someone

else.

EGOTISTIC

DISRUPTIVE

UNHELPFUL

128

Interviewer: When you said that they'd be cocky, lets say now that

you had someone better than you, but this time you

know that person will not be cocky and you know that

their going to actuallly want to help you out. Now on

the other side you know that one person will want to

help you and the other person will be happy to take

your help. Which one would you now pick?

Josh: I'd pick the one with less ability, because after I'd feel

much better about myself. Because I'd have someone

whose got more knowledge; whereas if I'd picked the

one whose higher than me and they taught me, the only

person who is getting anything out of it would be

myself, which would be a bit selfish.

LESSABILITY SELF-

ESTEEM SELFISH

Interviewer: Okay. Do you agree or disagree?

Jack: Erm. I'd choose the person who has more ability than

me so I could erm learn from them; then next time I

could choose someone who has less ability. At least I

could pass down that knowledge.

HIGHERABILITY

LEARN

LOWERABILITY

TEACH

Interviewer: Okay. Let's go, Josh, now and say that you've got two

people and this time you don't get on as well from

them. You've been told by the teacher that you have to

go with one of these two people. One's better than you

and ones not as good as you. The one who isn't as good

will take your help and the one who's not as good will

help you, but you don't really get on with them. You

don't want to work with them. Now who would you go

with?

Josh: That's a really hard question. If it was the one better

than you they would just take over

Interviewer: They won't take over, you just don't really like them

Josh: Oh.

Interviewer: Everything else is the same, but you just don't like them

as much, they're not your friend.

Josh: I'd pick the one who is worse because maybe I could

help them and then maybe we could become friends.

Coz I've helped them.

LOWERABILITY

HELP

Jack: I'd also choose the person who didn't have as much

ability as me, because perhaps maybe the other person

could try perhaps snobby to me, do everything to be

generally nasty. No just actual, be mean to me; but with

the person that had less ability than me I could teach

them like Josh said. And they can't really be actual

snobby to me.

LOWERABILITY

EGOTISTIC FEAR

TEACH

129

Interviewer: Let's now ask, what advice would you give a teacher. If

you could say to them, this is how you should pair

people together, what do you think you would tell them

to do?

Jack: I think I'd start to let the students pick their partners

entirely. But if there's any arguments - well have the

students write their three top choices maybe, and then

they can, and then if one of those people are taken they

can go to the other two.

RANDOM ARGUE

Interviewer: What do you think?

Josh: I would probably go the same. But I say that if people

are messing around I would split them up, coz then they

won't work effectively and they can't distract everyone

else.

DISRUPTIVE

Interviewer: Let's say that you've got a brand new class, so like when

you started in year 7, so the whole class is new and they

don't know anybody at all. So the teacher now has to do

it and the students won't have any knowledge about

who is best to pair with. How would you now advise the

teacher to do it?

Jack: Maybe, if it's more than just a one off session, let the

students do a bonding activity so that they can get to

know each other very well. Then after that on the

second session, on the last half of the first session they

can choose their top three and then proceed with the

method that I said.

RELATIONSHIP

Josh: Erm. Yeah, I would go with the same one as him.

They're both very effective methods. Coz then they get

to know each other and who they like and don't like.

Interviewer: So here are some different types of people. I want you

to tell me how you would order these as most

important. So you have the following personalities -

someone who is really fun, someone who is

hardworking, someone who is really good at it or the

same level as you, someone who is really keen or

something else. What order would you put those in?

Here is the list.

Jack: I would put first, good at the topic, second I would put

personality, third I would put keen and interested, and

then fourth I'd put hardworking

ABILITY

PERSONAILITY

MOTIVATION

Josh: I would put first personlity because if you get on with

them and they're really fun then you might work more

effectively together.

PERSONALITY

Interviewer: And for the rest?

130

Josh: I would go with, hardworking second, keen third, and

good at the topic fourth - because you don't have to be

good at the topic because the whole point of it is to

learn and to gain new skills and if they're good at it...

MOTIVATION

ABILITY

Interviewer: What about if good changed to similar level to you

Josh: I would put them then about third probably SAMEABILITY

Interviewer: So you would see it as more important?

Josh: Yeah SAMEABILITY

Interviewer: Let's say that you were quite good in the class and the

teacher said, I've got someone who's really really

struggling, they're not good at this, and the teacher said

I'd really like you to partner with them. What would you

think of that?

Josh: I think I'd be doing good because I'd be helping them

and giving them skills and teaching them and I'd feel

really good about myself.

HELP ALTRUISM

Interviewer: And what do you think about that?

Jack: Same as Josh

Interviewer: What about if they said for the next 6 lessons. What

about now?

Josh: I think that would be quite good as then you'd get to

know them and then you'd be able to teach them.

TEACH

Interviewer: You paused and gave a face when I asked that Jack,

why?

Jack: Maybe I'd do it for three lessons. I'm sometimes get,

well I sometimes get annoyed, well I sometimes have to

help, I might find it annoying if they're just going "what

does this mean, what does this mean"

FRUSTRATION

HELP

Interviewer: So what's annoying about that?

Jack: I'm just trying to concentrate and then people keep

asking and then they get impatient and don't wait to

respond to them and don't wait for you to give them an

answer. That's happened to me before, so that's why

I'm a bit [inaudible]

DISRUPTION

Interviewer: So let's say your the middle of the class and the teacher

says they'd like you to pair with someone who's top of

the class as I think they'd help you out. What do you

think of that?

Jack: I'd be okay with it as long as they're, as long as they

don't take over of the whole thing. And if they keep

doing that, I'd probably ask for someone who has the

same ability, because they might just cooperate with

me.

TAKEOVER

SAMEABILITY

COOPERATE

Interviewer: What do you think?

Josh: Erm. I'd agree.

131

Interviewer: And just summarising as we've looked a lot at ability. Do

you still think that the same is best or that someone

better or worse than you is best. Do you want to change

your answer?

Josh: I'm still SAMEABILITY

Jack: Yeah, same is best SAMEABILITY

Interviewer: Just thinking about how partners helped you out, how

did your partner help you with the programming

specifically?

Josh: Well if you got stuck on a question and you really

couldn't solve it then maybe they'd know and maybe

they'd help you.

SOLVEPROB

Jack: Well they, my partners would give me fresh new ideas

and I would give them new ideas. So it would sort of

work in a cycle. So I'd give them ideas, they'd give me

ideas and then we'd come up with something fantastic.

IDEAS

Interviewer: Were there any more ways they might help? Josh?

Josh: erm.

Interviewer: Not any you can think of. Can you give me any examples

where your partner helped you and having them was

really useful.

Josh: Erm, well, like I say, from the start, I think it was with

the turtle and it made a shape, and then they, because I

was reading over the booklet and I couldn't get my head

around it, I probably missed something and then they

found it and they put it in and it worked.

SYNTAX

Interviewer: And what sort of thing did they find?

Josh: It was a different thing where it was a colon and I just

completely missed.

SYNTAX

Interviewer: And you?

Jack: It was in the final session when we were making the

text adventure game. I had a completely different idea

form what my partner did. Yeah, it was like run away

from the weird creature called the creature lady, do you

remember that?

IDEAS

Interviewer: Yes.

Jack: So he had the idea of it being, having it on an island

where you have to go find shelter, food, water that sort

of stuff without getting eaten by the creepy lady.

IDEAS

Interviewer: Some was to do with ideas, some was to do with fixing

it. Is there anything else which you think a partner gives

you?

Jack: fun, it's more fun with a partner. ENJOY

Interviewer: Do you agree with that?

Josh: Yeah - it's more enjoyable. ENJOY

132

Interviewer: Can we say any other words than fun?

Josh: Erm. It. If you're on your own, you can get a bit bored

typing away, they keep you entertained.

MOTIVATION

Interviewer: Okay. If I gave you the choice of having a partner and

not having a partner which would you pick?

Josh: Partner PAIRPREF

Jack: Partner PAIRPREF

Interviewer: Why's that?

Josh: Because, then you don't have to do all the work all the

time. Other people are there so you can take a rest.

WORKLOAD

Interviewer: Do you agree with that?

Jack: Not particularly. I don't think that having a partner is so

that you can sit back. I agree that you need to relax

while it take a bit of the weight off your shoulders and

everything is better done in twos. I think that you

should both equally help each other out. And also, it's

just me, I work better in partners.

SITBACK

WORKLOAD HELP

Interviewer: What do you think?

Josh: I can agree, but also they keep you entertained, so if

you're constantly typing you can get really bored and

also you work less effectively. And if you're a partner

then you're all lively, happy and you work efficiently.

ENJOY

MOTIVATION

EFFICIENCY

Interviewer: Okay, so we've got that they can help you solve

mistakes or fix problems, they can also make it more

lively. What would you prefer your ideal partner to be?

So same ability, what else? Describe the perfect

partner.

Jack: Personality. PERSONALITY

Josh: They'd like the same things as me, but they wouldn't be

completely different. They wouldn't be completely the

same. They'd have quite a few differences in methods,

in ideas, but they'd be your friend.

INTERESTS

DIVERSE IDEAS

FRIEND

Jack: As Josh said, be your, be their friend. Erm, but they

enjoy the same things as you, but not completely. They

don't unanimously like the same thing as you, they have

some different interests. That gives you some diversity

which allows you to, just makes it different.

INTERESTS

DIVERSE

Interviewer: How do you think a partner, could, do you think a

partner is for fun, or encouragement or both?

Josh: Both ENJOY

MOTIVATION

Jack: Both ENJOY

MOTIVATION

133

Interviewer: So they can support and encourage, you also have all

the other advantages - just thinking about how they can

help you to learn, how do you think in the sessions

having a partner helped you to learn.

Jack: They can, like I've just said, they can give you fresh

ideas. They can help you with things that you're stuck

on. And.

HELP

Interviewer: Josh anything else which having a partner can help you

to learn?

Josh: No

Interviewer: Were there any times during it when you felt that your

partner explained how something worked to you.

Jack: Yeah. EXPLAIN

Interviewer: Was that quite common?

Jack: Erm. Not really common EXPLAIN

Josh: Not really, but it did happen. EXPLAIN

Jack: With me it was, quite a lot of my partners had the same

ability.

EXPLAIN

SAMEABILITY

Interviewer: Did either of you have any partners, and please don't

say who, but did either of you have partners where

maybe the partnership didn't work.

Jack & Josh: Yes

Interviewer: Okay. You seemed very strong on that Jack, why do you

think it didn't

Jack: well he took over on some parts and then didn't do

anything on other parts. He was being, just generally

being irritating by typing random things into my thing

and spamming the keyboard like putting his hands all

over it and just generally being annoying.

TAKEOVER

DISRUPTIVE

Interviewer: Do you think that that partner, they were annoying, do

you think that there was anything else other than being

annoying.

Jack: Refusal to work and getting over the top and taking it

away from me and not letting me do it when it was my

turn.

MOTIVATION

TAKEOVER

Interviewer: So annoying, not the same level of hard work as you,

and anything else at all?

Jack: [pause] No.

Interviewer: What about you Josh?

Josh: Yeah - I did have a partner like that and it was pretty

much the same. They just kept spamming the keyboard.

Wouldn't give you control when it was your turn. And

kept, they wanted everything to be about them,

nothing was allowed to be your idea.

TAKEOVER

DISRUPTIVE

EGOTISTIC

134

Interviewer: Okay. Let's say that they weren't spamming the

keyboard, they allowed you to have your own ideas,

was there anything else left that maybe you didn't like

as a partnership about them.

Josh: Well refusal to work still. They just. Sometimes, when

they did work they wouldn't give it to you. When they,

when it was their turn and they didn't want to work

they just wouldn't.

TAKEOVER

SELFISH

Interviewer: Are these people, do you feel they were the same

ability as you, better than you at it or not as good as

you at it.

Josh: It was hard to tell as they weren't trying MOTIVATION

Jack: I think not as good. LOWERABILITY

Interviewer: At the beginning you said a lot of things to do with the

method. I will go into this with others in more depth as I

know we are nearly out of time. But just thinking of the

method itself, the clock, the changeover and having two

keyboards. What did you think of that?

Jack: Effective and efficient EFFICIENT

Josh: Yeah, I think the clock was really good. The two

keyboards was good to an extent. When you were

working with someone bad they would just misuse it.

CLOCK DUALKEY

DISRUPTIVE

Jack: At one point I did have to unplug the keyboard, so.

[laughter from all]

DISRUPTIVE

UNPLUG

Interviewer: Let's say some fairly black and white questions. If you

were to do it again. Would you want the clock, yes or

no?

Jack: I would say yes CLOCK

Josh: yes CLOCK

Interviewer: If they said you could have two keyboards, would you

say yes or no?

Josh: I would say yes DUALKEY

Jack: yes DUALKEY

Interviewer: If they said we'd like you to give each other a high five,

yes or no

Jack: no HIGHFIVE

Josh: no HIGHFIVE

Interviewer: And to saw awesome or something like that?

Jack: no SHOUT

Josh: yes, I would say yes. SHOUT

Interviewer: Okay, some mixed opinions. So you said no for high

fiving, why?

135

Josh: well, I just think it wastes a bit of the time. Because if

you add up all the time you spent high fiving, well it

kind of adds up. Also it makes people get a bit giddy and

overexcited. And they just stop working.

EFFICIENT

HIGHFIVE

DISRUPTIVE

What do you reckon

Jack: It's a rather strong opinion, but it just makes me feel a

bit more young. And a bit.

AGEAPPROPRIATE

Interviewer: Lets assume that it didn't make you feel younger, I don't

want to talk about high fiving or saying awesome; let's

say, does saying awesome, and you said that sometimes

they wouldn't changeover or they would takeover. Do

you think that helps with saying there is now someone

else in charge, ignore the fact it made you feel childish.

Jack: It does yeah. HIGHFIVE SHOUT

Interviewer: Do you agree?

Josh: Yeah HIGHFIVE SHOUT

Interviewer: so now let's say there shoudl be something there for

the changeover, but we don't want you to feel childish

or waste your time. Other than the clock, what coudl

help with that changing it over.

Jack: A bell sound. BELL

There was a bell aswell. Do you think that should be

louder or something?

Jack: Maybe a bit louder and someone saying changeover BELL

Interviewer: Josh?

Jack: Well I still think they should say something so then you

can see if everyone is changing over properly. So if

someone doesn't say it you can tell that they are, they

don't want to changeover.

CHANGEOVER

Interviewer: so could it be in your thinking, do you agree with that,

that it's a bit childish?

Josh: well, yeah. AGEAPPROPRIATE

Interviewer: here I'm guessing and you can say anything you want,

but what if it was shaking hands, or saying to your

partner it's time to change now or any idea you can

think of, what would you go for?

Josh: I'd just have someone at the class go "changeover". CHANGEOVER

Interviewer: So that would be a teacher or student or someone like

that?

Josh: a teacher CHANGEOVER

Jack: shaking hands could work SHAKEHANDS

136

Interviewer: So shaking hands could work and that would be more

appropriate?

Jack: yeah SHAKEHANDS

Interviewer: which would you prefer Josh, shaking hands or a

teacher or both?

Josh: both SHAKEHANDS

Interviewer: what do you reckon?

Jack: both SHAKEHANDS

Interviewer: so tell me if I'm right here. There should be something

extra to the clock, to say how to change, but not the

way that we did it. Is that right?

Jack & Josh: Yes CHANGEOVER

Interviewer: okay I don't want you to be late. You've been the

perfect people for an interview because you've told me

absolutely loads. Is there anything else which you want

to tell me about what should be done or shouldn't be

done?

Josh: I'm okay

Jack: I've said everything.

Interviewer: Okay thank you very much.

Jack & Josh: Thank you.

Appendix O – Interview 2

Interviewer: Hi again. You have been invited to a follow up interview today because you attended one or more of the Pair Programming sessions last half term. This is voluntary so you are free to leave now or at any time during the interview. This interview is being recorded. It will then be written down and the recording will be deleted. Your names will be changed when it is written down so anything you say will be anonymous. If you don't want a comment included then you can tell me during this interview, or at any time up until the end of term. This interview will allow you to give more information about what you thought about the sessions on Pair Programming. Do you have any questions or is there anything you would like clarified?

James No

Interviewer: Is everything okay?

Thomas Yep

137

Interviewer: So, thinking back to when we were doing these programming sessions. First of all, what do you think overall?

Thomas I quite enjoyed it and I think it was an effective way to learn Python. Because although I knew a bit, I, there was stuff which we were covering which I haven't learnt yet. But also I find it quite an effective learning, and also quite fun at the same time.

TEACH ENJOY

James I really like it. Some people may just want to do like everything so this way it's like fair, so this person goes on, then this person, but you both the get the same amount of time.

ENJOY FAIRNESS

Interviewer: Okay. So I want to look, and thinking about what you just said about the method, I want to look at how the method works and then some other areas if we get time. So the first question, what do you think, thinking of the method, what do you think of the method overall?

Thomas I think it was quite effective as, as James said, normally when I'm learning in doing something like ICT my partner just lets me do all the work because I'm quite good at it in their opinion.

TAKEOVER HIGHERABILITY

Interviewer: Can you give any examples of where this is successful?

Thomas Well, it helped both of us learn at the same time, rather...

LEARN

James Yeah

Thomas ... than when I was, when I'm doing it with a partner but I'm doing most of the work, there is me sitting there but a lot of the time they don't know what I'm doing.

TAKEOVER

Interviewer: What was it that made it so that it was like that?

Thomas It was the fact that the time was divided up; the time was divided up equally between each partner and most of us were active and engaged in what the other person was doing and asking about what they were doing.

TAKEOVER CLOCK MOTIVATION ASK

James Yeah, I asked what he was doing a few times. ASK

Interviewer: Were there any examples, are there any other examples you can think of where you felt it was successful?

James Well, ... [long pause], well with Thomas I can make sure that I know what he's doing as I always ask, so when we switch over, I might be doing some of it that I don't know so I get to learn new things aswell, that way.

ASK CHANGEOVER DUALKEY

Interviewer: Were there any examples where it perhaps wasn't successful?

Thomas I can't think of any off the top of my head?

James Yeah, I can't.

138

Interviewer: Okay, that's fine.

Interviewer: What would, and here I want you to put them in the order of importance, so we did different things like we had the high fiving, we had the clock, we had the keyboards; what order would you give those?

Thomas I would say that clock is the most important one... CLOCK

James Yeah

Thomas ... followed by the two keyboards and then the high fiving and awesome.

DUALKEY HIGHFIVE SHOUT

James Yeah, same.

Interviewer: same order.

James Yeah

Interviewer: And out of all of those, what's the most important to making it work?

Thomas The clock because then you get equal time with the people

CLOCK

James Yeah. The only thing I'd say is, I'm not sure about the two keyboards coz I don't, I know me and Thomas sometimes just used one between both of us, because you're changing anyway.

DUALKEY

Interviewer: So what do you think about the keyboards overall.

Thomas So I thought it was quite good as it saved the time of having to move the keyboards around instead you just had to move the mouse which is a lot faster. Yeah.

DUALKEY EFFICIENCY

James The only thing is that sometimes when I was with someone, my keyboard was a bit, coz our keyboards were next to each other when you move the mouse it might not have reached, so we had to push all the keyboards down to do it and that was annoying so I preferred just using one.

DUALKEY ROOMSPACE

Interviewer: Okay. So let me ask, so you said it was annoying how it was with the mouse. Let's say that you now had the choice of having two mice. Would you go with two keyboards or would you go with one?

James Yeah probably. As long as there was enough room then yeah.

DUALMICE

Thomas I probably wouldn't have two mice though, because if your partner accidentally knock it...

DUALMICE

James Oh yeah, that would not work well. DUALMICE

Thomas ...moving it off the screen or something. DUALMICE

Interviewer: Do you agree with that?

James Yeah. DUALMICE

Interviewer: So, you reckon that one mouse is better than two whatever the other situation?

DUALMICE

James & Thomas: Yeah

139

Interviewer: Okay. So for the two keyboards, just go into detail, what exactly was wrong with them when it went wrong.

James So because we had two there, then the computer was there, because he added the mouse there, when I reached over here the mouse didn't really reach that well so it was hard for me to move, so we moved the keyboards down a bit; but I had to move mine up when he was doing it

DUALKEY DUALMICE

Interviewer: So if you could move, if you had a mouse that had a long enough cable...

DUALMICE

James Yeah DUALMICE

Interviewer: ...or it's all neatly organised... DUALMICE

James Yeah DUALMICE

Interviewer: ...so you could quickly move the mouse from one to the other, then would two keyboards be okay?

James & Thomas: Yeah DUALKEY

Interviewer: okay. Are there any other problems which you see with two keyboards?

Thomas there, the only one I can think of is the obvious one which would be typing over each other.

DUALKEY DISRUPTIVE

James Yeah, that was, that would be annoying. DUALKEY DISRUPTIVE

Interviewer: And was that an issue for you?

Thomas No DUALKEY

James No DUALKEY

Interviewer: Could you see it becoming an issue and if so how might that be dealt with?

Thomas I could see it personally becoming an issue if your partner was kind of a destructive mindset then it's constantly typing random letters and stuff.

DUALKEY DISRUPTIVE

James Yeah

Interviewer: How would you deal with that if that happened to you?

Thomas Well I'd start by asking them to stop, then if it happened then I'd probably end up unplugging their keyboard.

DUALKEY UNPLUG

Interviewer: Okay. How does the method, you think help you solving those problems?

Thomas Erm. With the two key. Erm, the method I just said?

Interviewer: Oh no. Does the method we did with the clock and the time change and everything else, does that help to avoid those problems?

Thomas Yeah CLOCK ARBITRATION

James Yeah

140

Interviewer: Can you think of any rules that you might put in that would improve it. So obviously we had ones that I set, do you have any that might improve that?

James Erm. [long pause]

Thomas I can't actually think of any that we haven't actually had.

James Unless you can see when you have the two keyboards to stop people typing over each other, maybe one of the keyboards was unplugged and then you quickly plugged it in. That might be a bit annoying.

DUALKEY UNPLUG

Interviewer: Were there any times when perhaps it wasn't your turn to use the keyboard but you were happy to type on theirs?

James Yeah, I [inaudible] sometimes DUALKEY SHARING

Interviewer: And did you do that sometimes?

James & Thomas: Yeah DUALKEY SHARING

Interviewer: How did you arrange that? Did you ask the other person or did you just do it or...?

Thomas Yeah, well what would happen with us, for example, so if I had an idea, erm, I'd suggest the idea, but then if James didn't quite know how to do it, he'd just say, erm, he'd just ask me to do it instead.

DUALKEY SHARING

James Yeah, but then once he'd written it out, I'd ask him, like, exactly what everything is so I can learn more of what he's doing so that I can understand.

ASK DISCUSS

Interviewer: You could put a switch in that forces it to be on one of the keyboards, but do you think that would reduce the times at which you let the other person do it?

James yeah DUALKEY EFFICIENCY

Thomas yeah that's a problem.

Interviewer: So if it works and the other person's okay and they're not going to interupt, then having two keyboards as it was is good as you can see it?

James & Thomas: Yeah DUALKEY

Interviewer: Just overall, one easy question. So if you did this again, would you prefer to use two keyboards or one keyboard?

Thomas Two DUALKEY

James Two DUALKEY

Interviewer: Okay. What do you think of the clock?

141

Thomas I think it's quite helpful because some, we lost track, also one of us had an idea and, but, we didn't quite know how to execute it, but then we looked over to the clock and we saw quite a bit of the time so we just let the other person do it, whereas other times when it was about to change over we just waited until the clock changed anyway.

CLOCK ARBITRATION

Interviewer: So how did that help?

Thomas It also helped me see how much time we had left. So for example, when you were looking at it, if you had quite a bit still in mind you might have to wait until your next turn to put it in because if you look over and see you don't have that much time left, not enough time to implement it then you might wait until next time and do something simpler instead.

CLOCK ALTERNATIVEIDEA

Interviewer: So are you saying that you, you said that you might do something simpler. Did the clock make you change how you solved the problem at all?

Thomas Er. Yes sometimes. ALTERNATIVEIDEA

Interviewer: And how did it make you change it?

Thomas Well sometimes I thought of a complicated solution to the problem, then I saw how much time we had left on the clock and so I suddenly just thought of a simpler solution to it.

ALTERNATIVEIDEA

James Yeah.

Interviewer: So it made you think of different solutions? ALTERNATIVEIDEA

Jacob & Simeone Yeah

Interviewer: What do you reckon James?

James I actually liked the clock because, I just like the idea of switching over. But I also thought it was a good amount of time. I think maybe if it was only two minutes it would be a bit too short and might get a bit annoying but if was like 10 minutes then the same person might be typing for ages, so I think 5 minutes is [inaudible]

CLOCK LENGTH

Interviewer: So do you think 5 minutes is the right amount of time? You worked in a 3 at some point, that was I think the last session and we worked it slightly differently where you swapped with the left or the right. How did that go?

142

Thomas Well it got slightly confusing at one point as we didn't all entirely understand what we would do, we thought we would all move along to the side, at least the person on the computer at that point thought it was. But they thought that it mean different people got different times, but then we tried it for a bit and we realised that everyone did get the same amount of time

THREE CONFUSING FAIRNESS

Interviewer: So now that you know you all get the same amount of time, do you think that now you've done it that that works well or not?

Thomas Yeah LENGTH

James Yeah it works well LENGTH

Interviewer: Is there a way that you could see to do that that would be easier.

Thomas The only one I could think of is that when it dings instead of moving to the right or the left you all move along one.

THREE

James Yeah THREE

Thomas You would just ignore the right and left [on the clock] THREE

Interviewer: I saw at one point, and this was interesting that the person in the middle moved to the right and you swapped over, but because you had two keyboards you carried on typing. Did that happen much?

Thomas Erm, don't think so.

Interviewer: Do you think it was easy though to allow different people to take control?

Simeon & Jacob Yeah DUALKEY SHARING

Interviewer: Do you think if you had one it would be easier, the same or harder to allow different people to take control.

Thomas It would be harder to allow people, but it also means that if you really don't want someone, then you can make sure.

DUALKEY

Interviewer: What makes sure?

Thomas If you have one keyboard because your typing, so they can't use it or reach over or do anything.

DUALKEY

Interviewer: Do you think there might be certain types of people or certain partnerships where having one keyboard would be better.

Thomas Well I think with me and Daniel, one worked better. Coz Daniel actually didn't want to do a lot sometimes.

DUALKEY

143

Interviewer: Okay. What about if you wanted the choice, the teacher at the beginning said you try it out in the first lesson and then you all understand how it works and then they said depending on your partnership you can agree on whether you want to have one or two keyboards, would that be better, worse or the same.

Thomas Better I'd say. DUALKEY

James Yeah better coz it gives you more freedom whether you want to or not.

DUALKEY

Interviewer: Okay. If you had a disagreement in the partnership, one wanted to use two, one wanted to use one, what should you say?

James rock, paper, scissors ARGUE

Interviewer: So is it 50

Thomas I'd say that they're both okay, because what you could do with one keyboard aswell, rather than move it you could just swap the seats.

DUALKEY

Interviewer: Thinking of the clock, can you think of anywhere where that makes things worse at all?

Thomas No not really. Unless you're in the middle of typing, but your partner will probably just let you carry on.

CLOCK

James Yeah.

Interviewer: Okay, so having the two keyboards and being allowed to let the partner carry on, so the clock is a bit of guidance. Is this right, the clock guides you but you don't have to stick to it?

James & Thomas: Yeah CLOCK FAIRNESS

Interviewer: Would you do anything to improve the clock at all?

Thomas I don't think so CLOCK

James I can't think of anything CLOCK

Interviewer: Was it obvious, when you were working as just two, was it obvious who was in control?

James & Thomas: Yeah CLOCK DUALKEY

James although I think a few times we actually, like sometimes, when we were about to change, one of us had an idea and it was their turn, so when we changed we were still going and then we ended up thinking it was their turn. So when it was actually their turn we had to like change again.

DUALKEY MOTIVATION

Interviewer: The system could cope with that.

James no, I think it's just if you choose to or not.

Interviewer: Do you think that for Pair Programming having a clock would be important?

James Yeah definitely CLOCK

Thomas Yeah CLOCK

144

Interviewer: And why is that?

Thomas Because otherwise it would just end up with just one person hogging it.

CLOCK TAKEOVER

James Yeah I'd agree.

Thomas Either hogging it or just letting the other person do all the work.

TAKOVER SITBACK

Interviewer: Do you think if someone started to hog it, what would the solution be to that?

Thomas Probably ask the teacher or I'd probably just say sorry it's my turn.

TAKEOVER

Interviewer: So if you couldn't deal with it by asking a teacher what would you then expect the teacher to do?

James Tell them off, tell them not to do it. TAKEOVER

Interviewer: Could it, rather than telling them off, would it be better to switch to one keyboard or to stay as two and deal with it some other way?

James Yeah actually, just getting them to switch to just one keyboard and then obviously tell them that it's not their turn so the other person would be able to carry on.

DUALKEY TAKEOVER

Interviewer: What about if someone was starting to hog it, but the other one was happy with them doing all the work. How would you deal with that one?

Thomas I don't really know.

James The person who's relaxing, well maybe you could try and get them quite interested in something new and then they might want to do something.

SITBACK MOTIVATION

Thomas Also, if someone just comes up to them and asks them if they know what's going on on the computer or something.

SITBACK MOTIVATION

Interviewer: so you would manage it within your partnership?

Simeon & Jacob Yeah. SITBACK

Interviewer: Okay. And a simple question, would you use the clock if you did it again?

Thomas Yeah I would use the clock CLOCK

James Yeah CLOCK

Interviewer: Okay. We also did a transition where you did a high five and you also said awesome. How did that go?

Thomas I can't really see any problems with it. [long pause]

Interviewer: Let's split it out coz we did two things. First of all going and doing a high five, was that a good thing or?

Thomas It was okay for younger students like us it would probably a good thing, but for older students they might not like it.

AGEAPPROPRIATE HIGHFIVE

James Yeah

Thomas To be honest I didn't really mind if you did it or if you didn't

HIGHFIVE

145

James I reckon if you did it in year 9 you might be really reluctant

Interviewer: What about in year 7 [current year group]?

Thomas Year 7 yeah AGEAPPROPRIATE HIGHFIVE

Interviewer: Do you think that it has any uses? Like if we didn't do it do you think that would be better?

Thomas The only thing is, it makes it obvious, so for example, if you missed the ding, erm, you can, if you see people high fiving around you then you can tell.

CHANGEOVER HIGHFIVE

James I think it's actually better if you do it and then you can see who's quite enthusiastic and who's relaxing; it would be clearer to the teacher.

HIGHFIVE MOTIVATION

Interviewer: Do you think you could change the action you do so that instead of high fiving you could do something else and that would be more age appropriate?

Thomas I'm trying to think of something else.

[long pause]

Interviewer: What about if there was like some kind of button in front of you that you had to press and if you pressed that it meant that you had to change, because then it would mean that you had definitely heard the change

James Yeah CHANGEOVER HIGHFIVE

Thomas I like pressing buttons

Interviewer: What about if you had to have 30 seconds talking with your partner to discuss what you had done so far.

Thomas Yeah, I think that would be good. CHANGEOVER 30SDISCUSS

James Yeah, the only thing though is though we've just, particularly me and James, we'd just be going over the same stuff we'd already talked about then just before that.

CHANGEOVER 30SDISCUSS EFFICIENCY

Interviewer: so that could waste your time.

James yeah. 30SDISCUSS EFFICIENCY

Interviewer: You also had to say Awesome, how do you feel about that?

Thomas Again I think by the time you get to year 9 you might be a bit reluctant to do that.

SHOUT AGEAPPROPRIATE

Interviewer: and in year 7 it's okay?

Thomas Yeah. SHOUT AGEAPPROPRIATE

Interviewer: would you change the word or not say it at all?

Thomas I'd probably not say it at all. SHOUT WORD

146

James Yeah. SHOUT WORD

Interviewer: What about if you had a handshake instead.

Thomas Too formal. SHAKEHANDS

James Yeah. but if you did do it, then definitely don't say awesome because it would be too formal for awesome.

SHAKEHANDS WORD

Interviewer: What about if you said nothing and just said well done and shook the hand and it's their go

Thomas I think it's still too formal though SHAKEHANDS WORD

James Yeah, I think people would prefer the high five to that. SHAKEHANDS HIGHFIVE

Interviewer: So it's high five for young people in year 7, maybe year 8, but not year 9?

Simeon & Jacob Yeah. AGEAPPROPRIATE HIGHFIVE

Interviewer: Do you think that working with a partner helps you to learn?

Simeon & Jacob Yeah. HELP

Interviewer: How does it help you?

Thomas Because your partner might have ideas and know stuff that you don't and vice versa

IDEAS

James The only thing is, what was it, when we were using, we were using random integer and we had to put bracket bracket somewhere, or maybe we had to put one in and then it turned out to work. Whereas Thomas might know lots about it but so like.

SYNTAX KNOWLEDGE

Thomas Yeah, but there was definitely one thing where I forgot to put the bracket bracket and then James pointed it out to me.

SYNTAX

James Yeah. Coz there's also some times you omit stuff. SYNTAX

Interviewer: So we have examples where we're fixing errors, is that right?

James & Thomas: Yeah SYNTAX

Interviewer: Are there any other times that it might be helpful to have a partner?

James If you have to work in new ideas then Thomas can put it in. Then we can discuss where we're going to put it or how we think we can put it in.

IDEAS SYNTAX SOLVEPROB

Thomas Or one of us might have the idea and the other one might think how to implement it but wouldn't have that idea.

IDEAS ALGORITHM SOLVEPROB

Interviewer: Did you talk with your partner or other students about how to solve your problems - it seems that you did.

Simeon & Jacob Yeah [laugh] DISCUSS

Interviewer: How much did you talk to each other?

Thomas Quite a lot. DISCUSS

147

James Yeah, quite often. DISCUSS

Interviewer: What does quite a lot and quite often mean?

Thomas Pretty much whenever we had a problem we'd discuss it and someone would work it out.

DISCUSS SOLVEPROB

Interviewer: Did you explain what you were doing as you did it?

James & Thomas: Yeah EXPLAIN

Interviewer: Did you talk to, I know when you worked in a 3, that's different, but did you talk to other students out of your group?

Thomas Yeah I think we did sometimes. Sometimes they had something, when we were doing the circle someone did this square thing and it kept on going around and changing colours and, hey look at this, and we might not have thought of that.

EXPLAINOTHERGROUP

Interviewer: Do you feel by the method being paired programming and everything that was done in the method, do you think that made you talk the same, more or less than if you had been on your own computers

Thomas More DISCUSS

James More, definitely more. Because especially like the [inaudible], to talk to each other and when often fixed other peoples errors and stuff and see them.

DISCUSS

Interviewer: Do you feel that that method made it easier to learn then?

James Yeah LEARN

Thomas Yes LEARN

Interviewer: Did you, you said about explaining ideas. Did you ask each other to explain your ideas so that if you got stuck you, so if you didn't understand would you ask?

James Yeah, I asked him, when he put in the random numbers, I can't remember, randint...

EXPLAIN

Thomas Yeah, random integer, randint EXPLAIN

James Yeah, I didn't really know what that was though. I've used Scratch so I kind of understand, but I didn't understand it in Python, so I kind of asked him to explain, and then once he was writing after it with the range.

ASK EXPLAIN

Interviewer: Were there any other times Thomas when you asked what he was doing?

Thomas There was once, I can't quite remember, when James put something in that I didn't quite understand.

ASK SYNTAX

James The password bit?

Thomas Yeah the password bit. So I asked James to explain what he was going to do.

ASK EXPLAIN

148

Interviewer: Okay. Just very quickly, with partners working together, it seemed to work well. Would you rather work with someone who is better than you, is the same as you, or not as good as you. Which would you work with if you had the choice?

Thomas I would probably go with the same SAMEABILITY

James I'd probably go with someone better than me, like Thomas, because they have lots of knowledge about it, but then I can maybe give ideas about things that they may not have thought of but they know how to put it in the program.

BETTERABILITY IDEAS ALGORITHM SYNTAX

Interviewer: Do you think there are times that you might go with someone better Thomas?

Thomas Yeah. BETTERABILITY

Interviewer: For the same reasons?

Thomas Yeah. IDEAS ALGORITHM SYNTAX

Interviewer: What about going with someone who is worse than you?

James It's good as long as you're good at explaining. You can explain it and then it helps them to learn aswell. And then they may actually enjoy it more.

WORSEABILITY EXPLAIN HELP LEARN ENJOY

Thomas If you're good at explaining and if they're good at picking up stuff then it's fine

EXPLAIN TEACH

Interviewer: Let's assume that everything's the same. What order would you choose for who you picked - so you've got three different people, ones better, ones the same, one's worse. What order would you pick those partners?

Thomas I'd probably choose the same first, then better then worse

SAMEABILITY BETTERABILITY WORSEABILITY

James I'd choose better, then worse, then the same - coz if they're the same then you won't have many new ideas or new knowledge. Because better will have more knowledge and more words

BETTERABILITY WORSEABILITY SAMEABILITY

Interviewer: Now lets say that there's 15 people going from exactly the same as you in the middle and they go all the way up to like so much better they're like my level and they go down so much worse that they're like someone in year 5 - they're all the same age, but there's this big range from higher to not so good. Where would you pick within that range?

Thomas I would pick about half way between same level and way way better

ZPD

James Yeah ZPD

Interviewer: Why would you not go with the very far better?

149

James Because I think they'll do things just too complicated for us to understand and we won't grasp what they're doing.

ZPD

Thomas So they'll constantly be explaining it ZPD EFFICIENCY

James Yeah, and then they'll probably not enjoy it as much either, trying to constantly explain.

ZPD ENJOY

Interviewer: And why not if you went for the worse one, why would you not go to the extreme?

James If they're too worse then it might be me who's explaining it to them and I think that would be a bit annoying sometimes.

ZPD

Interviewer: Okay. That's all the questions I have, but do you have anything else that you want to say that you think we haven't covered?

Thomas No

Rob I really enjoyed it! ENJOY

Interviewer: Did you enjoy it Thomas?

Thomas Yeah ENJOY

Interviewer: Brilliant. Thank you for your time.

Appendix P – Interview 3

Interviewer: Welcome back. You have been invited to a follow up interview today because you attended one or more of the Pair Programming sessions last half term. This is voluntary so you are free to leave now or at any time during the interview. This interview is being recorded. It will then be written down and the recording will be deleted. Your names will be changed when it is written down so anything you say will be anonymous. If you don't want a comment included then you can tell me during this interview, or at any time up until the end of term. This interview will allow you to give more information about what you thought about the sessions on Pair Programming. Do you have any questions or is there anything you would like clarified?

Sophie: No

Emily That's okay

Interviewer: So if you remember back to the sessions we did on Pair Programming. You worked together at least twice?

Emily: We worked together each time we were here

Sophie: Yeah

150

Interviewer: So, first of all, and this isn't a problem for me, this isn't anything to do with the school, can I ask why you didn't come every day, was there something else on, or...?

Sophie: I think for one of them I was ill, the second one I had to do something in RM

ATTENDANCE

Emily: And one of them I was there for three times, but the other, the only time was because I had to get my braces tightened a bit.

ATTENDANCE

Interviewer: Okay. And can I ask, just so that we know, and it's okay to give any answer, if you hadn't have had these other things, would you have come?

Emily & Sophie Yeah

Interviewer: Okay. Do you think other girls would enjoy this?

Emily: Yeah ENJOY

Sophie: errr ENJOY

Emily: not all of them ENJOY

Sophie: maybe not our year coz their sort of more phones, makeup, ... they're not really, sort of

ENJOY GENDERTOPIC

Emily: they're not really like technology people ENJOY GENDERTOPIC

Interviewer: Why, so you've given some reasons why they might not come to something like that or might not enjoy it. Let's say that this was in normal lessons and they didn't have an option of coming, how would you change it?

Emily: I would probably say, well maybe it's like, it's better than doing like an exam or a test and it's quite fun to do when you're learning new things. I'd probably just say that.

ENJOY LEARN

Sophie: I'd probably just do it, and say, if they didn't understand it then I'd sort of show them like bit by bit.

HELP

Emily: so sort of help them. HELP

Sophie: yeah so that we just like read it and I'd like explain it to them, coz I think that the people that are in my lesson, the girls are more, I don't know why, they find it easier to listen to instructions than read instructions.

EXPLAIN

Interviewer: Okay. Would you deliver it slightly different then?

Sophie: No, I'd just sort of say what you're supposed to do but EXPLAIN

Emily: Like making it easier EXPLAIN

Interviewer: So you'd re-explain?

Emily & Sophie Yeah EXPLAIN

Interviewer: Do you think, the theme I guess was kind of a bit mathsy with shapes and then pictures, then we had an adventure game for the second part. Do you think that those themes could be changed to be more appealing to girls?

151

Emily: Maybe like, maybe the adventure game we could kind of try and change it to something more girly, something like a dress up game or something like that. Or trying to sort of, instead of shapes, sort of make maybe, like, clothes like top, trousers...

GENDERTOPIC

Interviewer: so some of the examples could have been

Sophie: yeah GENDERTOPIC

Emily: sort of like more to do with GENDERTOPIC

Sophie: girls? GENDERTOPIC

Emily: yeah GENDERTOPIC

Interviewer: like clothing, that sort of thing.

Emily: yeah GENDERTOPIC

Interviewer: if it was like flowers as some of those shapes fit in, that would be a bit more,...

GENDERTOPIC

Emily: yeah GENDERTOPIC

Interviewer: ... you agree?

Emily & Sophie Yeah GENDERTOPIC

Interviewer: For the adventure game, you said that you could change that as something dressing up but you weren't sure, but like, how would that work? What would you see the end game looking like?

Sophie: it would basically be like... GENDERTOPIC

Emily: like what like clothes you'd want to wear and then at the end maybe have a list of what you were wearing

GENDERTOPIC

Interviewer: okay

Sophie: and like you could try and program it so there, er, you could click on something and in the picture it could like move along so that it looks like it's on top of the person or something

GENDERTOPIC

Interviewer: are you talking about the first part rather than the one with the adventure game, or are you talking about the adventure game?

Sophie: and that would make it more like girly like GENDERTOPIC

Interviewer: yeah, are you saying to replace the first part or the second part or something completely new

Sophie: I think something completely new GENDERTOPIC

Interviewer: okay. so could you have like a different theme, so like you're dressing up this person to like go to something?

Sophie: yeah GENDERTOPIC

Emily: yeah like you could maybe pick... GENDERTOPIC

Sophie: like a prom or a disco GENDERTOPIC

Emily: what they were so they were able to, so like wedding GENDERTOPIC

Elize prom GENDERTOPIC

Emily: yeah prom, to school, like everyday. GENDERTOPIC

152

Interviewer: okay. would it work if, and I'm just thinking of the same ideas as an adventure game, would it work in the same way as an adventure game where maybe you make choices. Could it give you the theme, one of those themes, and then perhaps be like you're shopping...

Emily: yeah GENDERTOPIC

Interviewer: ...and you have to choose the different options, so you have to choose the different options, like here's a number of items, what would you want to buy and you had to...

GENDERTOPIC

Emily: yeah and you had like a certain amount of money GENDERTOPIC

Interviewer: so would that work

Emily: if you had sort of like £100 or around there and then you and they had a price list and, it would be a bit more, yeah.

GENDERTOPIC

Interviewer: and would that work for you?

Sophie: yeah GENDERTOPIC

Interviewer: so it could be sort of picking out clothes for somebody

Sophie: yeah GENDERTOPIC

Interviewer: okay. Erm, do you think then, just looking at that, that when it becomes gamey, certain girls might be turned off

Sophie: I don't know GENDERTOPIC

Interviewer: like that was making an adventure game. Would that be not as attractive to certain girls

GENDERTOPIC

Sophie: yeah. I don't think it would be that attractive to certain girls coz like most girls in our year are more like

GENDERTOPIC

Emily: boys, makeup, clothes, gadgets... GENDERTOPIC

Interviewer: music?

Emily: yeah music, but not, they sort of, they're not on the making side of things, they're more on like, they just get the things they want and they don't cons [pause - perhaps construct], so like for this you sort of like make your game, so you can make what you want, but I think that they would rather have that someone else made it and they just played it and sort of like watched what they did

GENDERTOPIC

Interviewer: right okay. If you were looking at, so changing slightly to the partners; what would your ideal partner, describe what your ideal partner would be?

Sophie: like, I think my ideal partner would be someone who has more knowledge on it than me, so they can teach me how to use the program and like maybe someone who's like got really creative ideas aswell.

HIGHERABILITY TEACH IDEAS

Emily: sort of like someone who, maybe doesn't know as much as you, or who knows more, so you can either teach them or learn from them and sort of like help them instead of like sort of just having the same level and not knowing what to do

LOWERABILITY HIGHERABILITY TEACH LEARN HELP

Interviewer: okay

153

Emily: sort of, like some people pick things up quite fast but some people don't and you don't know what erm, like you might not know what to do or you do it completely wrong and then the other person's like it's completely right and you don't know what to do. It's just easier for someone to know what they're doing. Or if we both know what we were doing and it was at the same level then that's good because...

SELF-ESTEEM SAMEABILITY

Interviewer: you [Sophie] said a bit higher so that they can teach you and either higher or lower so that you can teach them or they can teach you, erm, how do you feel about if they're the same level?

Sophie: I think it will still be quite fun, just you won't be able to learn anything more, they won't be able to learn anything more, coz you'll both be at the same level. And it won't really be like teamwork.

ENJOY SAMEABILITY

Interviewer: Okay. do you agree?

Emily: If you're sort of the same level and you don't know much about it, it's good to like work together and find out what you're supposed to do, then if you don't know what you're doing and you do it wrong then you might just like screw up everything, and like both of you just don't know what to do after that. But like if you're the same level and you know what to do then that's quite good coz then you can just like bounce off each other with like things. So if someone says, so the person who's typing like typed something wrong and the other person's like, the same level, so you know like you can trust each other, and the other persons like, hey you've typed that bit wrong, and you know you can rely on the other person to tell you whether they think it's like right or it might be like wrong

SAMEABILITY DISCUSS IDEAS SELF-ESTEEEM

Interviewer: Thinking about you two, and here we're not thinking about normal school or your intelligence or anything else, this is just about this project, do you think that you were about the same, that one of you was better, that one of you was worse, what do you think?

Sophie: I think we were about the same SAMEABILITY

Emily: the same SAMEABILITY

Interviewer: Okay - and don't fall out with each other, it doesn't matter how you got on, but do you think you got on when you were doing this?

Emily & Sophie Yeah SAMEABILITY ENJOY

Interviewer: did you feel that you learnt much during it?

Sophie: Yeah, a lot, I'd never really even had Python. LEARN

Interviewer: you'd learnt a lot?

154

Emily: yeah LEARN

Interviewer: so you would say that this worked as a partnership. But it was the same. How; Do you feel if you could take Emily, exactly the same, you get on the same, the only difference is that she's now better than you. Do you think that would have made it better or worse, or the same?

Sophie: I think it would have probably made it like the same, because we can both learn off each other's mistakes.

SAMEABILITY LEARN

Interviewer: and if it's exactly the same and you made her worse, do you think it would be the same, better or worse?

Sophie: I think it would still be the same coz I could teach her and. SAMEABILITY TEACH

Interviewer: so the same relationship works for you aswell. And what about you

Emily: the same SAMEABILITY

Interviewer: it works

Emily: yeah SAMEABILITY

Interviewer: If we take it to a bigger extreme now, so here exactly the same person, but now she's really good, she's as good as me at programming, what would you rather, Emily or her as good as me at programming?

Sophie: I think I'd prefer her. SAMEABILITY

Interviewer: okay. Why?

Sophie: because, like, if she was better then she might be thinking like, she can keep doing things and not letting me have a go, because she might be on top of herself a bit.

BETTERABILITY TAKEOVER EGOTISM

Interviewer: Do you think you'd learn more or less?

Sophie: I think I'd learn less because I wouldn't be doing much BETTERABILITY LEARN SITBACK

Interviewer: And what about if she's now like just really like not very good at all. It's exactly the same person, you really like her, but she's like being with a year 5 student.

Sophie: I wouldn't really mind that coz I could still teach her some stuff.

LOWERABILITY TEACH

Interviewer: and same questions. If it was really really better

Emily: I'd probably just want like her, coz then we could just bounce off each other and not have to, like coz if, the other person knows a lot then they might just be like, that's wrong, that's wrong, that's wrong, and not say anything if it's right, so you just don't learn from your mistakes. The other person just says, that's wrong just let me do it, and you don't learn

SAMEABILITY IDEAS SELF-ESTEEM LEARN

Interviewer: and if it was someone exactly the same but like a year 5 student, they just weren't so bright

155

Emily: Probably just teach them like the easy bits, and then just ease them into the harder parts of it

LOWERABILITY TEACH

Interviewer: but you'd be happy with that person compared to the bright person?

Emily: yep LOWERABILITY

Interviewer: okay. Erm. When thinking about chooosing partners, how do you feel about say, lets say that we had a room here, it was completed mixed, boys and girsl and they all have exactly the same ability and you get on with them all exactly the same, which would you choose?

Sophie: I would probably choose like, I might choose a boy, like they are kind of like smart and they have used the program before, but otherwise I would probably choose a girl.

HIGHERABILITY GENDER

Sophie: If like, if I got on with like, a certain girl and certain guy the same way, I would probably go with the guy, coz then, it's just saying that like, coz everyone thinks that if you're a girl you have to go with a girl, it's just saying that you don't have to go with a girl. If you're a similar ability to a guy and you know that you're exactly the same and you get on with them then sort of you don't have to stick with the girl that might be worse than you or might be a lot better and you don't get on with her.

GENDER

Interviewer: But if she's exactly the same as the boy and you know like you couldn't tell the difference like

Sophie: I don't know

Interviewer: okay. let's say that you were doing this for other girls, so you were advising the teacher, so not for yourselves now, just for the average girl in year 7. Would you advise the teacher to match girls with girls and boys with boys? Everything else is even, would you imagine girls with girls; boys with boys, or would you say no, you're better off mixing them up together?

Emily: mixed GENDER

Sophie: yeah GENDER

Emily: because then they don't, coz if you do girls with girls they normally just chat

GENDER DISRUPTIVE

Sophie: yeah

Emily: and then boys and boys chat, so mix it up and not have like...

Sophie: especially the boys in our classes. GENDER DISRUPTIVE

Emily: ... so I'd have sort of girl boy girl boy coz then, otherwise it's, if it's girl boy boy girl or boy girl girl boy the people in the middle could just talk.

GENDER DISRUPTIVE

156

Interviewer: okay, so lets say, so split them into mixed, now lets say that you give the option of themes, so you give one option which is to do a text adventure game and one option which is to do a shop, a clothes shop. Do you think that might have an issue with it?

Emily & Sophie No. GENDERTOPIC

Emily: because you could have it, you don't have to have it like this, but you could either have the clothes shop, sort of like maybe Next where it's got both girls and boys

GENDERTOPIC

Interviewer: so here I'm balancing the two coz obviously your ideal is to mix them up and give them the option, what's more important, that you give the partners the choice over what they're doing and so they could choose to do the clothes shop or they could choose to do the text adventure, or is it more important that you say girl boy girl boy

Sophie: I think it's more important that you say girl boy girl boy, coz they'll like get on more, they'll get more done and they'll like sort of like liten to each other coz there's nothing to talk about

GENDER PRODUCTIVE

Emily: yeah - the same GENDER PRODUCTIVE

Interviewer: Erm, what advice, and we've covered some of it, if you had to advise a teacher for now, or maybe year 9, if you had to advise a teacher on how to pair students together, what rules would you give them, what would you say to do?

Emily: If girls like chat like normally when they're not in pairs when they like sit in a row, like all girls they like chat, they don't get on, don't pair them together. But if they're other girls in the class that they don't talk to and they probably wouldn't have anything to talk about, they could go with them. Sort of the same with boys.

GENDER DISRUPTIVE

Interviewer: So are you saying that, so like you two I think that worked, is that fair?

Emily & Sophie yeah

Interviewer: so like you two, lets say you were quiet in the class, pairing the girls together would actually be a good thing, you could then do a theme that you liked and you worked well together, but if I see you chatting in the classroom, just about chit chat, then I will want to split you up

GENDER MOTIVATION

Emily: yeah, if it's TV, whatever is on TV then yeah GENDERTOPIC

Interviewer: I'm with you. Do you agree with all of that

Sophie: yeah GENDERTOPIC

Interviewer: okay.

Emily: the same with boys GENDERTOPIC

157

Interviewer: so you said that you'd partner girls with boys or possibly girls with girls if they're not going to chat, is there anything, what other advice would you give?

Sophie: I would say probably, like, erm

Emily: use that timer that we had so you just sort of switch like left right

CLOCK

Interviewer: okay, and for making the partners in the beginning what other things would you ask them to look for

Sophie: Erm they'd be like

Emily: same ability maybe, or around the same ability SAMEABILITY

Sophie: yeah SAMEABILTY

Interviewer: so around the same ability

Sophie: either about the same, or maybe if it was a girl with a boy, maybe the girl might have more coz girls are more sensible as girls are more sensible than the boys in year 7, so.

SAMEABILITY GENDER

Interviewer: so you could have a girl with slightly more ability. Do you think if you had a girl with a boy and the girl had slightly less ability that that might be a problem?

Sophie: no, because like

Emily: because boys sort of remember things and can like explain things okay. And girls sort of like catch like sort of what they say and.

GENDER EXPLAIN

Interviewer: do you think that pairing someone that's slightly lower, be it a boy or a girl, that they might be slightly less confident than someone who's stronger

Sophie: erm. maybe yeah. coz some people could get really shy with someone they don't work with usually.

FEAR

Emily: mmm,hmm [agreement]

Sophie: so maybe like, sometimes people won't be able to choose their own partners coz otherwise people would always like, it will always be like dead silence and sometimes silence isn't all that fun and you can't like express your ideas with the other person. So I think like, yeah.

IDEAS

Interviewer: okay. so if you had the class, so it's my first lesson but you kind of know each other, do you think it would be better for me as the teacher to pick who's partnering by similar abilities and girl boy, or do you think in the first lesson I'd be better off letting you guys choose who to pair with

Emily: choose CHOOSE

Sophie: I think in the first lesson they can be able to choose coz then you can see if they work together

CHOOSE

Emily: and who could work together if it's like a girl that talks alot that they get on with the work and don't talk about much while they're doing the work, I think that would be like fine, unless the next lesson they just talk, then I wouldn't like have them go together.

DISRUPT

158

Interviewer: And you agree with that?

Sophie: yeah

Interviewer: I think we're nearing the end. So obviously you worked with partners, how did working together help over working alone.

Emily: you could bounce of each other any ideas that you had IDEAS

Sophie: yeah, erm like.

Emily: work out what we're going to do IDEAS ALGORITHM

Sophie: like [pause]

Interviewer: can you give any examples?

Sophie: er, well,... the turtle ALGORITHM

Emily: one bit I got, I think we both got something wrong in one bit

ALGORITHM

Sophie: yeah

Emily: then with the turtle we didn't get the angle right, and when we tried to do the triangle...

ALGORITHM

Sophie: erm

Emily: we eventually got it, but just like bouncing off each other with like different angles that we could sort of work out, could work

IDEAS ALGORITHM

Sophie: and with the turtle we took it in turns with what to name the turtle and that was quite fun

SHARING ENJOY

Interviewer: and are there any other examples, you said about getting ideas, any other examples where you helped each other?

Sophie: with the tree I think, we worked together IDEAS HELP

Interviewer: uh-huh

Sophie: yeah and like

Emily: and like the erm, text adventure, the game, we thought of an idea, and thought of a couple of ideas and then mixed them together, because we had like a quiz and then we had two ideas of like the quiz, I think we had a...

IDEAS

Sophie: a youtube quiz IDEAS

Emily: a youtube quiz and a youtuber quiz, so I think IDEAS

Sophie: we chose the youtube quiz IDEAS

Emily: so like whose the IDEAS

Sophie: whose the youtuber who lives in Brighton IDEAS

Emily: lives in Brighton with cats. And then for youtube we did whose the girl with 8 million subscribers or something like that

IDEAS

Interviewer: and do you feel that having a partner helped you to learn more

IDEAS

Sophie: yeah IDEAS

Interviewer: okay, and can you give any examples where you felt you were learning more because of it?

159

Sophie: like, when we were switching partners the other person new more, so they could help you with like

CHANGEOVER ZPD HELP

Emily: so one person knew more ZPD

Sophie: so like after Emily's turn she knew more so ZPD

Emily: then we switched, so if it was my go I knew more, then we switched so I helped her sort of like get the first bit of it and then when she got that bit she knew more and helped me so we just sort of went back and forth with knowing more knowing

CHANGEOVER ZPD HELP

Interviewer: okay. I'm conscious of the time and I've asked some of the other people some of these bits in detail. I just want to ask one question like, if you had a choice of doing this again, so you're doing this again, if you had a choice working as a pair or individually which would you pick?

Emily & Sophie Pair PAIR

Interviewer: and what's the, what's the biggest reasons for that?

Sophie: erm, so we can learn from each other and share our ideas with each other and someone to talk to about the work and stuff like that

LEARN IDEAS

Emily: yeah the same LEARN IDEAS

Interviewer: the same things, okay.

Sophie: yeah

Interviewer: we've covered everything now but is there anything else which we haven't covered which you think is really important where you'd like to say that was good, that wasn't good, we like this...

Emily: I liked the fact that we had two keyboards and two mouses and the leaflet to go by. We just sort of like, so some of the time we typed something and we didn't know what to type and they could just type it on their keyboard instead of having to move it.

DUALKEY EFFICIENCY

Interviewer: so do you feel that two keyboards helped

Emily: yeah DUALKEY

Sophie: yeah DUALKEY

Interviewer: would you both want two keyboards again or one?

Emily & Sophie two DUALKEY

Emily: coz otherwise you've just got to pass them. And they had an idea and so just say.

DUALKEY IDEAS EFFICIENCY

Interviewer: You said you liked having the clock...

Emily: yeah, that was good CLOCK

Interviewer: did you like it aswell? CLOCK

Sophie: yeah. CLOCK

Interviewer: what about in between when you switched having high five and saying something.

160

Sophie: That was quite fun HIGHFIVE SHOUT

Interviewer: you would keep that in aswell HIGHFIVE SHOUT

Sophie: mmm-hmm [confirmation] HIGHFIVE SHOUT

Interviewer: would that be appropriate for people in year 9 aswell. AGEAPPROPRIATE HIGHFIVE SHOUT

Sophie: mmm... [pause]. I think it's more like a year 7 to 8 thing coz it's more like kiddy friendly

AGEAPPROPRIATE HIGHFIVE SHOUT

Emily: yeah AGEAPPROPRIATE HIGHFIVE SHOUT

Interviewer: I think having something to break it up helps because then you know that it's changing...

Emily: yeah CHANGEOVER

Interviewer: ... how would you change that to make it a bit more for year 9 or 10

Emily: maybe have something in your hand so that while you weren't typing you had something in your hand, and if it was like a marble or a golf ball or rounders ball you sort of roll it to the other person

CHANGEOVER

Interviewer: so it could be like one of those stress balls that sits there to show who's in charge and then you move it over to the person who's in charge?

Emily: yeah CHANGEOVER

Sophie: yeah CHANGEOVER

Interviewer: Okay. Do you have any ideas

Sophie: mmm... no. CHANGEOVER

Interviewer: Do you think though that there should be something so that people know that they've moved to the different person or there shouldn't be?

Emily: there should be CHANGEOVER

Sophie: there should be CHANGEOVER

Emily: coz if like, say if the board goes off or maybe the sound cuts out, you don't know when to switch so

CLOCK

Interviewer: okay

Emily: so if the teacher tells you to switch then you pass it, so you can't like rely on the board, you. Whatever you did you rely on, you.

CLOCK CHANGEOVER

Sophie: also I think it's important to have something to say when you need to switch, otherwise one person will have like 10 minutes and the other person will have like 2 or 3 minutes, and it wouldn't be really fair.

SHOUT

161

Interviewer: so do you feel that the system we had was fair?

Sophie: yeah. FAIRNESS CLOCK SHOUT HIGHFIVE

Interviewer: would you be stricter and say you can only type when it's your go or would you have it like we had?

Sophie: no I'd say, have it how we had FAIRNESS CLOCK SHOUT HIGHFIVE

Interviewer: would you agree?

Emily: yeah FAIRNESS CLOCK SHOUT HIGHFIVE

Interviewer: okay.

Emily: so you could sort of just like, if you need to type something to it, you can say wait I've got to type something and then just.

DUALKEY

Interviewer: is there anything else you want to bring up?

Emily: no.

Interviewer: that's really really interesting, thank you very much for that girls.

Interviewer: is there anything else you want to bring up?

Emily: no.

Interviewer: that's really really interesting, thank you very much for that girls.

162

Appendix Q – Quiz results distributions

Figure 27 - Quiz 1 marks

Figure 28 - Quiz 2 marks

0

1

2

3

4

5

6

7

0 1 2 3 4 5 6 7 8 9 10

Fre

qu

en

cy

Score

Test 1 Score Distribution

0

2

4

6

8

0 1 2 3 4 5 6 7 8 9 10

Fre

qu

en

cy

Score

Test 2 Score Distribution

163

Figure 29 - Quiz 3 marks

Figure 30 - Quiz 4 marks

0

0.5

1

1.5

2

2.5

3

3.5

0 1 2 3 4 5 6 7 8 9 10

Fre

qu

en

cy

Score

Test 3 Score Distribution

0

1

2

3

4

5

0 1 2 3 4 5 6 7 8 9 10

Fre

qu

en

cy

Score

Test 4 Score Distribution

164

Appendix R – Raw results for pair type and success

Session 1

Perception of partner ability Enjoyment of session Perception of pair success

Same Good Excellent

Same Excellent Excellent

Same Excellent Excellent

Same Excellent Excellent

Same Excellent Excellent

Same Excellent Excellent

Same Excellent Excellent

Same Good Good

Same Excellent Excellent

Same Excellent Excellent

Same Excellent Excellent

Same Excellent Excellent

Session 2

Perception of partner ability Enjoyment of session Perception of pair success

Same Excellent Good

Better Excellent Didn’t work well

Same Excellent Good

Better Good Good

Same Excellent Excellent

Worse Excellent Excellent

Same Excellent Excellent

Same Okay Didn’t work well

Worse Good Excellent

Better Good Excellent

Better Excellent Didn’t work well

Worse Okay Excellent

Better Good Didn’t work well

Same Excellent Excellent

165

Session 3

Perception of partner ability Enjoyment of session Perception of pair success

Better Excellent Excellent

Same Excellent Excellent

Not as good Excellent Excellent

Same Excellent Excellent

Same Good Excellent

Same Good Good

Better Excellent Good

Same Excellent Excellent

Same Excellent Good

Same Excellent Excellent

Better Okay Didn’t work well

Same Excellent Excellent

Not as good Excellent Excellent

Session 4

Perception of partner ability Enjoyment of session Perception of pair success

Same Excellent Excellent

Better Excellent Okay

Same Excellent Excellent

Same Excellent Excellent

Same Excellent Excellent

Not as good Excellent Excellent

Same Excellent Excellent

Same Excellent Excellent

Better Excellent Excellent

Same Excellent Excellent

Same Excellent Excellent

Better Excellent Excellent

Same Excellent Excellent

Better Excellent Excellent

Same Excellent Excellent

166

Appendix S – Descriptive statistics for pair success

Participants were asked how they perceived their partners ability (Same ability, More able partner,

Less able partner). They were then asked the extent they enjoyed the session and the extent which

their pair was successful. These were ranked from Excellent (3.00) to Bad (0.00).

Table 5 - Enjoyment of sessions for different ability partners

N Minimum Maximum Mean Std. Deviation

Same ability 36 .00 3.00 2.8056 .57666

More able partner 12 1.00 3.00 2.5833 .66856

Less able partner 6 1.00 3.00 2.5000 .83666

Table 6 - Success of partnership for different ability partners

N Minimum Maximum Mean Std. Deviation

Same ability 36 .00 3.00 2.7500 .60356

More able partner 12 .00 3.00 1.6667 1.37069

Less able partner 6 3.00 3.00 3.0000 .00000

167

Chapter 8 - References

Aiken, L. R. (1997). Psychological testing and assessment (9th ed.) (Vol. x). Needham Heights, MA,

US: Allyn & Bacon.

Bailey, K. D. (1994). Methods of Social Research. Simon and Schuster.

Black, P., & Wiliam, D. (2006). Inside the Black Box: Raising Standards Through Classroom

Assessment. Granada Learning.

Braught, G., Eby, L. M., & Wahls, T. (2008). The Effects of Pair-programming on Individual

Programming Skill. In Proceedings of the 39th SIGCSE Technical Symposium on Computer

Science Education (pp. 200–204). New York, NY, USA: ACM.

http://doi.org/10.1145/1352135.1352207

Braught, G., MacCormick, J., & Wahls, T. (2010). The Benefits of Pairing by Ability. In Proceedings of

the 41st ACM Technical Symposium on Computer Science Education (pp. 249–253). New York,

NY, USA: ACM. http://doi.org/10.1145/1734263.1734348

Braught, G., Wahls, T., & Eby, L. M. (2011). The Case for Pair Programming in the Computer Science

Classroom. Trans. Comput. Educ., 11(1), 2:1–2:21. http://doi.org/1921607.1921609

Bruner, J. S. (1966). Toward a Theory of Instruction. Harvard University Press.

Bruner, J. S. (1979). On Knowing: Essays for the Left Hand. Harvard University Press.

Bruner, J. S. (1986). Actual minds, possible worlds. Cambridge, Mass ; London: Harvard University

Press.

Bruner, J. S. (1996). The Culture of Education. Harvard University Press.

Bryant, P. (2003). Piaget, mathematics and Vygotsky. In Piaget, Vygotsky & Beyond: Central Issues in

Developmental Psychology and Education.

Campbell, D. T., & Fiske, D. W. (1959). Convergent and discriminant validation by the multitrait-

multimethod matrix. Psychological Bulletin, 56(2), 81–105. http://doi.org/10.1037/h0046016

Carter, G., & Jones, M. G. (1994). Relationship between ability-paired interactions and the

development of fifth graders’ concepts of balance. Journal of Research in Science Teaching,

31(8), 847–856. http://doi.org/10.1002/tea.3660310807

Carver, J. C., Henderson, L., He, L., Hodges, J., & Reese, D. (2007). Increased Retention of Early

Computer Science and Software Engineering Students Using Pair Programming. In 20th

Conference on Software Engineering Education Training, 2007. CSEET ’07 (pp. 115–122).

http://doi.org/10.1109/CSEET.2007.29

Chao, J., & Atli, G. (2006). Critical personality traits in successful pair programming. In Agile

Conference, 2006 (p. 5 pp.–93). http://doi.org/10.1109/AGILE.2006.20

168

Chaparro, E., Yuksel, A., Pablo, R., & Bryant, S. (2005). Factors affecting the perceived effectiveness

of pair programming in higher education. Psychology of Programming Interest GRoup 17th

Workshop, 5–18.

Chong, J., & Hurlbutt, T. (2007). The Social Dynamics of Pair Programming. In 29th International

Conference on Software Engineering, 2007. ICSE 2007 (pp. 354–363).

http://doi.org/10.1109/ICSE.2007.87

Cliburn, D. C. (2003). Experiences with Pair Programming at a Small College. J. Comput. Sci. Coll.,

19(1), 20–29.

Cohen, L., Manion, L., & Morrison, K. (2013). Research Methods in Education. Routledge.

Coman, I. D., Robillard, P. N., Sillitti, A., & Succi, G. (2014). Cooperation, collaboration and pair-

programming: Field studies on backup behavior. Journal of Systems and Software, 91, 124–134.

http://doi.org/10.1016/j.jss.2013.12.037

Daniels, H. (2002). Vygotsky and Pedagogy. Routledge.

Denner, J., & Werner, L. (2007). Computer programming in middle school: How pairs respond to

challenges. Journal of Educational Computing Research, 37(2), 131–150.

Denner, J., Werner, L., Campe, S., & Ortiz, E. (2014). Pair Programming: Under What Conditions Is It

Advantageous for Middle School Students? Journal of Research on Technology in Education,

46(3), 277–296. http://doi.org/10.1080/15391523.2014.888272

Denzin, N. (1997). Triangulation in Educational Research. Educational Research Methodology and

Measurement an International Handbook.

Denzin, N. K. (1970). The Research Act in Sociology: A Theoretical Introduction to Sociological

Methods. Butterworths.

DfE. (2013). National curriculum in England: computing programmes of study - GOV.UK. Retrieved

June 19, 2015, from https://www.gov.uk/government/publications/national-curriculum-in-

england-computing-programmes-of-study/national-curriculum-in-england-computing-

programmes-of-study#key-stage-3

Dillman, D., Smyth, J., Christian, L., & Stern, M. (2003). Multiple answer questions in self-

administered surveys: the use of check-all-that-apply and forced-choice question formats.

Dorling, M., & Walker, M. (2014). A computational thinking guide & Progression Pathways

assessment framework including computational thinking: KS1 (Y1) to KS3 (Y9). Retrieved from

http://community.computingatschool.org.uk/resources/2324

Douglas, J. D. (1985). Creative Interviewing. Books on Demand.

Ernst, M., & Byra, M. (1998). Pairing Learners in the Reciprocal Style of Teaching: Influence on

Student Skill, Knowledge, and Socializaton. Retrieved July 15, 2015, from

169

http://search.proquest.com/openview/c33acd11a6111d30c0ed75be9063bd93/1?pq-

origsite=gscholar

Fielding, N., & Fielding, J. (1986). Linking data. Beverly Hills, CA: Sage, 4.

Friedman, H. H., & Amoo, T. (1999). Rating the Rating Scales (SSRN Scholarly Paper No. ID 2333648).

Rochester, NY: Social Science Research Network. Retrieved from

http://papers.ssrn.com/abstract=2333648

Furber, S. (2012). Shut down or restart? The way forward for comuting in UK schools. The Royal

Society.

Gibbs, G. R. (2008). Analysing Qualitative Data. SAGE.

Gove, M. (2012). Michael Gove speech at the BETT Show 2012 - Speeches - GOV.UK. Retrieved June

19, 2015, from https://www.gov.uk/government/speeches/michael-gove-speech-at-the-bett-

show-2012

Gronlund, E. N. L. (1990). Measurement and evaluation in teaching. Retrieved from

http://pgim.srilankahealthrepository.org/handle/123456789/11651

Hanks, B. (2006). Student Attitudes Toward Pair Programming. In Proceedings of the 11th Annual

SIGCSE Conference on Innovation and Technology in Computer Science Education (pp. 113–

117). New York, NY, USA: ACM. http://doi.org/10.1145/1140124.1140156

Hanks, B. (2008). Problems Encountered by Novice Pair Programmers. J. Educ. Resour. Comput., 7(4),

2:1–2:13. http://doi.org/1316450.1316452

Hanna, G. (1993). Better teaching through better measurement. Harcourt College Pub.

Hattie, J. (2013). Visible Learning: A Synthesis of Over 800 Meta-Analyses Relating to Achievement.

Routledge.

Hooper, S., & Hannafin, M. J. (1988). Cooperative CBI: The Effects of Heterogeneous versus

Homogeneous Grouping on the Learning of Progressively Complex Concepts. Journal of

Educational Computing Research, 4(4), 413–424. http://doi.org/10.2190/T26C-3FTH-RNYP-

TV30

Jadud, M. C. (2006). Methods and Tools for Exploring Novice Compilation Behaviour. In Proceedings

of the Second International Workshop on Computing Education Research (pp. 73–84). New

York, NY, USA: ACM. http://doi.org/10.1145/1151588.1151600

Johnson, B., & McClure, R. (2004). Validity and Reliability of a Shortened, Revised Version of the

Constructivist Learning Environment Survey (CLES). Learning Environments Research, 7(1), 65–

80. http://doi.org/10.1023/B:LERI.0000022279.89075.9f

170

Johnson, R. B., Onwuegbuzie, A. J., & Turner, L. A. (2007). Toward a Definition of Mixed Methods

Research. Journal of Mixed Methods Research, 1(2), 112–133.

http://doi.org/10.1177/1558689806298224

Katira, N., Williams, L., & Osborne, J. (2005). Towards Increasing the Compatibility of Student Pair

Programmers. In Proceedings of the 27th International Conference on Software Engineering

(pp. 625–626). New York, NY, USA: ACM. http://doi.org/10.1145/1062455.1062572

Katira, N., Williams, L., Wiebe, E., Miller, C., Balik, S., & Gehringer, E. (2004). On Understanding

Compatibility of Student Pair Programmers. In Proceedings of the 35th SIGCSE Technical

Symposium on Computer Science Education (pp. 7–11). New York, NY, USA: ACM.

http://doi.org/10.1145/971300.971307

Kerlinger, F. (1970). Foundations of behavioral research. Holt, Rinehart & Winston.

Kvale, S. (2008). Doing Interviews. SAGE.

LeCompte, M. D., Preissle, J., & Tesch, R. (1993). Ethnography and Qualitative Design in Educational

Research. Academic Press.

Lewis, C. M. (2010). How Programming Environment Shapes Perception, Learning and Goals: Logo vs.

Scratch. In Proceedings of the 41st ACM Technical Symposium on Computer Science Education

(pp. 346–350). New York, NY, USA: ACM. http://doi.org/10.1145/1734263.1734383

Lewis, C. M. (2011). Is pair programming more effective than other forms of collaboration for young

students? Computer Science Education, 21(2), 105–134.

http://doi.org/10.1080/08993408.2011.579805

Likert, R. (1932). A technique for the measurement of attitudes. Archives of Psychology, 22 140, 55.

Lofland, J. (1971). Interactionist imagery and analytic interrupts. Human Nature and Collective

Behaviour: Papers in Honour of Herbert Blumer.

Lui, K. M., & Chan, K. C. C. (2006). Pair programming productivity: Novice–novice vs. expert–expert.

International Journal of Human-Computer Studies, 64(9), 915–925.

http://doi.org/10.1016/j.ijhcs.2006.04.010

Marti, E., & Rodriguez, C. (2012). After Piaget. Transaction Publishers.

McDowell, C., Werner, L., Bullock, H. E., & Fernald, J. (2003). The Impact of Pair Programming on

Student Performance, Perception and Persistence. In Proceedings of the 25th International

Conference on Software Engineering (pp. 602–607). Washington, DC, USA: IEEE Computer

Society. Retrieved from http://dl.acm.org/citation.cfm?id=776816.776899

McDowell, C., Werner, L., Bullock, H. E., & Fernald, J. (2006). Pair Programming Improves Student

Retention, Confidence, and Program Quality. Commun. ACM, 49(8), 90–95.

http://doi.org/10.1145/1145287.1145293

171

McDowell, C., Werner, L., Bullock, H., & Fernald, J. (2002). The Effects of Pair-programming on

Performance in an Introductory Programming Course. In Proceedings of the 33rd SIGCSE

Technical Symposium on Computer Science Education (pp. 38–42). New York, NY, USA: ACM.

http://doi.org/10.1145/563340.563353

Mendes, E., Al-Fakhri, L. B., & Luxton-Reilly, A. (2005). Investigating Pair-programming in a 2Nd-year

Software Development and Design Computer Science Course. In Proceedings of the 10th

Annual SIGCSE Conference on Innovation and Technology in Computer Science Education (pp.

296–300). New York, NY, USA: ACM. http://doi.org/10.1145/1067445.1067526

Mendes, E., Al-Fakhri, L., & Luxton-Reilly, A. (2006). A Replicated Experiment of Pair-programming in

a 2Nd-year Software Development and Design Computer Science Course. In Proceedings of the

11th Annual SIGCSE Conference on Innovation and Technology in Computer Science Education

(pp. 108–112). New York, NY, USA: ACM. http://doi.org/10.1145/1140124.1140155

Miles, M. B., Huberman, A. M., & Saldana, J. (2013). Qualitative Data Analysis: A Methods

Sourcebook. SAGE Publications.

Morrison, K. (2012). Causation in Educational Research. Routledge.

Mortimore, P., Sammons, P., Stoll, L., Lewis, D., & Ecob, R. (1988). School Matters: the Junior Years.

Wells: Open Books. Retrieved from http://eprints.ioe.ac.uk/2889/

Müller, M. M. (2007). Do programmer pairs make different mistakes than solo programmers?

Journal of Systems and Software, 80(9), 1460–1471. http://doi.org/10.1016/j.jss.2006.10.032

Nagappan, N., Williams, L., Ferzli, M., Wiebe, E., Yang, K., Miller, C., & Balik, S. (2003). Improving the

CS1 Experience with Pair Programming. In Proceedings of the 34th SIGCSE Technical Symposium

on Computer Science Education (pp. 359–362). New York, NY, USA: ACM.

http://doi.org/10.1145/611892.612006

Newman, D., Griffin, P., & Cole, M. (1989). The Construction Zone: Working for Cognitive Change in

School. Cambridge University Press.

Onwuegbuzie, A. J., & Leech, N. L. (2005). On Becoming a Pragmatic Researcher: The Importance of

Combining Quantitative and Qualitative Research Methodologies. International Journal of

Social Research Methodology, 8(5), 375–387. http://doi.org/10.1080/13645570500402447

Oppenheim, A. N. (2000). Questionnaire Design, Interviewing and Attitude Measurement.

Bloomsbury Publishing.

Papert, S. A. (1980). Mindstorms: Children, Computers, And Powerful Ideas. Basic Books.

Papert, S., & Harel, I. (1991). Situating constructionism.

Patton, M. Q. (2014). Qualitative Research & Evaluation Methods: Integrating Theory and Practice.

SAGE Publications.

172

Phongpaibul, M. (2007). Experimental and Analytical Comparison Between Pair Development and

Software Development with Fagan’s Inspection. ProQuest.

Piaget, J. (1972). Psychology and epistemology: towards a theory of knowledge. Harmondsworth:

Penguin.

Piaget, Jean. (1936). Origins of intelligence in the child. London: Routledge.

Redline, C. D., Dillman, D. A., Carley–Baxter, L., & Creecy*, R. H. (2005). Factors that influence

reading and comprehension of branching instructions in self–administered questionnaires.

Allgemeines Statistisches Archiv, 89(1), 21–38. http://doi.org/10.1007/s101820500189

Rogers, C. (1992). The Social Psychology of the Primary School. Psychology Press.

Rubin, H. J., & Rubin, I. S. (2011). Qualitative Interviewing: The Art of Hearing Data. SAGE.

Saleh, M., Lazonder, A. W., & Jong, T. D. (2005). Effects of within-class ability grouping on social

interaction, achievement, and motivation. Instructional Science, 33(2), 105–119.

http://doi.org/10.1007/s11251-004-6405-z

Salinger, S., Zieris, F., & Prechelt, L. (2013). Liberating Pair Programming Research from the

Oppressive Driver/Observer Regime. In Proceedings of the 2013 International Conference on

Software Engineering (pp. 1201–1204). Piscataway, NJ, USA: IEEE Press. Retrieved from

http://dl.acm.org/citation.cfm?id=2486788.2486962

Salleh, N., Mendes, E., & Grundy, J. (2012). Investigating the effects of personality traits on pair

programming in a higher education setting through a family of experiments. Empirical Software

Engineering, 19(3), 714–752. http://doi.org/10.1007/s10664-012-9238-4

Schmidt, E. (2011, August 26). Eric Schmidt’s MacTaggart lecture - full text. The Guardian. Retrieved

from http://www.theguardian.com/media/interactive/2011/aug/26/eric-schmidt-mactaggart-

lecture-full-text

Seidman, I. (2013). Interviewing as Qualitative Research: A Guide for Researchers in Education and

the Social Sciences. Teachers College Press.

Shayer, M. (2003). Not just Piaget; not just Vygotsky, and certainly not Vygotsky as alternative to

Piaget. Learning and Instruction, 13(5), 465–485. http://doi.org/10.1016/S0959-

4752(03)00092-6

Shayer, M., & Wylam, H. (n.d.). The distribution of Piagetian stages of thinking in British middle and

secondary sex differentials. British Journal of Educational Psychology.

Sibieta, L. (2015). Schools Spending. Institute for Fiscal Studies. Retrieved from

http://www.ifs.org.uk/uploads/publications/bns/BN168.pdf

Siegler, R. S., & Ellis, S. (1996). Piaget on Childhood. Psychological Science, 7(4), 211–215.

173

Simon, B., & Hanks, B. (2008). First-year Students’ Impressions of Pair Programming in CS1. J. Educ.

Resour. Comput., 7(4), 5:1–5:28. http://doi.org/10.1145/1316450.1316455

Slaten, K. M., Droujkova, M., Berenson, S. B., Williams, L., & Layman, L. (2005). Undergraduate

student perceptions of pair programming and agile software methodologies: verifying a model

of social interaction. In Agile Conference, 2005. Proceedings (pp. 323–330).

http://doi.org/10.1109/ADC.2005.48

Srikanth, H., Williams, L., Wiebe, E., Miller, C., & Balik, S. (2004). On pair rotation in the computer

science course. In 17th Conference on Software Engineering Education and Training, 2004.

Proceedings (pp. 144–149). http://doi.org/10.1109/CSEE.2004.1276524

Stephen, G., & Chris, T. (2004). Combining Methods In Educational And Social Research. McGraw-Hill

Education (UK).

Stylianou, S. (2008). Interview Control Questions. International Journal of Social Research

Methodology, 11(3), 239–256. http://doi.org/10.1080/13645570701401289

Tashakkori, A., & Teddlie, C. (2010). SAGE Handbook of Mixed Methods in Social & Behavioral

Research. SAGE.

Teale, W. H. (1981). Parents Reading to Their Children: What We Know and Need to Know. Language

Arts, 58(8), 902–912.

Teddlie, C., & Yu, F. (2007). Mixed Methods Sampling A Typology With Examples. Journal of Mixed

Methods Research, 1(1), 77–100. http://doi.org/10.1177/2345678906292430

Thomas, L., Ratcliffe, M., & Robertson, A. (2003). Code Warriors and Code-a-phobes: A Study in

Attitude and Pair Programming. In Proceedings of the 34th SIGCSE Technical Symposium on

Computer Science Education (pp. 363–367). New York, NY, USA: ACM.

http://doi.org/10.1145/611892.612007

Turbak, F., Royden, C., Stephan, J., & Herbst, J. (1999). Teaching recursion before loops in CS1.

Journal oOf Computing in Small Colleges, 86–101.

VanDeGrift, T. (2004). Coupling Pair Programming and Writing: Learning About Students’ Perceptions

and Processes. In Proceedings of the 35th SIGCSE Technical Symposium on Computer Science

Education (pp. 2–6). New York, NY, USA: ACM. http://doi.org/10.1145/971300.971306

Vygotsky, L. (1978). Mind in society: the development of higher psychological processes. Cambridge,

Mass. ; London: Harvard University Press.

Vygotsky, L. (1981). The genesis of higher mental functions - The concept of activity in Soviet

psychology.

Vygotsky, L. (1982). Om barnets psykiske udvikling [On the child’s psychic development].

Copenhagen: Nyt Nordisk.

174

W3C. (2014, October 28). HTML5. Retrieved from http://www.w3.org/TR/html5/

Wadsworth, B. J. (1978). Piaget for the classroom teacher. Longman.

Wason, P. C., & Johnson-Laird, P. N. (1972). Psychology of Reasoning: Structure and Content. Harvard

University Press.

Wells, D., & Williams, L. (2003). Extreme Programming and Agile Methods - XP/Agile Universe 2002:

Second XP Universe and First Agile Universe Conference Chicago, IL, USA, August 4-7,

2002.Proceedings. Springer.

Werner, L., & Denning, J. (2009). Pair Programming in Middle School. Journal of Research on

Technology in Education, 42(1), 29–49. http://doi.org/10.1080/15391523.2009.10782540

Werner, L. L., Campe, S., & Denner, J. (2005). Middle School Girls + Games Programming =

Information Technology Fluency. In Proceedings of the 6th Conference on Information

Technology Education (pp. 301–305). New York, NY, USA: ACM.

http://doi.org/10.1145/1095714.1095784

Werner, L. L., Hanks, B., & McDowell, C. (2004). Pair-programming Helps Female Computer Science

Students. J. Educ. Resour. Comput., 4(1). http://doi.org/10.1145/1060071.1060075

Williams, L., & Kessler, R. R. (2003). Pair Programming Illuminated. Addison-Wesley Professional.

Williams, L., Kessler, R. R., Cunningham, W., & Jeffries, R. (2000). Strengthening the Case for Pair

Programming. IEEE Software, 17(4), 19–25.

Williams, L., Layman, L., Osborne, J., & Katira, N. (2006). Examining the compatibility of student pair

programmers. In Agile Conference, 2006 (p. 10 pp.–420). http://doi.org/10.1109/AGILE.2006.25

Williams, L., Layman, L., Slaten, K. M., Berenson, S. B., & Seaman, C. (2007). On the Impact of a

Collaborative Pedagogy on African American Millennial Students in Software Engineering. In

Proceedings of the 29th International Conference on Software Engineering (pp. 677–687).

Washington, DC, USA: IEEE Computer Society. http://doi.org/10.1109/ICSE.2007.58

Wood, D. (1998). How Children Think and Learn. Wiley.