7 ms·

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 sa

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.
      - Twisol 5y ago
        Programming is neither design nor implementation; it's a skill and a tool that isn't owned by a particular process. I am quite happy to sketch in code; I won't work with my hands tied behind my back. Concretely, what "incredible waste" are you projecting here? Neither myself nor the ancestor even laid out a process to criticize.
        geophile 5y ago
        "Design" can mean a lot of different things. UI? Data structures and algorithms? API? Database schema? Whichever of these we're discussing, and whatever process we're talking about, I find it much faster to think and sketch and describe in words before writing code.
        Huggernaut 5y ago
        No one said these things were mutually exclusive. Unless you're telling me that your sketches map exactly into the code you've written every time, then there is design emerging during the coding process.
    - elzbardico 5y ago
      Yes. Code "is" design, unless you're working with machine code. Code is a blueprint, not the building. We sometimes tend to take high level languages for granted and forget that. Sometimes, of course, you need to go up a few notches on the abstraction level and you do some diagram or even a few lines of English prose. But, still, code IS design.
  - marcosdumay 5y ago
    Why not? For nearly any user-facing program, merging the design and requirement gathering¹ with programming brings only good things. 1 - Including user testing. It's worth putting a lot of time into the process design just to have user testing concomitant with programming.
    - geophile 5y ago
      My experience is mostly server-side, and there, I have found that smushing these things together leads to sadness.
      - marcosdumay 5y ago
        Oh, non-user facing programs is the land of well written specs, tests before implementation, design before implementation, and all the old school academic markers of good software engineering. Yeah, you really do not want to program those before deciding their architecture. But the experience is far from universal.
- nthj 5y ago
  > * Redundancy (if you are on holiday or sick somebody else still knows the code deeply) This is the part I’m always puzzled by. I read and understand every line of code my team merges in. If I don’t feel like I fully understand it, I ask questions, in code review. If I’m still not getting it I may ask for a zoom meeting. But that’s maybe once a week. Consequently I can jump in and manage issues or bugs pretty much anywhere in the product, and it’s fairly complex. I think there are two kinds of programmers, those who quickly read and understand code and those who more quickly understand from talking about the code, and these two groups will always talk past each other when discussing pair programming.
dkersten 5y ago
I don't agree. I wrote a top-level comment about my (positive) experience pairing, but I'll state it again here because its relevant to your comment: I was on a team with one other guy working on a complex distributed-systems project. We were both principle engineers at the company. We delivered the project in under a year and as far as I'm aware from talking with former colleagues, the code is still in production without issue years later. We paired every day for about 11 months. Yes, its mentally exhausting. You need to take regular breaks. You also need buy in from everyone involved, if one person is half-assing it, its going to fall apart. The benefits I saw were many: better quality code (two sets of eyes on the code at all times, two people solving every problem or bug, always someone to ping ideas off), better understanding of the code/knowledge sharing (both of us fully understood every line of code written, why it was like that, what it was for), shipping on time (easier to make decisions to get it production ready quickly when two brains are working on it, easier to avoid bugs, boring tasks like documenting are easier too). I don't think the project could have been completed in the time it was with only two people if we hadn't paired. There was also no disparity in experience or seniority, we were both quite equally matched.
- g051051 5y ago
  I just can't fathom that. How could the 4 hours "pairing" negate the fact that one of you can't work for 4 hours? I can see it if those 4 hours were really design/planning time, but otherwise, I just don't see how it could work. Most of what I see people here calling "pair programming" is just normal collaboration. Bringing in someone to put a second set of eyeballs on a problem, or to discuss some design topics, or brainstorm isn't the kind of pair programming in the original article.
  - MockObject 5y ago
    All those benefits he listed there can, and often do, offset what seems like a waste of an extra programmer.
    - g051051 5y ago
      And my point is that I just can't see it. I collaborate with people, and there's benefit in those relatively short interactions, but I've never seen a situation where it made more sense to pair up like that, unless it's a training scenario.
Smaug123 5y ago
It's not about a disparity as such. I've had great pairs who I'd say are about equally "good" as me (if one must project to a 1d scale), but who have complementary skills to mine.
JohnBooty 5y ago
Pairing people with the same skill set? Mostly that’s just a waste. Strong disagree in my experience. Even with two "evenly matched" developers: 1. The idea of "evenly matched" developers is a fallacy. They're never exactly equal in all areas. Each one is going to know technical things the other doesn't. One will be stronger on the back end, one on the front end, etc. One will know parts of the API the other doesn't. One is better at SQL. 2. Each will know tool/workflow tweaks the other doesn't. 3. Most importantly by far: this is how domain knowledge transfer happens. On any non-trivial codebase there are decisions and business logic baked into the code. We of course need to document these as well as possible via other means (comments, commit messages, whatever) but nothing compares to person-to-person knowledge transfer. To be clear, full-time pairing seems rather crazy to me. My ideal (which surely isn't some folks' idea of "ideal") would be approximately several hours per week of on-demand pairing when it makes sense. In other words, a team that doesn't pair as a rule but is eager to pair when it makes sense to do so.
JohnWhigham 5y ago
I think it can be good for 2 seniors when you need something right now i.e. production bug, or feature that came out of nowhere that needs to ship by EOD. Assembling a strike team of sorts.

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.
    - Twisol 5y ago
      Programming is neither design nor implementation; it's a skill and a tool that isn't owned by a particular process. I am quite happy to sketch in code; I won't work with my hands tied behind my back. Concretely, what "incredible waste" are you projecting here? Neither myself nor the ancestor even laid out a process to criticize.
      - geophile 5y ago
        "Design" can mean a lot of different things. UI? Data structures and algorithms? API? Database schema? Whichever of these we're discussing, and whatever process we're talking about, I find it much faster to think and sketch and describe in words before writing code.
        Huggernaut 5y ago
        No one said these things were mutually exclusive. Unless you're telling me that your sketches map exactly into the code you've written every time, then there is design emerging during the coding process.
  - elzbardico 5y ago
    Yes. Code "is" design, unless you're working with machine code. Code is a blueprint, not the building. We sometimes tend to take high level languages for granted and forget that. Sometimes, of course, you need to go up a few notches on the abstraction level and you do some diagram or even a few lines of English prose. But, still, code IS design.
