Paired programming: an agile software development technique in which two programmers work as a pair together on one workstation. One, the driver, writes code while the other, the observer, pointer or navigator, reviews each line of code as it is typed in. A pair will usually take 15% longer than an individual tackling a problem, but will generally produce code with 15% less defects. (Definition and stats)
I work at a place where it’s expected you pair program 99% of the time, if not 100%. I have a mostly-love, sometimes-hate relationship with paired programming. Sometimes, I think it’s the best thing in the world, and I can’t imagine working anywhere that doesn’t do paired programming. Other times, I feel like I’m losing my mind. There are days where I think my pair is the coolest person ever, and we’re working as if we have one mind, but sometimes there are other days where my pair is this weird alien that speaks another language.
My favorite thing about pairing is seeing how someone else likes to solve a problem. I feel like you learn so much about another person in the way that they go about thinking through a problem. Some people like to write the tests first and see them fail before touching anything else. Other people like to make sure that the user interface is fully tweaked first. There can be a major focus on the normal functionality with an afterthought to the edge cases or the edge cases can be the priority. Some people like to hack something together and then refactor after it’s working, and others like to refactor as they go. All in all, it’s very interesting to see different people solve the same problem in a variety of ways.
When you are learning a new language or getting familiar with a new project, pairing is the best way in my mind to get familiar with it. You get a fast glimpse into the shared, tribal knowledge like why one tech stack was chosen over another, what sacrifices were made, and how the project is structured overall. As a person new to a language, I love to be able to see how, why, and when people use certain methods and syntax. I definitely learn faster that way than taking any tutorial.
I also love pairing because it brings you closer to your coworkers. When you have to work closely with everyone, you become more committed to the success of a team. It’s harder to blame one person for a problem that was created because you have shared ownership of the code. Almost every single line of code was supposed to have been seen by at least two people. Not only that, but you get to know all of your coworkers on a more personal level. As an extrovert, knowing all of my coworkers on a more personal level makes work so much more fun for me. It’s easier to empathize with others when there are problems instead of blame people for not meeting an impossible standard of perfection.
On the flip side, paired programming drives me insane sometimes. Depending on who you’re pairing with, it can be hard to get a in rhythm with a person to create a cohesive solution. You might have a completely different idea of how things should happen than the other person, and fight longer than it would have taken you to complete the problem in the first place. You could be working with someone who gets defensive when the other person calls out an error in the approach. If you’re working with someone who considers themselves to be more experienced than you, you can run into situations where it feels like you have to fight to be heard, whether it’s to point out a problem with the approach or just point out a syntax error.
Generally, you get different results depending on the experience level of both people in the pair. If two people are considered ‘experts’, the two people can build up each other and provide intellectual stimulation. Or, one person can trust that the other person knows what they’re doing and sit back and do nothing, essentially taking away many of the benefits of pairing. If an ‘expert’ is pairing with a person that is considered a ‘novice’, then the ‘expert’ may get burnt out on being in a teaching role. On the same note, the ‘novice’ may become disengaged if they let the ‘expert’ take care of things. It’s easy to fall into a situation where the ‘novice’ feels as if they are following along and learning things until they have to do it on their own. A ‘novice’ might not feel comfortable arguing with the ‘expert’ or the ‘novice’ might argue a lot in order to prove their worth to the ‘expert’. If a ‘novice’ pairs with another ‘novice’, they can solve problems much faster than they would on their own, but they might also reinforce bad practices between each other.
I definitely struggle with feeling like I know how to do things with a pair until I have to do them on my own. Sometimes, I need to time and freedom to make a mistake and then learn how to fix it instead of being prevented from going down that path by my pair. I get frustrated when pairing when I don’t see the solution as fast as my pair, and I need time to poke around and get my bearings in the code. On the flip side, I get frustrated sometimes when I see the solution but my pair needs more time. The worst for me is when neither one of us sees the solution, and somebody snaps from frustration. It is similarly bad when one person disengages and then gets frustrated when something is taking longer than they expected.
My favorite days are when I’m pairing with someone and we are both completely in sync with what the problem is and how we are going to solve it. There are few things more rewarding at work than working through a difficult problem with your pair and then seeing all of the tests pass. I love it when I am pairing with someone with more experience than me, and I can teach them something new or point out something that they are missing. Conversely, I love pairing with a person with less experience than me so that I can figure out what their learning style is and try to teach effectively teach them best practices. In all cases, I find that I’m constantly improving my ability to communicate with others as well as learning things at a faster pace compared to being alone. Overall though, I like paired programming way more than I liked programming on my own.
3 thoughts on “Paired programming is awesome! Paired programming sucks!”
I consider this to be the canonical article on pairing with a junior developer: https://devmynd.com/blog/2015-1-pairing-with-junior-developers. I think everyone doing any pair programming should read it.
I love that article. I wish more people would take it to heart.
I loved pair programming in my undergrad since I found it so much easier to learn new concepts and work through difficult homework if I had someone to brainstorm with and even if we got stuck, we were stuck together so it was less frustrating. I’ve definitely heard the stories of how it can go wrong, but most of the time that seems to happen when one or both aren’t putting in the effort to “do pair programming right” ha.