Pear programming

At Makers, pair programming is very much encouraged and is what I spend most of my time doing. At its core pair-programming is when two developers work together at one workstation. They take it in turns to drive and navigate. The driver writes the code whilst the navigator directs the driver, checking the code for mistakes and identifying potential problems or issues that need to be addressed.

I’m a big proponent of pairing. I find the process of verbalising problems helps me half way to solving them. Moreover, as I am such a newbie, if I was working by myself I would find myself bashing my head against a wall all too often. (Definitely better for two of us to be bashing our heads against the wall!) Having a second perspective with a different approach to the problem is massively helpful. Also, as I’ve discovered over the past couple of months, computers are devilish pedants. They are worse than your friend who corrects you everytime you say ‘who’ instead of ‘whom’. Having someone to spot a stray ‘s’ or missing full-stop can save you a lot of agony when trying to debug.

Pair-programming reminds me of the ancient Jewish tradition of studying texts, such as the Talmud b’chavruta, in pairs. This methodology is one in which students learn in pairs, discussing and debating a shared text. Similar to the driver, navigator set up, often one member of the pair will read, whilst the other pair tries to explain what has been read. The ideas in the texts are challenging to understand, and are there to be challenged. When thinking about ideas yourself, you often just reinforce your already formed views. Being challenged is not a comfortable place to be, but it is an important process to go through. Likewise pair-programming is uncomfortable in many situations because you have to expose your thought process, and therefore your vulnerabilities to your pair. Sometimes you have to admit that you don’t know something, or that your understanding might not be correct. But I believe that this is the way that I will become a better thinker and developer. In programming, especially Ruby, there is never just one way of doing something. Having another perspective I have found to be invaluable.

Yet there seems to be a growing dissatisfaction amongst our cohort with pairing. Around week 5 we were learning around 3 new technologies and testing frameworks I found it extremely difficult to pair. It was hard not to feel swamped by the sheer volume of new information being thrown at us. I just wanted to sit down with a book and the internet to begin to try to get to grips with it all before even attempting to start the project of getting our game of battleships online. One of the main problems seems to be that sometimes you just need time to think for yourself and to be able to process something at your own speed. Last week, ASOS very kindly came in to pair-programme with us, but I can tell you it is far from easy trying to think with someone watching you! However, I have found that good pairs are the ones in which I have space to think things through, and rather than being a hindrance, my pair has built upon my thought process and helped me to develop it. There is always going to be a balance when learning something completely new as to how much time you need to get to grips with the idea before you can start doing, but I think the role for pairing is always there.

Some people have learnt with the same chavruta for years. Clearly some pairs are hugely beneficial. Unfortunately not all pairs will work, or enhance learning. There has to be a mutual understanding of the purpose of the pair, and each pair must give the other person space to think, instead of scaring and stifling their thought process. I have been so lucky to have found so many brilliant people in our cohort who have put up with me, and given me that space to think and to grow my understanding in a way which I doubt would have been possible working by myself. For that, I am deeply grateful.

Hannah