I learnt about pair programming at university when we were studying Agile methodologies. At the time it seemed very full-on — almost scary. I pictured myself stumbling over my keyboard as my co-worker facepalmed behind me. In reality, pair programming sessions have helped me to evolve as a developer and I actually find it more relaxing to tackle something as a team of two.
Do you mind if I drive?
Driving means being in control of the mouse/keyboard. Navigating is watching, and depending on the pair's style, might be dictating what is to be written or there to raise questions, problems, and muse on design. Find a more detailed break down of the roles here (first written by Jordan Poulton).
I saw a study which claimed that during a conversation we give the other person around three times longer to respond to us than we give ourselves when it is our turn to respond. I think that the same holds true while pair programming because I've felt under pressure at times. I can remember plenty of instances of myself making endless typos (that I missed until they were pointed out) and forgetting basic structures of code, worrying that the navigator was getting bored while waiting for me to finish my code-thought. However, I can't remember any of my co-workers ever doing anything of the sort. Everyone has uniformly been brilliant.
It may seem odd to the uninitiated that two developers working on one ticket can be more efficient than if they were working on two tickets separately. One of the reasons is the level of focus and that can be maintained by the driver. Someone watching you code will catch silly errors that your linter might not. This saves building and testing time. Instead of googling easy questions (and context switching) you can throw them behind you and stay in your IDE. Being able to discuss ideas helps with creative problem-solving. I find that my mind wanders less because my partner is always there to point me back to our design. Rabbit holes can be nipped in the bud — e.g. one of us saying "Let's not optimize this part yet".
For me, it's a comfy atmosphere, it's fun. I've seen it referred to as an "automatic bi-directional rubber ducky".
When debugging, the best course of action is to break the problem down to its smallest parts — removing assumptions and finding out which parts you know for sure 100% work. However, it's hard to get rid of your own assumptions and later on you'll find out that something you held to be true was, in fact, the path to the solution. While pair programming, it's easier to approach the problem with more logic as there is a second pair of eyes that must be convinced of every assumption being held.
Pairing is good for when:
- You're stuck!
- You're new and want mentoring
- The team needs shared knowledge
- There is one time-sensitive feature
Some tickets don't require it
I've read about peoples' experiences at companies where every line of code is pair programmed. I'm curious about the benefit of such a requirement. I imagine that the bus factor of a team would be incredibly low. But I'm thinking about the stories and bugs where I'm working in parts of the codebase that I know well. Where most of the work is setting up boilerplate code and some tests.
My favourite setup that I've experienced so far is a team where pair programming was left up to the developers. If we felt that a ticket required pair programming to be efficient then all we had to do was let our manager know that was the plan.
As a mentor
Over the past year, I've been teaching my wife how to code. The largest jumps in her knowledge are when we've tackled a feature or a project as a pair-team. It gives me a chance to observe how she goes about tackling a problem and lets me guide her down the right path (or at least close to it). While I'm driving, the most helpful things she's reported watching are the steps that aren't coding but are more knowledge-based e.g. setting up a dev environment, proper version control, different test suites and CI/CD integrations.
N.b.
This reads a little like propaganda from the Pair Programming Institute (tm). Some people don't mix well with pair programming and may find it distressing and inefficient. And there's nothing wrong with that at all!
Join 150+ people signed up to my newsletter on programming and personal growth!
I tweet about tech @healeycodes.
Top comments (14)
Been using/encouraging it for the past 3-4 months to teach my team new stuff.
We even resort to mobbing occasionally, when I introduce new concepts fx. We will sit together and implement a feature so everyone has an idea of how it works.
I have 3 juniors on my team, and so far the feedback has been great, and productivety has been boosted greatly. :)
That's awesome! Mobbing when there are new concepts is a great idea.
I find pair programming SO useful when there's a difficult debugging task at hand, for all the reasons you mention. It can be very useful to have a second brain on standby to challenge assumptions!
I also agree it's excellent for learning and mentoring - I've picked up so much from pair programming and seeing someone else's approach to a problem, not just the resulting code. Plus, challenging myself to explain what I'm doing and why has helped solidify a lot of my own learning and soft skills :)
Yes, I always learn new stuff!
It's a lot better to watch someone write it and ask the questions there and then instead of watching it go through code review.
The big thing is not everything needs to be paired. I appreciate you calling that out. I pair all day everyday where I work. If we are doing boilerplate stuff the navigator may take a moment to check on our outstanding pull requests, or do something else to make us more efficient.
Pairing is just another tool in your toolbox, and is far from a golden hammer.
"I've read about peoples' experiences at companies where every line of code is pair programmed [...] My favourite setup that I've experienced so far is a team where pair programming was left up to the developers"
Absolutely. I recently worked in a company where pair programming was enforced all the time by managers who didn't understand the benefits of pair programming.
It practically has made me hate it, when in fact I used to love it.
PS: Good to see Jordan being mentioned here in the dev community :)
Thanks for sharing Carlos, that’s very interesting.
Jordan’s breakdown of the pair programming roles is really great!
We use a similar approach in our company with a timer of 15 minutes to switch between Driver and Navigator. We also follow the process where one person is writing the test and other fixing it as we follow strict TDD process.
I have written a similar article describing how it benefit us
linkedin.com/pulse/happy-developer...
Thanks for sharing that resource. The timer approach sounds really interesting.
Hey Andrew!
I'd like to know which "soft-skills" would you address to the navigator and which to the driver?
Are there any?
Hi!
The same soft-skills that are used when reviewing code apply. E.g. asking questions instead of telling or directing, being patient and polite, and giving the other person time to respond. As well as an attitude that even a fresh junior can teach the most senior person new skills. These apply for both the driver and the navigator.
I would be interested to hear other peoples' input on this question. For me, different pairs behave in different ways depending on seniority and whether you two are friends or not.
Absolutely agree. Just read a great article earlier today about this topic
bloomberg.com/opinion/articles/202...
Thanks for sharing! Some interesting facts there 👍🏻
Ok, great article, but: would you be available to do pair programming with me? :D