6 ms·

The case for pair programming

51 points by mijustin 8y ago

maxxxxx 8y ago
Pairing with someone you get along with is a great experience. But with a lot of people I find it pretty miserable. I have paired with people who I just almost never agreed with. I am not saying they were bad but I just didn't like their style. There is also the risk of having one very dominant partner and the other one just watching passively (or having checked out already).
mbo 8y ago
The "How to pair with a junior developer" section is extremely considerate, and highlights some behaviours that I know I've subconsciously engaged in that may have negatively impacted a junior dev. Expanding this section would be great.
- carterza 8y ago
  I'd also like to see a section for junior devs, and what they need to bring to the table. Another great section would be how to identify a pairing that is less than ideal / problematic.
- rhacker 8y ago
  It actually makes a great reference. Today during a pair session a new developer happen to mention a technology that might solve X, Y and Z. I think 5 or 10 years ago I would have shut them down - I was much more arrogant back then. Instead in the next few days this person is going to demo something they've built since they are pretty much our team's expert in this tech - since none of the others have used it. If everything checks out, this could very well be our next large architectural shift - and that's incredibly awesome contribution for someone new. Even if it means he'll be putting in a lot of extra work and time - in my eyes that's better than turning him into a robot that wants to check out exactly at 5pm.
projectileboy 8y ago
I used to be a zealot. I had found the religion of XP, and I enforced pairing on teams I was hired to coach. Many people were happy to be exposed to it, but many weren’t. Of those, some were better for the experience, some weren’t. In either case, it was massively disrespectful of me to force it on people. Certain kinds of people are drawn to programming. Asking some of those people to pair all day every day is tantamount to asking them to switch careers. I for one don’t have the emotional energy for it any more. Having said all that, I would encourage any skeptics to give it a try, in the right environment with the right teammates. It can really teach you a lot in a short period of time.
- Waterluvian 8y ago
  I used to love the idea until I really understood what people meant by it. It would be a career change and I'd hate it. What I want is a wingman, not a co-pilot. Someone I'm paired with who learns my code intimately and I learn theirs intimately and we are always supporting each other in PRs and design chats. But ultimately we fly our own aircraft our own way.
- gagege 8y ago
  > Asking some of those people to pair all day every day is tantamount to asking them to switch careers. You got the mail on the head! That's exactly how I felt when I was told to pair program at a job for 6 months.
- beefsack 8y ago
  I feel the more general lesson here is that zealotry in our industry is almost always a bad thing. Whether it be in technology choices, development paradigms, project management techniques, training strategies, or even just how you deal with your staff and coworkers. Whenever I come across a zealot in a professional setting, I'm fairly certain they're intentionally ignorant toward better ways of tackling certain problems (big red flag).
  - projectileboy 8y ago
    I agree, although I would qualify your last statement a bit to allow for (a) the zealot is usually well-intentioned, and (b) the zealot is usually not intentionally ignorant, but rather hasn’t yet learned that context matters.
carterza 8y ago
I find pairing with anyone that is significantly outside the range of your competency level, to be extremely frustrating. You can have a junior dev, and hand hold, but it also requires effort on the part of the junior dev / a desire to learn and grow. Without that, the exercise is futile. IMO - pair programming is over-hyped. I often find that I produce better, more reliable code, with the more space and more time I am given. I agree that pair-programming can rock in certain circumstances - but you need developers that have a certain level of synergy, you can't force it.
- carterza 8y ago
  Another issue with pair programming - the assumption that the benefits which are potentially produced by pairing, are often baked into estimations regarding quality of work and / or deadlines. The current product I work on has had a team of - count em - two developers for the past year. I'm the one that is full-stack, so I get to help the less-experienced developer work on our frontend, while I have minimal time to work on the backend solo (for the most part). My pair programmer partner, also has no interest in learning the new dev-sec-ops our company is pushing - so I get to also solo all of that work. It's an extremely frustrating / soul-crushing scenario to be in. It's basically punishment for exhibiting competence and willingness. It's a situation I'm hopefully out of in the next month.
  - deleted 8y ago
    [deleted]