- marcosdumay 5y ago
  Why not? For nearly any user-facing program, merging the design and requirement gathering¹ with programming brings only good things. 1 - Including user testing. It's worth putting a lot of time into the process design just to have user testing concomitant with programming.
  - geophile 5y ago
    My experience is mostly server-side, and there, I have found that smushing these things together leads to sadness.
    - marcosdumay 5y ago
      Oh, non-user facing programs is the land of well written specs, tests before implementation, design before implementation, and all the old school academic markers of good software engineering. Yeah, you really do not want to program those before deciding their architecture. But the experience is far from universal.
nthj 5y ago
> * Redundancy (if you are on holiday or sick somebody else still knows the code deeply) This is the part I’m always puzzled by. I read and understand every line of code my team merges in. If I don’t feel like I fully understand it, I ask questions, in code review. If I’m still not getting it I may ask for a zoom meeting. But that’s maybe once a week. Consequently I can jump in and manage issues or bugs pretty much anywhere in the product, and it’s fairly complex. I think there are two kinds of programmers, those who quickly read and understand code and those who more quickly understand from talking about the code, and these two groups will always talk past each other when discussing pair programming.

dkersten 5y ago

I don't agree. I wrote a top-level comment about my (positive) experience pairing, but I'll state it again here because its relevant to your comment: I was on a team with one other guy working on a complex distributed-systems project. We were both principle engineers at the company. We delivered the project in under a year and as far as I'm aware from talking with former colleagues, the code is still in production without issue years later. We paired every day for about 11 months. Yes, its mentally exhausting. You need to take regular breaks. You also need buy in from everyone involved, if one person is half-assing it, its going to fall apart. The benefits I saw were many: better quality code (two sets of eyes on the code at all times, two people solving every problem or bug, always someone to ping ideas off), better understanding of the code/knowledge sharing (both of us fully understood every line of code written, why it was like that, what it was for), shipping on time (easier to make decisions to get it production ready quickly when two brains are working on it, easier to avoid bugs, boring tasks like documenting are easier too). I don't think the project could have been completed in the time it was with only two people if we hadn't paired. There was also no disparity in experience or seniority, we were both quite equally matched.

g051051 5y ago
I just can't fathom that. How could the 4 hours "pairing" negate the fact that one of you can't work for 4 hours? I can see it if those 4 hours were really design/planning time, but otherwise, I just don't see how it could work. Most of what I see people here calling "pair programming" is just normal collaboration. Bringing in someone to put a second set of eyeballs on a problem, or to discuss some design topics, or brainstorm isn't the kind of pair programming in the original article.
- MockObject 5y ago
  All those benefits he listed there can, and often do, offset what seems like a waste of an extra programmer.
  - g051051 5y ago
    And my point is that I just can't see it. I collaborate with people, and there's benefit in those relatively short interactions, but I've never seen a situation where it made more sense to pair up like that, unless it's a training scenario.

Smaug123 5y ago

It's not about a disparity as such. I've had great pairs who I'd say are about equally "good" as me (if one must project to a 1d scale), but who have complementary skills to mine.

JohnBooty 5y ago

Pairing people with the same skill set? Mostly that’s just a waste. Strong disagree in my experience. Even with two "evenly matched" developers: 1. The idea of "evenly matched" developers is a fallacy. They're never exactly equal in all areas. Each one is going to know technical things the other doesn't. One will be stronger on the back end, one on the front end, etc. One will know parts of the API the other doesn't. One is better at SQL. 2. Each will know tool/workflow tweaks the other doesn't. 3. Most importantly by far: this is how domain knowledge transfer happens. On any non-trivial codebase there are decisions and business logic baked into the code. We of course need to document these as well as possible via other means (comments, commit messages, whatever) but nothing compares to person-to-person knowledge transfer. To be clear, full-time pairing seems rather crazy to me. My ideal (which surely isn't some folks' idea of "ideal") would be approximately several hours per week of on-demand pairing when it makes sense. In other words, a team that doesn't pair as a rule but is eager to pair when it makes sense to do so.

JohnWhigham 5y ago

I think it can be good for 2 seniors when you need something right now i.e. production bug, or feature that came out of nowhere that needs to ship by EOD. Assembling a strike team of sorts.