9 ms·

Pair programming generates visceral responses due to it being introduced as if it were fact, which for me always triggers my spidey senses. People who didn't li

Pair programming generates visceral responses due to it being introduced as if it were fact, which for me always triggers my spidey senses. People who didn't like it were told "you're doing it wrong" or "you didn't give it a proper chance". Dismissing criticisms out of hand only furthers distrust, regardless of the actual value of the idea. I played along and paired for awhile, but now steadfastly refuse to pair, ever. I work best within my own mind, and the distraction of talking to someone breaks my concentration such that I'm unable to keep the big picture in my head anymore. The irritation of being that close to someone and having to engage with them for even half an hour is draining, and I took more frequent and longer breaks because of this (much to the annoyance of my pair-partner, who couldn't work while I was away). There may very well be people who work well in pairs, but rest assured that there are those who aren't built that way. Don't disparage them, don't discriminate against them, and don't play the moral superiority game with them. Accept their diversity and be a better team for it.

harryf 6y ago
Like many things in programming, we adopt it like a cargo cult ( https://en.wikipedia.org/wiki/Cargo_cult_programming https://en.wikipedia.org/wiki/Cargo_cult_programming ) based on "some thought leader said" or "some company has amazing..." without actually doing any serious study. It's actually amazing for an industry that should be all about rational, reasoned analysis, that we're willing to perform such experiments on ourselves with so little evidence to show the value. There is this study here - https://www.researchgate.net/publication/222408325_The_effectiveness_of_pair_programming_A_meta-analysis https://www.researchgate.net/publication/222408325_The_effec... "A more detailed examination of the evidence suggests that pair programming is faster than solo programming when programming task complexity is low and yields code solutions of higher quality when task complexity is high." There are links to a few more here - https://tuple.app/pair-programming-guide/scientific-research-into-pair-programming https://tuple.app/pair-programming-guide/scientific-research... - none of it looks particularly compelling. And I'm not "against" pair programming. It's just sad to see "cargo cult" adoption of practices.
- hughrr 6y ago
  I'm actually here because my colleagues keep coming up with things posted here and on other sources and I was intrigued as to the consensus behind them. I'm pleasantly surprised to read that there is a nice critical balance of discussion. The worry for me is that there is almost always an obvious detachment from the steps carried out to the benefit which is the precise definition of a cargo cult. A lot of people can't seem to see this at all and when asked for some sort of rational proof, something I do regularly, tend to switch to a personal or ideological attack instead. It's slightly tiring to be fighting the front of rationalism in an industry which appears to be driven partially by fashion. As for pair programming, 100% anecdotally I find that sometimes you need a second set of eyes on a problem when you can't see the forest for the trees. But mostly it's inefficient and unproductive and absolutely crippling for small teams.
  - Agentlien 6y ago
    I agree with your criticism against pair programming. I also agree that it's helpful with an extra pair of eyes on anything you write, which is why I'm strongly in favour of code reviews.
    - harryf 6y ago
      ...although some people might argue that you could get the same value from a rubber duck ( https://en.wikipedia.org/wiki/Rubber_duck_debugging https://en.wikipedia.org/wiki/Rubber_duck_debugging )
      - Agentlien 6y ago
        I want very different things from my rubber ducks and my code reviews. Rubber ducking is great for forcing yourself to articulate your train of thought, spelling out your assumptions, and proof-reading your own logic. Code reviews are great for catching errors you glaze over because you're too familiar with what you think you wrote to see what's actually written. It's also a great way to onboard people and enforce code standards and best practices. Even when you're in a more senior position code reviews can often teach you new things, when you interact with systems the reviewer knows better and they happen to know a better approach.
ratww 6y ago
> The irritation of being that close to someone and having to engage with them for even half an hour is draining, and I took more frequent and longer breaks because of this (much to the annoyance of my pair-partner, who couldn't work while I was away). For me the issue wasn't just the difference in frequency or duration of breaks, but also the fact that different people prefer to take breaks at different times. In the end, unless you're very lucky, it ends up being a compromise for both parts and the productivity gains are negated by the constant context switching.
eplanit 6y ago
In my experience, I've seen pairing work in the context of an experienced engineer mentoring a junior, as part of a spectrum of engagement: observing/reading, shadowing, pair programming, to then where the junior acts with more independence with some oversight, and then they're ready. Beyond that, as a general rule it's only attractive to very mediocre engineers (who are honest enough to admit they need help). In interviews for experienced roles, I might ask "what do you think of pair programming", and if they're positive about it there's a good chance I'll pass.
- paulcole 6y ago
  > it's only attractive to very mediocre engineers This is a feature, not a bug! Most people are mediocre at nearly everything. The mediocre person who knows their limitations and embraces systems to get the most out of themselves is more valuable than the mediocre person who sees themselves as a rockstar.
- lghh 6y ago
  > as a general rule it's only attractive to very mediocre engineers "Thing I don't like is only useful to developers who are worse than me" is a super toxic take. If you said something like that when I was interviewing you, regardless of how much pairing the company I'm running the interview for does, I'd pass on you as well.
  - randomdata 6y ago
    ...and then complain that there is a "shortage" of developers.
    - lghh 6y ago
      I think a developer presenting themselves as unqualified for the job, via being an asshole in a job that requires good communication skills and teamwork, you have a pass to say you have not gotten a qualified candidate yet.
ChrisMarshallNY 6y ago
Pairing works great; as long as everyone is on the same "wavelength." That's absolutely vital, and has both good and bad sides. The good, is what the author was talking about. That team cohesiveness, that he disturbingly compared to being in a Borg Collective, is something that can't be easily quantified, but can amplify energy and positive morale. The Marines have known this for a couple of hundred years. Every Marine I've ever talked to, has described, almost verbatim, what he said. About how the squads act as a unit; almost without thinking. The results are tough to argue with. They are a highly effective fighting force. The price can be burnout (as mentioned). When everything we do is being channeled and amplified, we have to be "on" all the time. We don't get that "five minutes of spacing out" between modules. In my case, that's absolutely required. It's also a young person's game (like being a Marine infantryman). As I've gotten older, my personal process has become almost supernatural, but it has also become incredibly draining, and that "down time" is now no longer a luxury, but a necessity. On days that I have had some really challenging work, like chasing a pernicious bug, or setting up scaffolding for a new architecture, I can be absolutely flattened by bedtime. I feel as if I have spent the day digging trenches. Also, I work best in my own head. I can create a pretty sizable architecture in my head, and don't need to write down a thing. That makes for very fast development, and tremendous flexibility. I can tear down an entire architectural construct, if it proves ineffective, and rebuild it, in a few minutes (in my head). The minute I need to communicate it, however, that efficiency goes right into the bog.
- goatcode 6y ago
  The only way I've seen this kind of situation come about is if pairing isn't forced. "Forced" means leadership encouraging at every opportunity, ham-handedly, without considering context. If there isn't an extreme investment by leadership, badly-executed pairing will ensue, form what I've seen.
  - kodah 6y ago
    Pairing is a decision made between two devs, not as a team or company, imo.
goatcode 6y ago
>There may very well be people who work well in pairs, but rest assured that there are those who aren't built that way. Don't disparage them, don't discriminate against them, and don't play the moral superiority game with them. Accept their diversity and be a better team for it. The most progressive view I've seen so far in the "official" dogma of pairing says to accept people who work better outside of pairing, but to exclude them from important projects. I'm at a loss as to how this is a good thing, and to me is a sign of pairing becoming a religion of extreme bigotry. Thank you for saying something that should be common sense! Don't expect everyone to work and think in the exact same way!
commandlinefan 6y ago
> but rest assured that there are those who aren't built that way Yeah, the title suggests an anti-pair-programming rant, but the author seems to have stockholm-syndrome'd himself into accepting it. I tried pair programming once, a long time ago, when it first "came out". We immediately ran into all sorts of practical issues like, how do you check your e-mail? (Back then, you had to read e-mail in a dedicated e-mail client like Outlook). What if there's documentation that needs to be read? Take turns reading a page? I can't even conjure up a world where pair programming is effective in my imagination.
- bluk 6y ago
  I've pair programmed using a shared server for a couple years. Both of us ssh'ed into a server and used a shared tmux session and primarily used vim to edit code. Having a chat program on the side to share links or other info we wanted to keep allowed us to browse things like documentation at our own pace. An audio/video session if working remotely. If terminal based pair programming doesn't work, Visual Studio Code has an interesting "Live Share" feature which works similarly. You keep some of your extensions (and don't even need all of the same extensions installed to make things work depending on who shares).
  - sleepybrett 6y ago
    They've recently added shared buffers to the jetbrains stack as well (or at least goland): https://www.jetbrains.com/code-with-me/ https://www.jetbrains.com/code-with-me/ I have yet to try it out though.
    - Noumenon72 6y ago
      I tried it and it was pretty cool. You can each look through the code on the source machine independently, and summon each other to the place you're looking at. The changes I made were put into a separate changeset where the host could roll them back.
- t0mbstone 6y ago
  The best pair programming experiences I've had involve each programmer using their own laptops, each with a separate screen attached. The pairing sessions were shared via ScreenHero (now I use Tuple), where each person has independent control of their own mouse cursor, but can grab control by clicking anywhere and typing. Because the pairing session is constrained to the external monitors and the laptop screen isn't shared, each dev can still check their private email or look up things off to the side, but can also keep an eye on the pairing session and jump back in whenever they are needed. This methodology works well in a side-by-side pairing environment, and it also works great for remote pairing.
jhedwards 6y ago
How do you teach other people? In our team we sometimes have people working on systems that they are unfamiliar with, either because they are new to the team or new to the feature/system, and we've found that it saves a huge amount of time to have someone who is familiar with the system pair with them to get up to speed. Sure, once the person is comfortable (and the "expert" is comfortable that they aren't going to do anything that they'll have to undo later) we typically go off and work on our own, but I just don't see how you can train others efficiently without pairing.
- kstenerud 6y ago
  I bring up the existing documentation, and have them run through it mostly on their own with me sitting there, asking me whenever they have questions. I watch over their shoulder and nudge them if I see something going awry. They jot down notes that they'll use to update the documentation later. Once they're up and running, they ping me whenever they get stuck, and then jot down notes for the documentation later. The important part is that they read the docs (as a sanity check that the docs still make sense to a newcomer) and perform the actions themselves. I don't touch the keyboard except when it's a complicated, exceptional issue that they're not expected to deal with at this level. The other important part is that they update the documentation.
ballenf 6y ago
I think it's also fair to apply that tolerance to the team level: letting teams exist that require pairing. And teams that never pair. And everything in between. That is, the parent point, should not be used as an argument against there existing teams with team-level pairing standards or expectations. If we get to the point where it is hard to find a non-pairing team, then maybe we revisit this. But given the diversity of people on this topic, that seems extremely unlikely. The justification on teams that require pairing should be a non-judgmental "that's just how we do it here. For now." And people who have strong preferences should be able to ask about it interviews.
eloisant 6y ago
I've had great pair programming sessions in the past. But it was always occasional, and short. Sometimes longer or more often if it's someone I really like to work with, but there have been only a handful in about 20 years of career. I think that the biggest mistake about pair programming is about forcing it, especially when do it all day. I could never do that!
brightball 6y ago
I’ve always encourage pair programming solely as a team cross training exercise and only for short stints. Aka - Bob built a system using tooling that is new to our team and unknown to anyone else. Bob needs to pair with Fred for a couple of hours so more than just Bob will have hands on experience with the tech. That’s my only requirement because in my experience it’s better than documentation and it’s a requirement to make sure Bob can take vacations. Everybody will be able to figure it out eventually, but if something is urgent we don’t have until eventually.
- kstenerud 6y ago
  I like to use bringing someone up to speed as a vehicle for improving the documentation. Docs go stale and decay, and require regular maintenance. But without a fresh eye, you become blind to many of the problems the documentation has. Having a new person go through the docs, feel their pain, and fix the problems (with your help) is a golden opportunity to keep the docs fresh and usable, and more importantly codifies knowledge that can otherwise be lost when people leave.
athorax 6y ago
I usually come off as a bumbling idiot when I try and pair program. It completely breaks the way my brain works trying to explain something while also trying to reason about a piece of software as a whole
superduperycomb 6y ago
I have ADHD and pairing is liberating. I don’t need medicine, I can stay focused and motivated for years. I’m seriously worried that I’ll have to get back on medicine because the pairing opportunities in the industry are becoming so far and few between. If anyone has recommendations I’m all ears (and eyes)!
- nerder92 6y ago
  That's very interesting, i never thought about pairing as a tool that help people with ADHD stay focused. At ThoughtWorks we do promote pairing, please let me know if there is anything I can do to help you out!
  - superduperycomb 5y ago
    It’s funny you mention ThoughtWorks, I’m happily (enough) employed right now. But I’ve thought about applying for years. I appreciate the offer :)

harryf 6y ago

Like many things in programming, we adopt it like a cargo cult ( https://en.wikipedia.org/wiki/Cargo_cult_programming https://en.wikipedia.org/wiki/Cargo_cult_programming ) based on "some thought leader said" or "some company has amazing..." without actually doing any serious study. It's actually amazing for an industry that should be all about rational, reasoned analysis, that we're willing to perform such experiments on ourselves with so little evidence to show the value. There is this study here - https://www.researchgate.net/publication/222408325_The_effectiveness_of_pair_programming_A_meta-analysis https://www.researchgate.net/publication/222408325_The_effec... "A more detailed examination of the evidence suggests that pair programming is faster than solo programming when programming task complexity is low and yields code solutions of higher quality when task complexity is high." There are links to a few more here - https://tuple.app/pair-programming-guide/scientific-research-into-pair-programming https://tuple.app/pair-programming-guide/scientific-research... - none of it looks particularly compelling. And I'm not "against" pair programming. It's just sad to see "cargo cult" adoption of practices.

hughrr 6y ago
I'm actually here because my colleagues keep coming up with things posted here and on other sources and I was intrigued as to the consensus behind them. I'm pleasantly surprised to read that there is a nice critical balance of discussion. The worry for me is that there is almost always an obvious detachment from the steps carried out to the benefit which is the precise definition of a cargo cult. A lot of people can't seem to see this at all and when asked for some sort of rational proof, something I do regularly, tend to switch to a personal or ideological attack instead. It's slightly tiring to be fighting the front of rationalism in an industry which appears to be driven partially by fashion. As for pair programming, 100% anecdotally I find that sometimes you need a second set of eyes on a problem when you can't see the forest for the trees. But mostly it's inefficient and unproductive and absolutely crippling for small teams.
- Agentlien 6y ago
  I agree with your criticism against pair programming. I also agree that it's helpful with an extra pair of eyes on anything you write, which is why I'm strongly in favour of code reviews.
  - harryf 6y ago
    ...although some people might argue that you could get the same value from a rubber duck ( https://en.wikipedia.org/wiki/Rubber_duck_debugging https://en.wikipedia.org/wiki/Rubber_duck_debugging )
    - Agentlien 6y ago
      I want very different things from my rubber ducks and my code reviews. Rubber ducking is great for forcing yourself to articulate your train of thought, spelling out your assumptions, and proof-reading your own logic. Code reviews are great for catching errors you glaze over because you're too familiar with what you think you wrote to see what's actually written. It's also a great way to onboard people and enforce code standards and best practices. Even when you're in a more senior position code reviews can often teach you new things, when you interact with systems the reviewer knows better and they happen to know a better approach.

ratww 6y ago

> The irritation of being that close to someone and having to engage with them for even half an hour is draining, and I took more frequent and longer breaks because of this (much to the annoyance of my pair-partner, who couldn't work while I was away). For me the issue wasn't just the difference in frequency or duration of breaks, but also the fact that different people prefer to take breaks at different times. In the end, unless you're very lucky, it ends up being a compromise for both parts and the productivity gains are negated by the constant context switching.

eplanit 6y ago

In my experience, I've seen pairing work in the context of an experienced engineer mentoring a junior, as part of a spectrum of engagement: observing/reading, shadowing, pair programming, to then where the junior acts with more independence with some oversight, and then they're ready. Beyond that, as a general rule it's only attractive to very mediocre engineers (who are honest enough to admit they need help). In interviews for experienced roles, I might ask "what do you think of pair programming", and if they're positive about it there's a good chance I'll pass.

paulcole 6y ago
> it's only attractive to very mediocre engineers This is a feature, not a bug! Most people are mediocre at nearly everything. The mediocre person who knows their limitations and embraces systems to get the most out of themselves is more valuable than the mediocre person who sees themselves as a rockstar.
lghh 6y ago
> as a general rule it's only attractive to very mediocre engineers "Thing I don't like is only useful to developers who are worse than me" is a super toxic take. If you said something like that when I was interviewing you, regardless of how much pairing the company I'm running the interview for does, I'd pass on you as well.
- randomdata 6y ago
  ...and then complain that there is a "shortage" of developers.
  - lghh 6y ago
    I think a developer presenting themselves as unqualified for the job, via being an asshole in a job that requires good communication skills and teamwork, you have a pass to say you have not gotten a qualified candidate yet.

ChrisMarshallNY 6y ago

Pairing works great; as long as everyone is on the same "wavelength." That's absolutely vital, and has both good and bad sides. The good, is what the author was talking about. That team cohesiveness, that he disturbingly compared to being in a Borg Collective, is something that can't be easily quantified, but can amplify energy and positive morale. The Marines have known this for a couple of hundred years. Every Marine I've ever talked to, has described, almost verbatim, what he said. About how the squads act as a unit; almost without thinking. The results are tough to argue with. They are a highly effective fighting force. The price can be burnout (as mentioned). When everything we do is being channeled and amplified, we have to be "on" all the time. We don't get that "five minutes of spacing out" between modules. In my case, that's absolutely required. It's also a young person's game (like being a Marine infantryman). As I've gotten older, my personal process has become almost supernatural, but it has also become incredibly draining, and that "down time" is now no longer a luxury, but a necessity. On days that I have had some really challenging work, like chasing a pernicious bug, or setting up scaffolding for a new architecture, I can be absolutely flattened by bedtime. I feel as if I have spent the day digging trenches. Also, I work best in my own head. I can create a pretty sizable architecture in my head, and don't need to write down a thing. That makes for very fast development, and tremendous flexibility. I can tear down an entire architectural construct, if it proves ineffective, and rebuild it, in a few minutes (in my head). The minute I need to communicate it, however, that efficiency goes right into the bog.

goatcode 6y ago
The only way I've seen this kind of situation come about is if pairing isn't forced. "Forced" means leadership encouraging at every opportunity, ham-handedly, without considering context. If there isn't an extreme investment by leadership, badly-executed pairing will ensue, form what I've seen.
- kodah 6y ago
  Pairing is a decision made between two devs, not as a team or company, imo.

goatcode 6y ago

>There may very well be people who work well in pairs, but rest assured that there are those who aren't built that way. Don't disparage them, don't discriminate against them, and don't play the moral superiority game with them. Accept their diversity and be a better team for it. The most progressive view I've seen so far in the "official" dogma of pairing says to accept people who work better outside of pairing, but to exclude them from important projects. I'm at a loss as to how this is a good thing, and to me is a sign of pairing becoming a religion of extreme bigotry. Thank you for saying something that should be common sense! Don't expect everyone to work and think in the exact same way!

commandlinefan 6y ago

> but rest assured that there are those who aren't built that way Yeah, the title suggests an anti-pair-programming rant, but the author seems to have stockholm-syndrome'd himself into accepting it. I tried pair programming once, a long time ago, when it first "came out". We immediately ran into all sorts of practical issues like, how do you check your e-mail? (Back then, you had to read e-mail in a dedicated e-mail client like Outlook). What if there's documentation that needs to be read? Take turns reading a page? I can't even conjure up a world where pair programming is effective in my imagination.

bluk 6y ago
I've pair programmed using a shared server for a couple years. Both of us ssh'ed into a server and used a shared tmux session and primarily used vim to edit code. Having a chat program on the side to share links or other info we wanted to keep allowed us to browse things like documentation at our own pace. An audio/video session if working remotely. If terminal based pair programming doesn't work, Visual Studio Code has an interesting "Live Share" feature which works similarly. You keep some of your extensions (and don't even need all of the same extensions installed to make things work depending on who shares).
- sleepybrett 6y ago
  They've recently added shared buffers to the jetbrains stack as well (or at least goland): https://www.jetbrains.com/code-with-me/ https://www.jetbrains.com/code-with-me/ I have yet to try it out though.
  - Noumenon72 6y ago
    I tried it and it was pretty cool. You can each look through the code on the source machine independently, and summon each other to the place you're looking at. The changes I made were put into a separate changeset where the host could roll them back.
t0mbstone 6y ago
The best pair programming experiences I've had involve each programmer using their own laptops, each with a separate screen attached. The pairing sessions were shared via ScreenHero (now I use Tuple), where each person has independent control of their own mouse cursor, but can grab control by clicking anywhere and typing. Because the pairing session is constrained to the external monitors and the laptop screen isn't shared, each dev can still check their private email or look up things off to the side, but can also keep an eye on the pairing session and jump back in whenever they are needed. This methodology works well in a side-by-side pairing environment, and it also works great for remote pairing.

jhedwards 6y ago

How do you teach other people? In our team we sometimes have people working on systems that they are unfamiliar with, either because they are new to the team or new to the feature/system, and we've found that it saves a huge amount of time to have someone who is familiar with the system pair with them to get up to speed. Sure, once the person is comfortable (and the "expert" is comfortable that they aren't going to do anything that they'll have to undo later) we typically go off and work on our own, but I just don't see how you can train others efficiently without pairing.

kstenerud 6y ago
I bring up the existing documentation, and have them run through it mostly on their own with me sitting there, asking me whenever they have questions. I watch over their shoulder and nudge them if I see something going awry. They jot down notes that they'll use to update the documentation later. Once they're up and running, they ping me whenever they get stuck, and then jot down notes for the documentation later. The important part is that they read the docs (as a sanity check that the docs still make sense to a newcomer) and perform the actions themselves. I don't touch the keyboard except when it's a complicated, exceptional issue that they're not expected to deal with at this level. The other important part is that they update the documentation.

ballenf 6y ago

I think it's also fair to apply that tolerance to the team level: letting teams exist that require pairing. And teams that never pair. And everything in between. That is, the parent point, should not be used as an argument against there existing teams with team-level pairing standards or expectations. If we get to the point where it is hard to find a non-pairing team, then maybe we revisit this. But given the diversity of people on this topic, that seems extremely unlikely. The justification on teams that require pairing should be a non-judgmental "that's just how we do it here. For now." And people who have strong preferences should be able to ask about it interviews.

eloisant 6y ago

I've had great pair programming sessions in the past. But it was always occasional, and short. Sometimes longer or more often if it's someone I really like to work with, but there have been only a handful in about 20 years of career. I think that the biggest mistake about pair programming is about forcing it, especially when do it all day. I could never do that!

brightball 6y ago

I’ve always encourage pair programming solely as a team cross training exercise and only for short stints. Aka - Bob built a system using tooling that is new to our team and unknown to anyone else. Bob needs to pair with Fred for a couple of hours so more than just Bob will have hands on experience with the tech. That’s my only requirement because in my experience it’s better than documentation and it’s a requirement to make sure Bob can take vacations. Everybody will be able to figure it out eventually, but if something is urgent we don’t have until eventually.

kstenerud 6y ago
I like to use bringing someone up to speed as a vehicle for improving the documentation. Docs go stale and decay, and require regular maintenance. But without a fresh eye, you become blind to many of the problems the documentation has. Having a new person go through the docs, feel their pain, and fix the problems (with your help) is a golden opportunity to keep the docs fresh and usable, and more importantly codifies knowledge that can otherwise be lost when people leave.

athorax 6y ago

I usually come off as a bumbling idiot when I try and pair program. It completely breaks the way my brain works trying to explain something while also trying to reason about a piece of software as a whole

superduperycomb 6y ago

I have ADHD and pairing is liberating. I don’t need medicine, I can stay focused and motivated for years. I’m seriously worried that I’ll have to get back on medicine because the pairing opportunities in the industry are becoming so far and few between. If anyone has recommendations I’m all ears (and eyes)!

nerder92 6y ago
That's very interesting, i never thought about pairing as a tool that help people with ADHD stay focused. At ThoughtWorks we do promote pairing, please let me know if there is anything I can do to help you out!
- superduperycomb 5y ago
  It’s funny you mention ThoughtWorks, I’m happily (enough) employed right now. But I’ve thought about applying for years. I appreciate the offer :)