Paired Programming – introducing the driver, navigator roles

Years ago, I took over a year ten class who had low confidence and a low regard for programming. I remember being observed on a lesson with them, and I had decided to introduce paired programming, in a hopeful attempt to inspire more work and improve the classroom climate. Fortunately, my hopes transpired to reality and by the end of the lesson I had students excitedly swapping seats and completing simple programs. So, I’m a bit disappointed that things have got in the way and I’ve not made use of this pedagogy for the last few years. I’ll forgive myself slightly and blame the pandemic… But really the success was something that stuck in my mind and so now I’m in a similar situation I decided to try it again… 

 

Paired Programming: 

Paired programming involves – at least in my understanding/ implementation- having two students work on the same project. Often, they are allocated roles. One is a driver, and one is a navigator. Now, this can mean different things but for us the driver was the student typing the code and the navigator was giving the directions. The driver could verbally question and prompt but could not type anything unless instructed. They had a ten-minute timer for tasks set and after five minutes the roles swapped. 

 

What happened? 

There was some laughter and eye rolls as I explained the set up. I let the students choose the pairs (I can see benefits in both allocating and choosing) and they logged on. 3 challenges were on the board assessing basic selection. Some students were quite slow to start but eventually everyone was beginning. Two students put their hand up to say they were done. These are my bottom two students so I went over to check their code. They had made a good start but there was a couple of mistakes so they needed a few prompts. Very shortly after they had a working solution. For motivation, I put their names on the board next to challenge 1 to show they had completed. This seemed to add fuel to the class. Suddenly, hands were up asking for help or saying they were done. Students were telling off other pairs for not following the rules and navigators were telling their programmers to drive faster. At the end of the ten minutes a couple of pairs had not finished the three tasks- all have completed two. So we modelled the third task together on the board, addressed potential misconceptions and restarted for a next round.  

The leaderboard consistently changed and students seemed much more vocal in asking for help. If trying this, I would really recommend keeping track of the students progress for this extra motivation. I was constantly circulating around and had to speak to one pair in the class for not being on task with their discussion/using the internet to find answers, which wasn’t allowed for this lesson. I gave students ten minutes at the end of the lesson to write down any code that they were particularly proud of/ developed new skills so they had a record of it in their books and asked students to feedback what they wanted more practise with to inform next lesson. They fed back they wanted more practice with using steppers in for loops. I had a gained a lot of insight from listening to the paired discussions and from their individual contributions. 

The lesson went better than I had hoped. It was a very nice atmosphere and it is probably the longest the students had coded themselves/with pairs, without asking for teacher input/scaffolding. Now, I know every task/class/school etc is different so I am not suggesting that this will work for everyone. However, after today’s success it is definitely something I am going to be trialling again. There’s lots of pedagogy and discussions surrounding how to implement this successfully so I’ve popped two sites below. If you try it out and have any reflections I’d love to hear them too! 

Summary points/recommendations: 

• Check the pairs, see who you may need to be around more to help 
• Circulate often- verbalise what you are seeing. 
• Have timings 
• Swap roles often (could consider swapping the pairs if needed) 
• Keep a leader board  
• Pause and go over the main points of a program 
• Pause and question, predict/go over potential misconceptions 
• Check the programs when students say they are done 
• Allow students some time to be creative and create their own code/add to a program scenario given 

What is Pair Programming? (techtarget.com) 

Pair Programming: What It Is, Why People Use It, and How You Can Learn To Pair Program | Codecademy