- carterza 8y ago
  Then - he randomly wants to chime in with tangentially related questions - it's basically all of the pitfalls described in the - working with a junior dev section of the OP's article - except I've tried every one of the tactics described therein, and at some point you have to question whether the junior dev really wants to be a dev or grow at all...
- jacques_chester 8y ago
  > You can have a junior dev, and hand hold, but it also requires effort on the part of the junior dev / a desire to learn and grow. Without that, the exercise is futile. If someone's not interested in learning or growing, I don't see how pairing or not pairing makes a difference.
RandallBrown 8y ago
I worked on a team pair programming for about 3 years. I really enjoyed it. Now that I've moved on to a different company and am working solo again, I really miss pairing. I feel that most of the problems my team has now would be easily solved by pairing. Things like shared standards (not just syntax but architectural approaches that are hard to automate), testing (you keep each other honest), and faster code review. Right now, if there's a bug in feature x, everyone goes to the feature x "guy" to have it fixed. If that person gets hit by a bus, feature x is hosed. People don't have a good idea what anyone else is working on (beyond the few that seem to do most of the code reviews). Swapping pairs every day or two easily solves these problems. Things like on boarding new employees is just so much faster that it's a no brainer to pair, especially when they're starting out. Junior developers learn so much faster by working directly with a senior developer. Sure, it might slow the senior down (very little in my experience) but it makes the junior developer so much more productive in the long run. Pairing is mentally exhausting at first and I can understand that it isn't for everyone. Most people hate it at first, especially if they have a bad setup. Most people I work with seem to think it means 2 people crowded around a single laptop. Setting up real pairing station with multiple BIG monitors and 2 keyboards and mice is crucial. After you get comfortable with it, the "always on" feeling goes away and it just becomes an enjoyable day working closely with your colleagues. If you really give it time, I feel it's the "right" way to develop software. Switching a team to pairing might not be the right decision for everyone. Some people are just uncomfortable working with others. I'm not sure those people will be super strong members of most teams anyway, but they can certainly be successful in some organizations. If you build your team around pairing and select for it in your interview process, you can have really great results.
- maxxxxx 8y ago
  You are right, pairing often fails because companies don't bother to set up the right environment and processes and fine tune them. It's probably the same with things like scrum or remote work. They can work well if the company puts some honest effort into making them work. Most of the time they don't so everything falls apart though
- latchkey 8y ago
  This 1000 times. It should be the top comment on the page. The desktop setup is crucial. 90% of the time when I ask companies if they do pairing and I ask them to describe the setup, it is two people crowded around one laptop and that never works. I can't imagine watching someone type like that. I'd add a few other things that help a lot... a very good PM writing stories that pairs can pickup and run with (and a good management tool everyone knows how to use properly, like Pivotal Tracker), a Monday iteration planning meeting, a Friday retrospective (with whiskey!) and ping pong tables to blow off steam, as a pair. It sounds so cultish meta silly .com programmer... and it is... but it also works really well as long as the majority buys into it. One way I found to introduce this sort of system into a company is to just start with one pairing station (the computer setup described above). Tell people that when they want to pair, they can use it all they want. My experience is that soon enough, you'll be getting requests for more stations.
artsyxxx 8y ago
https://books.google.ca/books/about/Pair_Programming_Illuminated.html?id=LRQhdlrKNE8C https://books.google.ca/books/about/Pair_Programming_Illumin... << Pair Programming illuminated shows all the different kinds of combinations that are possible between programmers of different abilities and experience
erik_seaberg 8y ago
I have to wonder how people make up for never getting into the zone.
- jacques_chester 8y ago
  I pair. The way I make up for getting into the zone while soloing is to get into the zone as frequently or more frequently in a pair.
- taneq 8y ago
  It's possible to get in the zone in a pair. It's much more difficult, though.
