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 ig...
For further actions, you may consider blocking this person and/or reporting abuse
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 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.
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.
"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
"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.
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.
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."
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.
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...
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.
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.
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.