5 ms·

> Pairing is probably better than two solo devs if both pairers can handle it. Man, am I the only one that absolutely detests pair programming? Not only do I f

> Pairing is probably better than two solo devs if both pairers can handle it. Man, am I the only one that absolutely detests pair programming? Not only do I find it socially awkward, it completely kills my productivity. Software development is often about building a very complex model in your head and then figuring out the changes that need to be made. Having to dedicate half of my mental bandwidth to handling social interaction is just devastating to that process.

seanhunter 5y ago
You're not the only one. I absolutely detest it (to the extent I would absolutely leave a job if they made it a requirement) and a significant portion of devs I have worked with are lukewarm at best.
notreallyserio 5y ago
I just want to be able to fart at my desk in peace. I haven't tried pair programming. It sounds miserable. I figure I'd end up paired with one of those people that can't stand to see you looking for something. You know the type: you're looking through cabinets for something and they demand you tell them what and they demand you go directly to the right place. Sure, I'm looking for something, but I'm also learning where other things are.
- t0mbstone 5y ago
  The trick to pair programming is for each dev to have their own workstation with two screens. Then, you simply use a screen sharing tool to share and collaborate on a code editor on each of your primary screens. We used to use Screenhero for this before they got bought out by Slack, but another tool that works well is something like Tuple.app or Drovio. The beauty of this approach is that each person can "check out" temporarily and do research and look up stuff or check messages on their secondary monitor (without the other person seeing it), but they can easily move their mouse back over to their primary monitor and re-join in on the pair programming. It makes pair programming a lot more tolerable, and gives you the ability to collaborate, while still having some flexibility and autonomy. This also works well in both local and remote pairing sessions.
downWidOutaFite 5y ago
The ideal is when you're both able to load that complex model into your heads and have conversations about it. If you are unable to do that then you are a worse team programmer than those that can.
Verdex 5y ago
The problem as I see it is that if you have someone working by themselves, then you only have to worry if that person is a good fit for that problem. If you have two people working with each other, then you have to worry if each person is a fit for the problem ... and if they're a fit for each other. Or you have to worry if they are each partially a fit for that problem such that the two of them count as being fit for the problem (and they still have to be a fit for each other). And you also have to keep an eye on overall productivity. You're billing at 2x the rate, so you had better be seeing some noticeable benefit to justify it. I've had good experiences and bad experiences pairing. I suspect that people who like it a lot already have a bunch of experience solo developing and are generally able to get along with a large number of people. Also, they're probably solving easy problems with an overabundance of budget.
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
michael1999 5y ago
No. Lots of programmers hate it. Very common reason for new hires quitting at an XP shop I worked at. I expect that's why the author qualified the statement with "if both pairers can handle it". Note that your comment also identifies a key value of pairing (if you can stomach it). When the model your are building is undocumented/implicit and can only be constructed in your mind by careful solitary thought, then you have a weak system design. But a pairing session can only succeed if you make the model explicit. So pairing has to start with constructing a shared model of the work (hard). It turns out, once you can share a model between two people verbally, turning that knowledge into documentation and/or refactoring is relatively easy. To the the individual programmer, this can seem like extra (wasteful!) effort. Unfortunately, it also means they are likely to make another inscrutable addition to the pile of Jenga that is clear them in the moment, but will be opaque to all next Monday. Mind you, if your management is running a ticket mill and doesn't value design or documentation, that is the right thing to do.
amw-zero 5y ago
I’m totally not trying to convince you, because I don’t strongly believe in pairing or anything. But, one benefit that I do see with pairing is that code is always shared amongst a team. You’re seeing the social interaction as only a cost, but there is also a benefit: pairing ensures that the code produced matches more than just one person’s brain. It basically frontloads the communication / knowledge sharing of the structure and reasoning behind the code, and avoids using patterns that only one person enjoys or understands. Which surely is an important part of working on a team.
gnulinux 5y ago
Anecdotal: I find pair programming great for my productivity, and I'm generally a shy/reserved person. Making things explicit by talking them out loud makes programming way safer imho. I almost never solo program if it's a life-and-death code and I have a trusted partner who enjoys pair programming.

