6 ms·

Since the comments here are mostly people appalled by the idea of pairing - try it before you knock it. Even the author says there's a lot of benefits to it, bu

Since the comments here are mostly people appalled by the idea of pairing - try it before you knock it. Even the author says there's a lot of benefits to it, but it wore down on them over time. I did pairing for a few year at a company early in my career. Some days it felt draining, but I learned a lot, quickly, from working with senior engineers and seeing how they approached problems or building systems. You even socialized different dev tools and terminal commands (I felt really smart when I taught a much more senior engineer about git push -u). I also liked how it helped keep me engaged on days when I was tired and unfocused, and that the day was over at 5pm - you packed up and went home, and were disincentivized from doing more work until the next day. Several years later, I'm pretty comfortable coding solo, but it's a nice tool to pull out when it's helpful (like ramping up on a new codebase).

Cthulhu_ 5y ago
I found it to be very intense, but part of that is having to get out of your comfort zone, change your speed of thinking and typing, and a lot of think and communicate before you act. That said, I don't oppose pairing, but only with a set time limit.
miltondts 5y ago
I also find this to be the case. Specially on ramp-up the difference is night and day. I also felt a motivation boost in certain situations. As with everything, if it makes sense or not, depends on a lot of factors: Who are you pairing with? How long? (hours per day/days per week..) What type of problem are you solving? All these and more, need to be taken into consideration. Just forcing people to pair is probably not a good idea. EDIT: Reading a bit more about pairing in general, there seems to be a lot of emphasis on the "one keyboard per pair". I like to keep two keyboards/computers per pair so that I can quickly jump between solo and pairing, to test ideas, investigate etc
Olreich 5y ago
Pair programming only seems good when there is a large disparity in experience or seniority. The senior engineer is there to teach the junior engineer and is sacrificing a great deal of time and energy to do so. That trade off may be worth it. Pairing people with the same skill set? Mostly that’s just a waste.
- pydry 5y ago
  It's good for a number of things: * Having multiple perspectives on design. * Having an extra pair of eyes to catch things one person might miss. * Being able to bounce ideas off each other. * Redundancy (if you are on holiday or sick somebody else still knows the code deeply) * Onboarding (it works better at getting me up to speed than any docs ever have) * Motivation (i find it's kind of like having a gym buddy). * Bonding (assuming you get along with whomever you're pairing with) I get that not everybody likes it though. I feel that it's somewhat irksome for introverts and companies try to use it as a means of making developers more replaceable, which some people hate.
  - geophile 5y ago
    > Having multiple perspectives on design. Serious question: Why is any design happening while programming? Seems unwise to start programming before you have designed the thing you are programming.
    - Twisol 5y ago
      It depends on what you mean by "design", but sometimes the best way to figure out what your options are is to throw something together and see how it feels. Could be UI, could be API design, could be a form of test-driven design. If the problem isn't well-understood, you probably don't want to put code down -- you're better served going to the customer and scoping a problem to start from. If the solution isn't well-understood, you probably don't want to commit to any code -- but there's no reason you can't use the development process to drive out some candidate solutions.
      - geophile 5y ago
        That seems incredibly wasteful to me. I have no problem with rapid iteration between design and implementation, but at least recognize that those are different activities, and that the latter is a poor way of doing the former.
        5y ago
vsareto 5y ago
>Several years later, I'm pretty comfortable coding solo, but it's a nice tool to pull out when it's helpful (like ramping up on a new codebase). Opt-in for both sides seems like the best option. You should pair program with someone with whom you get along. Joining a place like Pivotal where you have little control over it and have to pair from the outset with someone you don't know a whole lot about just seems like a bad experiment.
lthornberry 5y ago
I also think it's important to acknowledge individual differences. To give one relevant example, pairing sounds particularly challenging for people on the autism spectrum, which as a group is well-represented among software engineers. Several of the things the author sites as problems (need for sensory breaks, difficulty sustaining social engagement) are real issues for most autistic folks. It's not a coincidence that autistic people talk about "burnout" in much the same way that the author does--a total cognitive shutdown. I'm not saying the author is autistic, although they might be, I have no idea. But enough people are that designing a work environment that won't work for them is something we want to be very careful about. And even more people aren't autistic but have some overlapping traits--the author might be in this group. That's also where I'd place myself, as someone who's not on the spectrum but has multiple close relatives who are, and sees more than a bit of myself in them, although not enough to be diagnosable. I think I could handle pair programming up to 30 or 40% of the time, but more than that, and I'm pretty sure I'd burn out fast.
stjohnswarts 5y ago
I did try it, it works when there is a hard problem to be solved, but for day to day coding no effing way. I can see extroverts who need to communicate a lot enjoying it, but I find they're in the minority with programmers especially the more senior they become. There are instances like mentoring or solving a tough problem, but otherwise I think email and slack and such are good enough communication tools, it doesn't need to be forced.

Cthulhu_ 5y ago

I found it to be very intense, but part of that is having to get out of your comfort zone, change your speed of thinking and typing, and a lot of think and communicate before you act. That said, I don't oppose pairing, but only with a set time limit.

miltondts 5y ago

I also find this to be the case. Specially on ramp-up the difference is night and day. I also felt a motivation boost in certain situations. As with everything, if it makes sense or not, depends on a lot of factors: Who are you pairing with? How long? (hours per day/days per week..) What type of problem are you solving? All these and more, need to be taken into consideration. Just forcing people to pair is probably not a good idea. EDIT: Reading a bit more about pairing in general, there seems to be a lot of emphasis on the "one keyboard per pair". I like to keep two keyboards/computers per pair so that I can quickly jump between solo and pairing, to test ideas, investigate etc

Olreich 5y ago

Pair programming only seems good when there is a large disparity in experience or seniority. The senior engineer is there to teach the junior engineer and is sacrificing a great deal of time and energy to do so. That trade off may be worth it. Pairing people with the same skill set? Mostly that’s just a waste.

pydry 5y ago
It's good for a number of things: * Having multiple perspectives on design. * Having an extra pair of eyes to catch things one person might miss. * Being able to bounce ideas off each other. * Redundancy (if you are on holiday or sick somebody else still knows the code deeply) * Onboarding (it works better at getting me up to speed than any docs ever have) * Motivation (i find it's kind of like having a gym buddy). * Bonding (assuming you get along with whomever you're pairing with) I get that not everybody likes it though. I feel that it's somewhat irksome for introverts and companies try to use it as a means of making developers more replaceable, which some people hate.
- geophile 5y ago
  > Having multiple perspectives on design. Serious question: Why is any design happening while programming? Seems unwise to start programming before you have designed the thing you are programming.
  - Twisol 5y ago
    It depends on what you mean by "design", but sometimes the best way to figure out what your options are is to throw something together and see how it feels. Could be UI, could be API design, could be a form of test-driven design. If the problem isn't well-understood, you probably don't want to put code down -- you're better served going to the customer and scoping a problem to start from. If the solution isn't well-understood, you probably don't want to commit to any code -- but there's no reason you can't use the development process to drive out some candidate solutions.
    - geophile 5y ago
      That seems incredibly wasteful to me. I have no problem with rapid iteration between design and implementation, but at least recognize that those are different activities, and that the latter is a poor way of doing the former.
      - 5y ago

vsareto 5y ago

>Several years later, I'm pretty comfortable coding solo, but it's a nice tool to pull out when it's helpful (like ramping up on a new codebase). Opt-in for both sides seems like the best option. You should pair program with someone with whom you get along. Joining a place like Pivotal where you have little control over it and have to pair from the outset with someone you don't know a whole lot about just seems like a bad experiment.

lthornberry 5y ago

I also think it's important to acknowledge individual differences. To give one relevant example, pairing sounds particularly challenging for people on the autism spectrum, which as a group is well-represented among software engineers. Several of the things the author sites as problems (need for sensory breaks, difficulty sustaining social engagement) are real issues for most autistic folks. It's not a coincidence that autistic people talk about "burnout" in much the same way that the author does--a total cognitive shutdown. I'm not saying the author is autistic, although they might be, I have no idea. But enough people are that designing a work environment that won't work for them is something we want to be very careful about. And even more people aren't autistic but have some overlapping traits--the author might be in this group. That's also where I'd place myself, as someone who's not on the spectrum but has multiple close relatives who are, and sees more than a bit of myself in them, although not enough to be diagnosable. I think I could handle pair programming up to 30 or 40% of the time, but more than that, and I'm pretty sure I'd burn out fast.

stjohnswarts 5y ago

I did try it, it works when there is a hard problem to be solved, but for day to day coding no effing way. I can see extroverts who need to communicate a lot enjoying it, but I find they're in the minority with programmers especially the more senior they become. There are instances like mentoring or solving a tough problem, but otherwise I think email and slack and such are good enough communication tools, it doesn't need to be forced.