- mitchtbaum 8y ago
  I've been pair programming for about 6 weeks now, over Discord. The calling and screen sharing functionalities work so well that my partners and I can join and part quickly and easily. We can get deeply into what we're doing individually. But collaboratively, we can solve problems that neither of us can do alone. I like this virtual setup for multi-user interaction a lot, and hope more tools, even ones specific to virtual programming environments, come for it soon. Tuple's making a remote sharing tool that looks interesting. What comes to mind for me is a shared 3D Wayland environment, like this https://www.youtube.com/watch?v=_FjuPn7MXMs https://www.youtube.com/watch?v=_FjuPn7MXMs so, hopefully more people will start focusing on https://github.com/way-cooler/way-cooler https://github.com/way-cooler/way-cooler and other Rust desktop/handheld application level development.
- wvenable 8y ago
  My best work is when I go off on wild tangents that might not work out (and some don't). I also tend to build wild and then refactor to cleanup later. I'd hate to put someone else through that all the time and I doubt they'd even let me.
city41 8y ago
For contrast, here is an article I wrote that is largely against pair programming: http://www.mattgreer.org/articles/pair-programming-is-not-a-panacea/ http://www.mattgreer.org/articles/pair-programming-is-not-a-...
- rhacker 8y ago
  While I'm pro-pair programming I totally understand these issues. The way I normally go about it is put it out there that I like pair programming. And if other people in the team feels the same way, usually that just clicks. I definitely think PP shouldn't be mandated at all. I think too that some of the issues you bring up are very important - especially about the notion that the soft spoken person will usually have their ideas rejected. A lot of developers act in very peculiar ways often because software development shops can be very toxic. Instead of addressing that toxicity, most places end up with a few head honchos. It really is bad for companies actually and can lead to many great budding engineers to leave or get out of the profession, sadly.
keithnz 8y ago
I started with XP way back in 99 after following the discussions on OTUG and then the white book came out. I PP for 8 -> 9 years. Theres a bunch of things I learnt from that It is really good for improving everyones skills. There is a fast convergence in good way to do things The code quality is generally really good and people often develop good habits, everything gets discussed. It doesn't work so well when people are across different projects, much better if they are all on the same project. Teams reach a point where it doesn't actually matter if you pair or not, you tend to carry on making good code. It can slow down experienced devs and they often don't get the same kind of "flow / mental zone" of coding they can get by themselves. Developers need alone time to do their own coding experiments and to follow their own noses It 100% has to be done right and people need to be open to the idea, I went into other companies who were trying to do it and it was failing massively. There was animosity and a lack of openness to trying it. People really didn't understand why they should do it, and felt coerced and threatened by it all. Untangling those messes seemed ... unproductive :) It's exhausting. These days I don't see the need for full time pairing, I see it more as a tool that has certain outcomes, and you use that tool when you notice certain kinds of problems / weaknesses. I would think that teams should "pair" at some point, and by that I mean watch each other code and have interactive discussion about code as it gets developed.
zaptheimpaler 8y ago
Pair programming: when u need 2 devs to do 1 devs job
- dang 8y ago
  Please don't post shallow dismissals to HN. This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html. Fortunately you needn't look far for good examples of how to do substantive critique; there are some excellent ones in this thread.
rhacker 8y ago
We got rid of the bad breath, smelly ass, coffee spill issues associated with pair programming. It's all remote now using VSCode Live Share and something like BlueJeans or Slack calls to facilitate the communication.
hw 8y ago
How well pairing works also depends on a person's personality. Introverts don't really do well in pairing situations, and especially when paired with someone totally opposite, the pairing essentially becomes a single person coding and the other person just observing and nodding their heads.
- spikej 8y ago
  Along the same lines, this doesn't work if one person is used to working rapidly and the other person takes their time to think things through. I found it only really worked best when I worked with another who worked at a similar pace to mine and we took time to bounce ideas off of each other. We both learned a LOT from each other since we both had strengths in opposing areas
- watwut 8y ago
  Plus beyond introversion, controlling and dominant people make everyone suffer during pairing. Also, shy people non-assertive people loose any possibility of autonomy or independent decision making (they might or might not find it uncomfortable). People who see everything in absolutes are hard to pair with and find it stressful. Extroverts who still like to think about problems silently or explore issues cant do that in pairing either. The human social issues related to pairing are many more areas then just introversion extroversion.

