Pair programming is a specific teaching technique where pupils work in pairs to write computer programs. One pupil takes the role of the driver, has control of the computer and writes or manipulates the code. The other pupil takes the role of the navigator, who has the project instructions, reads them out and looks out for any bumps in the road (aka bugs in the code). The roots of this learning technique come from industry, where developers work with a partner on programming tasks.
At our recent staff meeting, we had a mini maker day where we all tried out some of our projects. I worked with my colleague Dan on a Sonic Pi project to code the Tetris theme tune, and we decided to try using pair programming techniques to structure our collaboration. This was the first time I’d tried pair programming for quite some time and it was a really positive experience for me. Here are five things I learned about pair programming along the way:
Coding is fun and pair programming increases that fun – It is very exciting to write code that works. It is enormously satisfying to write code that doesn’t work, debug it and then see it work. Pair programming increases that excitement and satisfaction exponentially as you get to share the “wow, we’ve made that” moments with a partner. Somehow that more than doubles the sense of achievement!
It’s quite hard to stick to the roles rigidly but it was fine when we didn’t – Sometimes we found that we both ended up taking the navigator role as we worked together to try and debug the code. It was useful to look through the instructions together to see if there were any clues or hints that would help us, then look through the code together to find and fix the errors. Once we’d spotted what we needed, we then reverted back to our roles again. This flexibility worked well for us.
Coding is immersive and it’s easy to forget to swap roles – We really enjoyed the Sonic Pi project we worked on together. After we had completed the first section, we swapped roles. We were so engaged in completing the tune though, that we forgot to swap again. We remembered once we’d started to apply what we had learned and write our own tune and then by that time, we ended up staying in set roles based on our skills. In a classroom, I’d definitely use a timer to remind children to swap roles. I’d also spend some time getting children to evaluate their strengths and weaknesses in each role so they can better understand how to use this technique more and more effectively.
There are lots of different skills which make a great pair programmer – I was very lucky to be working with Dan, who was very patient, enthusiastic and open to working together to solve problems. I know my own weakness in pair programming is that when I’m learning something new, I want to be able to do it at my pace. Dan was very good at making suggestions, coming up with ideas and taking the lead so that the pace worked well for us both. I’d like to think that my eye for detail, creativity and resilience also contributed towards the partnership too.
Working in pairs is really helpful for text-based programming languages – In Sonic Pi, there are some syntax rules to follow. Punctuation such as square brackets, commas, and colons need to be in the right place for the code to run without errors. It really helped to read out the full punctuation as well as the words from the project instructions, as this improved the accuracy of the code we were writing.
We were both really proud of what we’d achieved by the end of the session. Not only had we coded the Tetris theme, we’d also made a start on the Star Wars theme. We’d experimented with different sounds, added repeating loops and found a way of adding a drum beat. We both commented that we wanted to explore Sonic Pi further – so maybe we’ll set up another pair programming session in the future!
Computation X 