Pair programming feels like a lingering ghost. Its adherents proclaim it to be the best approach to coding while the rest of us just continue to ignore it. I've only tried it a few times. Based on those few experiences, and what I read, I'm not interested in trying it again. I'm a huge fan of collaboration, mentoring, and code review, but this idea of sustained pairing just isn't appealing to me. Let me attempt to figure out why.
If you regularly do pair programming, please share how your experience contrasts to my opinions here. I'd like to see what I'm missing or misunderstood.
Dichotomy of experience
One of the tenets of pair programming is that both members must be equally contributing to the process. If this is not the case, then you end up with more of a mentoring situation. I love mentoring, but it's not the same.
Gaps in experience are expected in a job. I'm not just talking about "raw skill", I mean everything from one's familiarity with the code, to their understanding of the business, to their background in the field. Given any activity, it's inevitable that one individual is more suited to the purpose than the other.
With a significant gap, I don't see how a pairing won't just become mentoring. While it's great that knowledge will be shared, I'm uncertain how we could prevent a significant productivity drop of the dominant partner.
If I understood correctly, this gap is precisely one of the things pair programming is meant to address. It's supposed to narrow the gap. I can see this happening for a new project member, at least for the first month, but I don't believe the total experience gap will ever narrow -- it would imply the senior partner is remaining stagnant.
Serialized thoughts
Shared experiences require the individuals to think in a similar linear style. To be open to feedback it's important that my mind focuses on the code I'm writing. If I'm thinking anything, it's important that I speak it out loud, letting my partner share in my thoughts. My outward actions must clearly map to my inner processes.
The problem is that I don't work that way. The code I write is fragments of a total vision I have in my head. I'll come and go from various source files piecing together that vision. It'd likely appear chaotic at times. If you were to interrupt my stream and ask out the bits, you'd throw me off-track, and it might take me a while to collect my thoughts and explain.
Of course, I can explain the code I've written; it's important to be able to do this. The problem is the online requirement of sharing this knowledge. Pair programming is forcing me to serialize my thought process, which is a significant hindrance.
Continual sharing is also a load on the brain. Progress is massively hampered whenever the problem is too much for me to both analyse and speak at the same time. I'll admit this isn't true of most of our work, but these problems do come up.
Isn't it pair "coding"
Programming is about a lot more than just coding, refer to my article I'm proud to be a programmer. Yet in all descriptions I've seen, pair "programming" is really about producing code. Maybe it should be called pair "coding". The terminology itself isn't my concern; I'm wondering how it fits into the bigger picture.
I don't see coding as a distinct phase of the programming process. There's a continual flow between writing code, analyzing requirements, talking to other team members, writing a fix on another branch, doing research, posting to online forums, eating a thoughtful sandwich, then eventually coming back to the original code.
I'm suspicious of any process that allows individuals to allocate large chunks of uninterrupted time to pure coding. Something seems off. Were the requirements so clear as to not need more feedback? Was the individual's background such a perfect fit that they don't need to do any research? Pair programming is supposed to stave off such isolation, yet appears to require it at the same time.
Tooling and remote work
To a programmer that's optimized their environment, it can be a shock to work with somebody else's environment. Many minor changes, like colour selection, keyboard positioning, screen height, font selection, and more, alter my productivity. I can eventually adjust, but every time I switch results in a productivity drop. I experience this whenever I need to work on either of my laptops, when I do a live stream for coding, or when I connect to a remote system.
Remote is also a problem. There are a lot of benefits to being out of the office, either one day a week, or as a permanent remote worker. I don't see how pair programming, as envisioned, can work in this situation. The tooling I've seen isn't sufficient to support it. Both parties would be subject to a foreign environment, with an accompanying productivity drop.
Why not work together?
Perhaps my biggest critique of pair programming is this overriding need to work as a single enlightened individual rather than as two members of a team. Why can't both people be coding at the same time? Why can't one be writing tests and the other functional code? Why can't one be doing some research and the other tracking down a defect?
I've had good experiences with two people focused on a problem, but both working at it from different directions. There's a continual sharing of ideas, reviewing code, and asking for assistance. The team relationship is fluid and doesn't require anybody give up their tools. It also doesn't matter if there's an experience gap -- it's okay if they're working at different speeds, and the junior member has access to mentor as needed. Why can't this be pair programming?
Latest comments (23)
I've never found a partner I like. I guess with what I'm trying to code if one guy's knows linear algebra and how to manipulate formula forms for optimization, (dropping variables we don't need from the official formula, etc) and I stick to compilers or general code structure it could be enjoyable. I guess it has to be more like a real relationship / friendship, where one partner focuses on a specific field of programming. Probably less useful for generalists.
It just sounds like you didn't give yourself enough opportunities to really try pair programming (and even mob programming), as you said it yourself.
There are so many different ways of trying this technique. There is the traditional way, which seems that it was the one you tried. But there is also promiscuous pairing, micro-pairing, TDD pairing, etc.
My eureka moment of pair programming was attending a Woody Zuill's talk (about mob programming), when he mentioned a strategy where, if you have an idea and want to input it in the code, you have to use someone else's hands. That is, the one in the keyboard (the driver) is inputting the idea of the navigator. This would solve some of the issues you mentioned in the article.
So, I'd say try a few more pairing/mobbing strategies, because the benefits of pairing way outweigh its cons. As Woddy said: "No one is better than all of us."
My 2c:
I have always worked as a lone developer. I do embedded F/W, the other engineers in the companies I've worked for have always been full H/W folks. I will often do whiteboard sessions with a H/W engineer to get a more thorough understanding of an issue, or to allow us to understand the requirements for both S/W and H/W.
However, once that is done I can sit down at the computer and bash out the code. There are lots of useful process to go through to improve such output: test, refactoring, QA and so on. Outside of those processes however I would see having someone I have to explain everything to just to get the code onto a keyboard to be a bottleneck. Vice versa, having stuff explained to me that I should then type, does not seem like something it would be possible to remain engaged with for longer than a very short period.
Having never tried it I obviously have bias and as a lone developer there are obviously areas where feedback would be very helpful but is just not available, I don't think the process of getting code onto a keyboard is one of those areas though.
One thing I'd like to know: Where can I get a thoughtful sandwich? ;)
At work I rarely do pair-programming (with a small dev-team it's hard to allocate two devs to the same task) but I did it for 3-months when I was first learning how to code.
My partners were all new to coding like me, yet another pair of eyes meant we were able to fix bugs and spot problems together much quicker than had we been working on our own. We were able to help ourselves and that gave us confidence, which helped us learn that much faster.
I think pair-programming works best when the partners are a similar level and a good use-case in business would be on-boarding new developers, getting to grips with a new code base.
Pair programming (coding) is one paradigm. There are many flavors within that paradigm and many of that ways of coding.
It is my belief that quality can exist/be ignored in any model.
Piar programming (especially coupled with TDD) focuses on the future state of the codebase by emphasizing the importance of quality over speed.
It is always easy to slap together features in a greenfield project. This is when the code base is 'fun'.
BUT, it is soul crushing to work in a legacy monolith spawned by this feature bloated context heavy labyrinth built upon work arounds, God functions, and a foundation created by a founder's first poc... explaining to stakeholders why can't we move like the good old days... especially explaining that the gold old days CAUSED the dismal hell we live in today.
Piar programming should be a tool in your tool box. Have a junior struggling, pair him/her. Struggling with quality, pair dev + coach. Trunk based development with continuous delivery to production, pair 2 strong seniors. Team struggling to distribute knowledge, mob program silos away...
A significant problem I've experienced is that some people may not be able to work together like this due to personality differences that go beyond the configuration of the work environment. Some people's personalities just clash, for example, pairing a very silent introvert with a chattering extrovert. Both may be very good programmers individually but they simply won't collaborate productively. Eventually, the situation turns toxic.
Hi Ed, great discussion!
I'm a huge fan of Pair Programming as a default (there are no silver bullets in life, so if folks want to un-pair it's fine, but it's mostly pairing). By the time we got acquired by Pivotal Labs, we had about 120 pairs at Xtreme Labs.
In my experience, I see:
Whether the engineers were both senior or senior/junior, both parties learned a lot as part of the experience. It's rarely just one person mentoring (juniors usually ask all the best questions, which leads to the senior evaluating exactly why you do things the way you do)
In terms of predictable velocity, the idea of pairing keeps everyone on topic more easily. Less distraction = less total hours on the task, but each hour is more productive. It also allows you to jump back into flow more quickly.
I think pairing allows many more types of folks into the field. We had about 25% female engineers (which is higher than normal. Not 50% unfortunately), and very low attrition to boot.
Happy to talk about this more!
A few links:
Your mileage may vary (every person and every company is different), however, I would try it for at least 2-3 months (like Yoga!) before realizing it's not a fit. It actually takes 2-3 weeks just to get used to working full 8-intense hours a day 😂
Cheers,
Farhan
p.s. it looks like we overlapped at Trilogy for a short while (I was there from 98-01)
My main experience with pair programming was in school, where during labs we would group up at computers and work through a problem presented to us. Thus I see pair programming as having a great benefit for people who want to learn and have equivalent experience. I actually learned a lot during those labs, sometimes more so than when I was doing homework, but often it just helped me look at programming in a new way.
I honestly don't see pair programming as being as beneficial in a professional setting, since the goal isn't really to learn but to solve a business problem and the reasons you described in your article.
I agree with you. I'm a very slow learner when it comes to coding / programming. I was not very happy with the course that I took as it was fast paced, staff exited and new staff came in, or staff would alternate so we were exposed to different styles of learning and coding every day, and many outside issues came into play (life).
As we were students in a classroom environment, pair programming was required every so often. I realized clearly that I was a lagging weight on many partners who learned much quicker than myself. It did not do much for my confidence or my learning that I was spending too much time trying to keep up, writing or copying code I didn't understand, and worrying about aggravating anyone due to my need to dig deeper into things they shrugged off as unimportant in their quest to appease the instructors. I like the idea of having mentors. I need it. Pair programming in my humble opinion, again as a novice, is not ideal.
This same time of pressure to produce exists in a lot of work environments as well. If it's supposed to be a "pair" you might find colleagues that also consider one an anchor. This is why I prefer to make it more informal, or consider it mentoring. If the other person knows his goal isn't to produce code, but to get you to produce code, the dynamic is very different.
If you find the other person is also unwilling to mentor you, then that's a whole other story.
Spot on, very well explained ... I believe there CAN be situations where it could be useful, especially as a "brainstorming session behind the keyboard" when figuring something out that you can't on your own, but it has to be applied very selectively, not as the daily norm.