51 points by mijustin 8y ago

Pairing with someone you get along with is a great experience. But with a lot of people I find it pretty miserable. I have paired with people who I just almost never agreed with. I am not saying they were bad but I just didn't like their style. There is also the risk of having one very dominant partner and the other one just watching passively (or having checked out already).

mbo 8y ago

The "How to pair with a junior developer" section is extremely considerate, and highlights some behaviours that I know I've subconsciously engaged in that may have negatively impacted a junior dev. Expanding this section would be great.

carterza 8y ago
I'd also like to see a section for junior devs, and what they need to bring to the table. Another great section would be how to identify a pairing that is less than ideal / problematic.
rhacker 8y ago
It actually makes a great reference. Today during a pair session a new developer happen to mention a technology that might solve X, Y and Z. I think 5 or 10 years ago I would have shut them down - I was much more arrogant back then. Instead in the next few days this person is going to demo something they've built since they are pretty much our team's expert in this tech - since none of the others have used it. If everything checks out, this could very well be our next large architectural shift - and that's incredibly awesome contribution for someone new. Even if it means he'll be putting in a lot of extra work and time - in my eyes that's better than turning him into a robot that wants to check out exactly at 5pm.

projectileboy 8y ago

I used to be a zealot. I had found the religion of XP, and I enforced pairing on teams I was hired to coach. Many people were happy to be exposed to it, but many weren’t. Of those, some were better for the experience, some weren’t. In either case, it was massively disrespectful of me to force it on people. Certain kinds of people are drawn to programming. Asking some of those people to pair all day every day is tantamount to asking them to switch careers. I for one don’t have the emotional energy for it any more. Having said all that, I would encourage any skeptics to give it a try, in the right environment with the right teammates. It can really teach you a lot in a short period of time.

Waterluvian 8y ago
I used to love the idea until I really understood what people meant by it. It would be a career change and I'd hate it. What I want is a wingman, not a co-pilot. Someone I'm paired with who learns my code intimately and I learn theirs intimately and we are always supporting each other in PRs and design chats. But ultimately we fly our own aircraft our own way.
gagege 8y ago
> Asking some of those people to pair all day every day is tantamount to asking them to switch careers. You got the mail on the head! That's exactly how I felt when I was told to pair program at a job for 6 months.
beefsack 8y ago
I feel the more general lesson here is that zealotry in our industry is almost always a bad thing. Whether it be in technology choices, development paradigms, project management techniques, training strategies, or even just how you deal with your staff and coworkers. Whenever I come across a zealot in a professional setting, I'm fairly certain they're intentionally ignorant toward better ways of tackling certain problems (big red flag).
- projectileboy 8y ago
  I agree, although I would qualify your last statement a bit to allow for (a) the zealot is usually well-intentioned, and (b) the zealot is usually not intentionally ignorant, but rather hasn’t yet learned that context matters.

carterza 8y ago

I find pairing with anyone that is significantly outside the range of your competency level, to be extremely frustrating. You can have a junior dev, and hand hold, but it also requires effort on the part of the junior dev / a desire to learn and grow. Without that, the exercise is futile. IMO - pair programming is over-hyped. I often find that I produce better, more reliable code, with the more space and more time I am given. I agree that pair-programming can rock in certain circumstances - but you need developers that have a certain level of synergy, you can't force it.

carterza 8y ago
Another issue with pair programming - the assumption that the benefits which are potentially produced by pairing, are often baked into estimations regarding quality of work and / or deadlines. The current product I work on has had a team of - count em - two developers for the past year. I'm the one that is full-stack, so I get to help the less-experienced developer work on our frontend, while I have minimal time to work on the backend solo (for the most part). My pair programmer partner, also has no interest in learning the new dev-sec-ops our company is pushing - so I get to also solo all of that work. It's an extremely frustrating / soul-crushing scenario to be in. It's basically punishment for exhibiting competence and willingness. It's a situation I'm hopefully out of in the next month.
- deleted 8y ago
  [deleted]
