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?
Top comments (23)
My colleagues and I tend to apply pair programming regularly, but only when it's useful, and as long as it is useful. It helps us tackle hard or complex problems (and we only use it for that purpose). The way we apply it, it's also definitely 'pair programming' and not just 'pair coding', since we fairly often briefly move to a meeting room to talk over the problem and possible sketch it out.
Do you follow through on the problem as a pair completely to the end? That is, after the meeting room do you sit at a computer (just one) and code the solution as a pair?
I'm asking since I've regularly had programming meetings in pairs, but we've almost always broken up after that meeting. On rare occassions I've had somebody else help me with code, but certainly nothing formal.
That mostly depends on the problem and on the outcome/conclusions of the impromptu meeting: sometimes the conclusion and the decided course of action is so cut-and-dried that, essentially, the problem that was no longer is. In that case, usually only one person continues with the actual implemention. In other cases, the result of the meeting is an avenue to explore via coding, and in that case we continue attacking or unravelling the problem together, behind a computer.
This flexible and adaptable approach sounds entirely reasonable to me.
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)
I don't use pair programming very often - I usually prefer to have the people I'm working with also coding. However, there is one individual with whom pair programming is an amazingly productive experience. He's my assistant lead developer (I'm the lead), and I directly trained him when he first joined the company. Although I have many years experience over him, it doesn't turn into mentoring time.
We first discovered we liked working this way by accidentally, when we were both working on the same section of code. Instead of trying to copy each other's changes, he had me take over all the typing, and we'd be talking through the entire logic. It was quite productive, and some of the most fun we've had in coding.
I guess the point is this: no practice should be followed religiously. What works marvelously for one situation and group may not work well at all for another. There are virtually no methodologies and practices that work always or never.
I can definitely see that it works for some people at times. And I think it's good that people try things out to see what works for them as a team.
You are right that no practice should be followed religiously. It's probably unfortunate that pair programming is something that is often presented as an ideal that a whole team should follow. I'm less skeptical when I hear it being used occassionally and with willing partners.
I try to pair program at least once or twice a week and find it very productive. Even when our coding levels couldn't be more different, I think how differently we think helps the process and quality of code that we write. If I'm less familiar, I'll ask a question to clarify and my partner voicing helps refocus our efforts. If they are "driving" and I'm familiar enough with the what we're doing then while they are focusing on the code being typed, I'm kind of 'eye in the sky' catching typos or odd syntax in real time. When we run into a particularly annoying bug, while one of us is doing exploratory debugging, the other is consulting documentation and other resources that might shed light on the issue. And the final thing I appreciate about it is that I've found myself way more likely to push through difficult blocks sooner when I'm pairing and tbh I'm not sure why. Maybe it's because someone else besides me is also invested and I want to succeed more for the both of us or that even though I'm putting in more effort and spending longer amounts of time, because I'm sharing the process ( aka double the knowledge base, double the resourcefulness, double the thought/idea sharing might equal only half the stress/frustrations for me.
I've paired with every engineer member of my team at least once in the last 2 months and am definitely a fan, but if you don't enjoy the process I don't think you should have to force yourself. If I felt pressured to do it, I doubt I'd be so fond of it. In my team we take on issues/tickets at will and are free to offer to pair with someone or open ourselves to being consulted on an as needed basis if they're working on something we find interesting/want to learn more about/ if we can offer some uniquely helpful/expert support. Alternately you can voice your interest in getting a pair partner for any issue you're working and those willing step forward. It has made me particularly more confident in assigning myself to issues that I deeply want to try my hand at but that are without a doubt above my current ability to tackle alone :D.
I'm glad that you are finding it effective. What I find interesting is that you say you only do it once or twice a week. Does this mean that you nonetheless spend most of your coding alone (or rather, not in a formal pair programming arrangement)?
Regardless of what we call it, I'm strongly in favour of having members of a team work together on small projects. It provides a good knowledge exchange and can help people share knowledge. But the "pair programming" I have concerns about is a specific process with rules and expectations. Would you say what you do is truly pair programming, or more of a informal cooperation?
Hiya, yeah I think we're definitely on the same page regarding the awesome of team contribution :). I pair "at least" once or twice a week, but I meant that in reference to specific issues instead of instances. I pair until the new feature is shipped or issue resolved whether that means a duration of only 30 mins - a few hours in a single day or regularly scheduled meeting times over the course of a few weeks. How much time I spend coding solo or pairing shifts each week based on the complexity and priority of the issues I'm currently working on that would benefit from it. I'm generally working on multiple tasks during the week at the same time (some programing and others product/UX/research).
IMO it is truly pair programing since: 1 workstation is used, one of us is driving focusing of strategy/improvement, the other is navigating focusing on tactical implementation of the code, and we switch roles during the process. I feel all of that still fits the agile method core values and principles of the practice where "requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams.[1] It advocates adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change". The informal nature my company takes to the forming of pairs, letting them naturally arise from preferences of the engineer assigned to a task or inspiration to form a pair based on team opinion that 2 of us would benefit from teaming on a particular issue due to our strengths and domain knowledge-base that relate to aspects of the task, and how we schedule out when/how we'll meet to fit work on the issue into both of our schedules around our other responsibilities is more team culture IMO. I'm ok with the rules and expectations of pairing currently, but my understanding/experience of them doesn't include the pure coding you mention. I super support your wanting to explore ways the methodology and others miss the mark though. Nothing's perfect and questioning accepted behaviors often leads to great discussions and growth.
"Pair programming is forcing me to serialize my thought process, which is a significant hindrance" that's true and I feel always tired the rest of the day when I paired for a long time. But there are also benefits, like:
I'd like to believe that certain processes have certain benefits, but I don't think we should accept that without some kind of evidence.
As my article indicates, pairing puts a drain on my mental capacity, and I highly doubt it could yield a more creative solution, if anything it'd limit my freedom in the process. This may vary based on experience in position however, as I indicated.
As to code quality, I see a lot of places that indicate this, yet I'm not seeing any kind of definitive proof of this. There are many ways to improve code quality. I doubt having multiple eyes watching the original coding inherently makes it any better.
Why would you think that pairing increases the time a developer can focus on a problem? If this is anecdotal evidence then I can offer my own anecdotal evidence that I've known many developers that can focus for very long periods of time on their won. I've indeed known many that have no ability to focus unless on their own.
I don't want to dismiss your points, as I suspect in some cases they are likely true. There are certainly people that can work well together, and pair programming is probably a good option. My overall concern with the approach is that descriptions of it are not well balanced, and fail to provide the bounds within which it is effective.
"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."
Agree. And in my experience what happens, in the best escenario, is that one member of the pair ends up taking ultimate control, and the other just learns and gives opinions... Being honest and pair a more experienced programmer with a Jr, will help the junior to learn if the experienced dev, has the mentoring bug in him... otherwise is juts an ego fight
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.
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.
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.
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."
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.
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...
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.
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.
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? ;)