seanhunter 5y ago

You're not the only one. I absolutely detest it (to the extent I would absolutely leave a job if they made it a requirement) and a significant portion of devs I have worked with are lukewarm at best.

notreallyserio 5y ago

I just want to be able to fart at my desk in peace. I haven't tried pair programming. It sounds miserable. I figure I'd end up paired with one of those people that can't stand to see you looking for something. You know the type: you're looking through cabinets for something and they demand you tell them what and they demand you go directly to the right place. Sure, I'm looking for something, but I'm also learning where other things are.

t0mbstone 5y ago
The trick to pair programming is for each dev to have their own workstation with two screens. Then, you simply use a screen sharing tool to share and collaborate on a code editor on each of your primary screens. We used to use Screenhero for this before they got bought out by Slack, but another tool that works well is something like Tuple.app or Drovio. The beauty of this approach is that each person can "check out" temporarily and do research and look up stuff or check messages on their secondary monitor (without the other person seeing it), but they can easily move their mouse back over to their primary monitor and re-join in on the pair programming. It makes pair programming a lot more tolerable, and gives you the ability to collaborate, while still having some flexibility and autonomy. This also works well in both local and remote pairing sessions.

downWidOutaFite 5y ago

The ideal is when you're both able to load that complex model into your heads and have conversations about it. If you are unable to do that then you are a worse team programmer than those that can.

Verdex 5y ago

The problem as I see it is that if you have someone working by themselves, then you only have to worry if that person is a good fit for that problem. If you have two people working with each other, then you have to worry if each person is a fit for the problem ... and if they're a fit for each other. Or you have to worry if they are each partially a fit for that problem such that the two of them count as being fit for the problem (and they still have to be a fit for each other). And you also have to keep an eye on overall productivity. You're billing at 2x the rate, so you had better be seeing some noticeable benefit to justify it. I've had good experiences and bad experiences pairing. I suspect that people who like it a lot already have a bunch of experience solo developing and are generally able to get along with a large number of people. Also, they're probably solving easy problems with an overabundance of budget.

deleted 5y ago

[deleted]

deleted 5y ago

[deleted]

michael1999 5y ago

No. Lots of programmers hate it. Very common reason for new hires quitting at an XP shop I worked at. I expect that's why the author qualified the statement with "if both pairers can handle it". Note that your comment also identifies a key value of pairing (if you can stomach it). When the model your are building is undocumented/implicit and can only be constructed in your mind by careful solitary thought, then you have a weak system design. But a pairing session can only succeed if you make the model explicit. So pairing has to start with constructing a shared model of the work (hard). It turns out, once you can share a model between two people verbally, turning that knowledge into documentation and/or refactoring is relatively easy. To the the individual programmer, this can seem like extra (wasteful!) effort. Unfortunately, it also means they are likely to make another inscrutable addition to the pile of Jenga that is clear them in the moment, but will be opaque to all next Monday. Mind you, if your management is running a ticket mill and doesn't value design or documentation, that is the right thing to do.

amw-zero 5y ago

I’m totally not trying to convince you, because I don’t strongly believe in pairing or anything. But, one benefit that I do see with pairing is that code is always shared amongst a team. You’re seeing the social interaction as only a cost, but there is also a benefit: pairing ensures that the code produced matches more than just one person’s brain. It basically frontloads the communication / knowledge sharing of the structure and reasoning behind the code, and avoids using patterns that only one person enjoys or understands. Which surely is an important part of working on a team.

gnulinux 5y ago

Anecdotal: I find pair programming great for my productivity, and I'm generally a shy/reserved person. Making things explicit by talking them out loud makes programming way safer imho. I almost never solo program if it's a life-and-death code and I have a trusted partner who enjoys pair programming.