carterza 8y ago
Then - he randomly wants to chime in with tangentially related questions - it's basically all of the pitfalls described in the - working with a junior dev section of the OP's article - except I've tried every one of the tactics described therein, and at some point you have to question whether the junior dev really wants to be a dev or grow at all...
jacques_chester 8y ago
> You can have a junior dev, and hand hold, but it also requires effort on the part of the junior dev / a desire to learn and grow. Without that, the exercise is futile. If someone's not interested in learning or growing, I don't see how pairing or not pairing makes a difference.

RandallBrown 8y ago

I worked on a team pair programming for about 3 years. I really enjoyed it. Now that I've moved on to a different company and am working solo again, I really miss pairing. I feel that most of the problems my team has now would be easily solved by pairing. Things like shared standards (not just syntax but architectural approaches that are hard to automate), testing (you keep each other honest), and faster code review. Right now, if there's a bug in feature x, everyone goes to the feature x "guy" to have it fixed. If that person gets hit by a bus, feature x is hosed. People don't have a good idea what anyone else is working on (beyond the few that seem to do most of the code reviews). Swapping pairs every day or two easily solves these problems. Things like on boarding new employees is just so much faster that it's a no brainer to pair, especially when they're starting out. Junior developers learn so much faster by working directly with a senior developer. Sure, it might slow the senior down (very little in my experience) but it makes the junior developer so much more productive in the long run. Pairing is mentally exhausting at first and I can understand that it isn't for everyone. Most people hate it at first, especially if they have a bad setup. Most people I work with seem to think it means 2 people crowded around a single laptop. Setting up real pairing station with multiple BIG monitors and 2 keyboards and mice is crucial. After you get comfortable with it, the "always on" feeling goes away and it just becomes an enjoyable day working closely with your colleagues. If you really give it time, I feel it's the "right" way to develop software. Switching a team to pairing might not be the right decision for everyone. Some people are just uncomfortable working with others. I'm not sure those people will be super strong members of most teams anyway, but they can certainly be successful in some organizations. If you build your team around pairing and select for it in your interview process, you can have really great results.

maxxxxx 8y ago
You are right, pairing often fails because companies don't bother to set up the right environment and processes and fine tune them. It's probably the same with things like scrum or remote work. They can work well if the company puts some honest effort into making them work. Most of the time they don't so everything falls apart though
latchkey 8y ago
This 1000 times. It should be the top comment on the page. The desktop setup is crucial. 90% of the time when I ask companies if they do pairing and I ask them to describe the setup, it is two people crowded around one laptop and that never works. I can't imagine watching someone type like that. I'd add a few other things that help a lot... a very good PM writing stories that pairs can pickup and run with (and a good management tool everyone knows how to use properly, like Pivotal Tracker), a Monday iteration planning meeting, a Friday retrospective (with whiskey!) and ping pong tables to blow off steam, as a pair. It sounds so cultish meta silly .com programmer... and it is... but it also works really well as long as the majority buys into it. One way I found to introduce this sort of system into a company is to just start with one pairing station (the computer setup described above). Tell people that when they want to pair, they can use it all they want. My experience is that soon enough, you'll be getting requests for more stations.

artsyxxx 8y ago

https://books.google.ca/books/about/Pair_Programming_Illuminated.html?id=LRQhdlrKNE8C https://books.google.ca/books/about/Pair_Programming_Illumin... << Pair Programming illuminated shows all the different kinds of combinations that are possible between programmers of different abilities and experience

erik_seaberg 8y ago

I have to wonder how people make up for never getting into the zone.

