Firstly, what is pair programming? It’s two developers sitting together, usually at one computer, where one types code and the other checks the code. In essence, it involves two developers who are thinking about different aspects of the same programming feature, and are constantly communicating in order to keep their understanding in sync. Some of you may know this already. Apart from this very short introduction, I can really only tell you about my own personal experiences with it. But first I’ll tell you a little bit about me.
I am a front end developer currently working at Edenspiekermann in Berlin, where I code alongside many talented and friendly developers and designers. It’s my second ever job as a developer, and in total, I’ve been working as a developer for less than a year. Other facts about me include that I’ve lived and worked in six countries (including the Netherlands where I got a masters in Psychology), I really love writing, I really really love my developer community and my favourite text editor is VS Code.
My current career in tech is exciting, full of opportunities and it’s fast-paced. My past career in psychology involved learning how to understand and help people. The mix of these two careers has led me to take an interest in the more human side of web development, and how we can all feel better about the jobs we do. I believe that the better we feel about what we do, the better the results of our work will be for everyone. The reason I want to write about pair programming is entirely selfish. It’s something that makes me feel much, much better about the job I do and I want to share with you the reasons why.
I don’t want to give you a list of pros and cons. I think comparing the pros and cons is a bit impersonal, which makes it difficult to connect any of the benefits with your own experiences. Instead, I’ll be telling stories about my own and others’ experiences. I hope that these can click and resonate with you.
To me it seems some of the hardest things for a new developer, and also any developer who is just beginning at a new company are getting used to the company culture, learning how members of the team do their best work, and getting acquainted with the codebase.
At work, we have dev couch every Monday. All the developers sit together for an hour to discuss what they’ve been working on. We recently began to collect topics we’d like to take a deep dive into. One of the senior developers suggested we discuss the idea of starting cross-team code reviews. His thoughts were that, while it was a smaller step than launching straight into pair programming, it wouldn’t exactly hurt the levels of communication, collaboration, and knowledge of the company codebases. Over the next few weeks, he gently reinforced the idea while reminding us that we could take it slowly, and nobody was forcing us to review or pair with each other all the time. This casual and unpressured approach helped the practice to become more common. And I loved it - it helped me feel more comfortable communicating and collaborating with other developers.
As code reviewing increased, I started to feel better about asking for feedback on my work. This is something I can find hard to do because I rarely want to bother busy people and don’t want to be seen as incompetent. It also made me feel like a more integral part of the company as a whole, and I know I’m not the only developer who began to feel more like this. The all-around good vibes reminded me of a past experience of mine that I want to tell you a little story about.
It’s about one interview I attended in London last year. I sat with a lovely senior developer who told me we were going to solve a coding challenge together. He must have sensed my nervousness because he began by reassuring me that I wouldn’t be doing it all myself, and the exercise was to get a good idea of how I work. We chose the ‘game of life’ challenge. I hadn’t heard of it before. We got straight into it and with what little Javascript experience I had, we got through a good amount of it in 45 minutes. Afterwards, he had a lot of encouraging things to say to me and I felt comfortable and valued by him. I did end up taking another job in the end because London is just so expensive. However, I won’t ever forget how it took less than an hour to feel valued and worthy as a developer, and during an interview no less.
I heard such a variety of things from other developers who I asked about pair programming. Every story was different. Nobody had had the same, or even a similar experience with pair programming. Some people had always done it, some never. Some companies only pair program! Some had never wanted to, and some want to but can’t. Some only ever found one person they were really comfortable pairing with The message that rung loud and clear is that pair programming doesn’t work in every situation. That’s fair enough. There are many factors at play. Here’s a little story from one developer I talked to.
This developer said to me: "For years, I didn’t pair program. Then I started working with a new developer. I was very much into high-end CSS and code quality, and my new friend was a fantastic problem solver (which I wasn’t). So, we both managed to learn from each other and the resulting work was just better than what any of us could have done on our own. We ended up pairing for months, and for 6 to 8 hours a day! Especially on complex stories. Despite reservations from our product manager, we enjoyed success. The reasons I see for our success are as follows: Our skills complemented each other, we could see the big picture and edge cases more clearly, mistakes were minimised, we reduced the knowledge island and bottlenecks, we gained shared ownership of the code, and pushed each other’s learning and expertise further." To bring a dose of reality to this warm and fuzzy sounding tale, the developer finished their story reconfirming my suspicions that pair programming isn’t for everyone. They told me that they know developers who simply prefer working on their own, or need space to focus and be in the zone. The fact that everyone has different personalities, means pairing with others shouldn’t be forced upon anyone, and even if people do pair, there is no set time limit or a set way to do so.
So, there’s no roadmap. There’s no step-by-step guide in a readme file to successfully install pair programming. In the end, it all depends how you feel about it. Well, and how your company feels about it. In essence, it is flexible.
For a hint at how flexible pair programming is, I want to take a quick look into some of the different types. For the sake of clarity, I’ll describe junior developers as novices, and seniors as experts.
We have the one that most people probably think of - the driver - navigator. This is the one I described at the beginning. It's where the driver uses the computer and controls the main actions. The navigator answers questions and points out potential problems. This can work for an expert and novice where the novice is the driver, but it can also work great for two experts as well.
Then we have the backseat navigator. Like driver-navigator, the driver sits with hands on the keyboard and types. However this time, the navigator dictates tactical instructions. This could mean telling the driver when to create a method or open a new file. Or what to name a test or a variable. This style works best with the novice as driver, and the expert as the navigator. It gives the novice (i.e someone like me) a chance to learn by doing things the way the expert would.
The last driving-based metaphor we have is the tour guide. Imagine being a tourist, getting on a bus, enjoying the scenery while someone explains to you what you are seeing. This works really well when the novice is the tourist, and the expert is the tour guide. The expert does the technical thinking, the problem solving and the typing, and, crucially, explains what is happening at every turn. This is the type of pairing I did right at the beginning, and I still do a lot of today. Again, the roles can be switched - with the novice being the tour guide and the expert being the tourist.
Lastly - and nothing to do with driving, we have ping-pong-pairing. This is the most fun type to say out loud. It’s all about unit tests and test-driven development. The first person writes a failing test and the second gets it to pass. Then the second person writes a failing test and the first gets it to pass. So people take it in turns to be on the ball. Kind of like a game of ping pong. This can work well with any combination of novice or expert because it really facilitates communication and focus, and keeps both members of the pair thinking and learning.
Remember how I mentioned that we began to do more code reviews at my work? I want to leave you with one more story that I heard recently.
Two developers I work with (and who also began to take part in the cross-team code reviews) recently decided to spontaneously pair up on a complex set of tasks. Afterwards, during dev couch, they told everyone that they’d achieved beyond what they’d expected, and were really happy with how things went. I asked what type of pairing they’d done, and they said there wasn’t a defined type, and they'd both switched roles a lot. They also said they’d managed to pair for 3 or 4 hours in one afternoon, but thought doing more than that may be too tiring. One developer told me pairing had been really enjoyable as it had enabled both of them to focus really well on the task, and provided much less opportunity to drift off-task and do things like re-factoring code or checking messages. Conversely, the same developer also told me that they usually get the most work done while doing home office.
So, what I am trying to get across with all these stories is that pair programming is a flexible thing with no strict set of rules. It can start with something small like occasional code reviews. It can be something to try to see whether it works well, and bring a pleasant surprise when you find out it does. It can work well for some developers in some circumstances, and not in others. It’s not something that has to be entirely formalised and it can be fit into what works best for you and your team. By the way, after our last retrospective, my team and I created an actionable item stating that pairing should always be considered for more complex stories.
What pairing means to my team mates is more robust code, a greater understanding of the codebase, and a closer relationship with each other.
What it means to me as a new developer is greater confidence, stronger connections with team members, and faster competency. It helps me feel like I am learning at a good pace, and allows me to get welcome feedback from other developers. As a package, this helps me to combat imposter syndrome and feel happier doing my job.
A collaborative exercise like pair programming helps developers of all levels to communicate, push each other forward, and feel more like a team. After all, a stronger team most likely builds stronger things.
Have a think about what pair programming could do for you.
~ This blog post is based on the talk I gave on Sunday 6th May 2018 at the Beyond Tellerrand Düsseldorf side event hosted by InVision. ~