jacques_chester 8y ago
I pair. The way I make up for getting into the zone while soloing is to get into the zone as frequently or more frequently in a pair.
taneq 8y ago
It's possible to get in the zone in a pair. It's much more difficult, though.
mitchtbaum 8y ago
I've been pair programming for about 6 weeks now, over Discord. The calling and screen sharing functionalities work so well that my partners and I can join and part quickly and easily. We can get deeply into what we're doing individually. But collaboratively, we can solve problems that neither of us can do alone. I like this virtual setup for multi-user interaction a lot, and hope more tools, even ones specific to virtual programming environments, come for it soon. Tuple's making a remote sharing tool that looks interesting. What comes to mind for me is a shared 3D Wayland environment, like this https://www.youtube.com/watch?v=_FjuPn7MXMs https://www.youtube.com/watch?v=_FjuPn7MXMs so, hopefully more people will start focusing on https://github.com/way-cooler/way-cooler https://github.com/way-cooler/way-cooler and other Rust desktop/handheld application level development.
wvenable 8y ago
My best work is when I go off on wild tangents that might not work out (and some don't). I also tend to build wild and then refactor to cleanup later. I'd hate to put someone else through that all the time and I doubt they'd even let me.

city41 8y ago

For contrast, here is an article I wrote that is largely against pair programming: http://www.mattgreer.org/articles/pair-programming-is-not-a-panacea/ http://www.mattgreer.org/articles/pair-programming-is-not-a-...

rhacker 8y ago
While I'm pro-pair programming I totally understand these issues. The way I normally go about it is put it out there that I like pair programming. And if other people in the team feels the same way, usually that just clicks. I definitely think PP shouldn't be mandated at all. I think too that some of the issues you bring up are very important - especially about the notion that the soft spoken person will usually have their ideas rejected. A lot of developers act in very peculiar ways often because software development shops can be very toxic. Instead of addressing that toxicity, most places end up with a few head honchos. It really is bad for companies actually and can lead to many great budding engineers to leave or get out of the profession, sadly.

keithnz 8y ago

I started with XP way back in 99 after following the discussions on OTUG and then the white book came out. I PP for 8 -> 9 years. Theres a bunch of things I learnt from that It is really good for improving everyones skills. There is a fast convergence in good way to do things The code quality is generally really good and people often develop good habits, everything gets discussed. It doesn't work so well when people are across different projects, much better if they are all on the same project. Teams reach a point where it doesn't actually matter if you pair or not, you tend to carry on making good code. It can slow down experienced devs and they often don't get the same kind of "flow / mental zone" of coding they can get by themselves. Developers need alone time to do their own coding experiments and to follow their own noses It 100% has to be done right and people need to be open to the idea, I went into other companies who were trying to do it and it was failing massively. There was animosity and a lack of openness to trying it. People really didn't understand why they should do it, and felt coerced and threatened by it all. Untangling those messes seemed ... unproductive :) It's exhausting. These days I don't see the need for full time pairing, I see it more as a tool that has certain outcomes, and you use that tool when you notice certain kinds of problems / weaknesses. I would think that teams should "pair" at some point, and by that I mean watch each other code and have interactive discussion about code as it gets developed.

zaptheimpaler 8y ago

Pair programming: when u need 2 devs to do 1 devs job

dang 8y ago
Please don't post shallow dismissals to HN. This is in the site guidelines: https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html. Fortunately you needn't look far for good examples of how to do substantive critique; there are some excellent ones in this thread.

rhacker 8y ago

We got rid of the bad breath, smelly ass, coffee spill issues associated with pair programming. It's all remote now using VSCode Live Share and something like BlueJeans or Slack calls to facilitate the communication.

hw 8y ago

How well pairing works also depends on a person's personality. Introverts don't really do well in pairing situations, and especially when paired with someone totally opposite, the pairing essentially becomes a single person coding and the other person just observing and nodding their heads.

spikej 8y ago
Along the same lines, this doesn't work if one person is used to working rapidly and the other person takes their time to think things through. I found it only really worked best when I worked with another who worked at a similar pace to mine and we took time to bounce ideas off of each other. We both learned a LOT from each other since we both had strengths in opposing areas
watwut 8y ago
Plus beyond introversion, controlling and dominant people make everyone suffer during pairing. Also, shy people non-assertive people loose any possibility of autonomy or independent decision making (they might or might not find it uncomfortable). People who see everything in absolutes are hard to pair with and find it stressful. Extroverts who still like to think about problems silently or explore issues cant do that in pairing either. The human social issues related to pairing are many more areas then just introversion extroversion.