5 ms·

the thought of pair programming nearly gives me an anxiety attack. the second it’s mentioned in the interview process, it’s an automatic no from me. what other

the thought of pair programming nearly gives me an anxiety attack. the second it’s mentioned in the interview process, it’s an automatic no from me. what other industry or domain does this? none that i know of. first of all, working in pairs creates a problem when there’s disagreement. you need a group of three to five to find agreement in those cases. working in pairs also requires a very tight alignment of style in programming, thinking, speed, brainstorming, etc. it simply does not allow for moments of thoughtful rumination or experimentation. it’s just like having pairs in school. it never works unless the two people are copies of each other or both people have spent time doing and thinking about the task themselves independently beforehand. i think working in pairs or small groups for design, review (or a post-review discussion), and especially debugging works quite well. it also works well when there’s a new person being ramped up or someone in the pair who is particularly knowledgeable about a portion of the interfacing code or sticky points. but two people sitting at a computer implementing? that only works for a very, very short amount of time, if at all. i refuse to work for any place that forces this upon workers. it creates just another selection bias in interviews. engineers already look for people just like them, and this just adds to that bias. and the articles for the benefits does nothing to say what pair programming does to actually enable the benefits listed. all of the benefits can be accomplished by shared design plus individual design, shared review, shared debugging, and individual implementation.

jacques_chester 7y ago
> what other industry or domain does this? none that i know of. Aviation, some surgeries. You know, low-stakes stuff.
- cgrealy 7y ago
  Fundamentally different to software development on both counts. Aviation and surgery are basically real-time activities. If you make a mistake in either, the consequences are dire. Also, in aviation, it's about redundancy... if there's an issue, it's not like you can wait while someone else steps in. Software is not like that. Your code almost never goes straight into prod (unless you have really aggressive CI/CD!). There is always time to correct your mistakes.
  - jacques_chester 7y ago
    Software mistakes can be pretty dire and if you want to ensure quality, in practice, you will want different eyes to look at the code. Which also lends redundancy, if someone wishes to move on. The easiest time to catch mistakes is early.
    - Mike12398 7y ago
      Coding is NOT a real-time procedural performance activity, and thus can not be compared to aviation or surgery. Code reviews, collaboration on architectural decisions, and QA catch mistakes as early as necessary.
      - jacques_chester 7y ago
        All these professions require a mix of procedural and declarative skill. Pilots and surgeons aren't professional athletes, they rely on enormous amounts of declarative knowledge. The easiest time to catch a mistake is when it's made, which is as true of surgery or flight as of software development. That's why I rely on type systems, tests and whenever I can, someone next to me asking "why?".
        Mike12398 7y ago
        Read again: Coding is NOT a real time performance activity, thus can not be compared with aviation and surgery in that way. Pairing is a requirement to do aviation and surgery reliably and accurately, but is completely optional for coding well, and arguably reduces quality of code in many cases.
    - nikofeyn 7y ago
      > The easiest time to catch mistakes is early. pair programming and the articles proposing it do nothing to help catch mistakes early. i would argue that they even delay catching mistakes due to what i'd call deconstructive interference during the implementation process. there are plenty of much more systematic ways to catch mistakes earlier than just slapping pair programming onto the software process.
- nikofeyn 7y ago
  those aren't analogous, like at all. or actually, they are analogous, just not in the sense you mean, as they don't serve as examples of "pair <whatever work>". for both pilots and surgeons, no one is doing the same job at the same time. pilots and surgeons, when performing on the same flight or surgery, have different roles, and it's actually extremely important that they stick to and abide by those roles. you know, because it's high-stakes stuff. however, before and after the flights or surgeries (akin to design or planning in software), or perhaps during sticky situations or emergencies (akin to debugging in software), or during post-flight or surgery reviews (akin to code reviews) they do work together on the same thing. during the sticky situation, emergency, or debugging stage, that thing is the emergency at hand. once it's dealt with, the separate, individual roles are assumed. so thanks for your examples, as they just serve to further my point.
  - jacques_chester 7y ago
    > for both pilots and surgeons, no one is doing the same job at the same time. Do you think pair programmers are literally bashing the keyboard simultaneously? Your point, as I read it, wasn't that "only programmers do pair programming". That's as trite as "only surgeons do pair surgery" or "only aviators do pair aviation", because it includes the profession. It's that only programmers doing any kind of assigning two minds to cooperatively navigate one problem space, which is demonstrably false.
    - nikofeyn 7y ago
      > Do you think pair programmers are literally bashing the keyboard simultaneously? that's how the article and other articles define it: two people sitting at the same machine writing code. what is your definition? my point was indeed: what other industry practices "pair <work or implementation>" on the same task? and why would it be the second? we're literally talking about pair programming here, not just cooperative work.
      - rabidrat 7y ago
        One person is sitting at the machine, the other is sitting beside them. Like how one person is flying the plane, the other is sitting beside them. Pilot/navigator is a common role division. In pair programming, the person at the keyboard is doing the minutiae of the immediate task at hand (the pilot), while the other person is thinking through the next steps or how it fits into the whole (the navigator). They are not actually typing at the same time.
- ken 7y ago
  And yet in software, the people in high-stakes domains who really care about quality (like the Lockheed shuttle group) don't use pair programming. Has any team using pair programming ever had a defect rate as low as 1 bug per half million lines of code? Or even within an order of magnitude of that? For real quality, you need detailed specifications before code is written, an independent verification team, and root cause analysis on every bug. Otherwise, you're still down at CMM level 1 or 2 ("chaos, and slightly better than chaos"). Pair programming is putting a second pair of eyes on chaos to try to emulate an actual process. It's the Hyper-Threading of development processes. We're too cheap to implement what we all know we really need, so here's something that's better than nothing, for a small fraction of the cost, because it repurposes what we have on hand.

jacques_chester 7y ago

> what other industry or domain does this? none that i know of. Aviation, some surgeries. You know, low-stakes stuff.

cgrealy 7y ago
Fundamentally different to software development on both counts. Aviation and surgery are basically real-time activities. If you make a mistake in either, the consequences are dire. Also, in aviation, it's about redundancy... if there's an issue, it's not like you can wait while someone else steps in. Software is not like that. Your code almost never goes straight into prod (unless you have really aggressive CI/CD!). There is always time to correct your mistakes.
- jacques_chester 7y ago
  Software mistakes can be pretty dire and if you want to ensure quality, in practice, you will want different eyes to look at the code. Which also lends redundancy, if someone wishes to move on. The easiest time to catch mistakes is early.
  - Mike12398 7y ago
    Coding is NOT a real-time procedural performance activity, and thus can not be compared to aviation or surgery. Code reviews, collaboration on architectural decisions, and QA catch mistakes as early as necessary.
    - jacques_chester 7y ago
      All these professions require a mix of procedural and declarative skill. Pilots and surgeons aren't professional athletes, they rely on enormous amounts of declarative knowledge. The easiest time to catch a mistake is when it's made, which is as true of surgery or flight as of software development. That's why I rely on type systems, tests and whenever I can, someone next to me asking "why?".
      - Mike12398 7y ago
        Read again: Coding is NOT a real time performance activity, thus can not be compared with aviation and surgery in that way. Pairing is a requirement to do aviation and surgery reliably and accurately, but is completely optional for coding well, and arguably reduces quality of code in many cases.
  - nikofeyn 7y ago
    > The easiest time to catch mistakes is early. pair programming and the articles proposing it do nothing to help catch mistakes early. i would argue that they even delay catching mistakes due to what i'd call deconstructive interference during the implementation process. there are plenty of much more systematic ways to catch mistakes earlier than just slapping pair programming onto the software process.
nikofeyn 7y ago
those aren't analogous, like at all. or actually, they are analogous, just not in the sense you mean, as they don't serve as examples of "pair <whatever work>". for both pilots and surgeons, no one is doing the same job at the same time. pilots and surgeons, when performing on the same flight or surgery, have different roles, and it's actually extremely important that they stick to and abide by those roles. you know, because it's high-stakes stuff. however, before and after the flights or surgeries (akin to design or planning in software), or perhaps during sticky situations or emergencies (akin to debugging in software), or during post-flight or surgery reviews (akin to code reviews) they do work together on the same thing. during the sticky situation, emergency, or debugging stage, that thing is the emergency at hand. once it's dealt with, the separate, individual roles are assumed. so thanks for your examples, as they just serve to further my point.
- jacques_chester 7y ago
  > for both pilots and surgeons, no one is doing the same job at the same time. Do you think pair programmers are literally bashing the keyboard simultaneously? Your point, as I read it, wasn't that "only programmers do pair programming". That's as trite as "only surgeons do pair surgery" or "only aviators do pair aviation", because it includes the profession. It's that only programmers doing any kind of assigning two minds to cooperatively navigate one problem space, which is demonstrably false.
  - nikofeyn 7y ago
    > Do you think pair programmers are literally bashing the keyboard simultaneously? that's how the article and other articles define it: two people sitting at the same machine writing code. what is your definition? my point was indeed: what other industry practices "pair <work or implementation>" on the same task? and why would it be the second? we're literally talking about pair programming here, not just cooperative work.
    - rabidrat 7y ago
      One person is sitting at the machine, the other is sitting beside them. Like how one person is flying the plane, the other is sitting beside them. Pilot/navigator is a common role division. In pair programming, the person at the keyboard is doing the minutiae of the immediate task at hand (the pilot), while the other person is thinking through the next steps or how it fits into the whole (the navigator). They are not actually typing at the same time.
ken 7y ago
And yet in software, the people in high-stakes domains who really care about quality (like the Lockheed shuttle group) don't use pair programming. Has any team using pair programming ever had a defect rate as low as 1 bug per half million lines of code? Or even within an order of magnitude of that? For real quality, you need detailed specifications before code is written, an independent verification team, and root cause analysis on every bug. Otherwise, you're still down at CMM level 1 or 2 ("chaos, and slightly better than chaos"). Pair programming is putting a second pair of eyes on chaos to try to emulate an actual process. It's the Hyper-Threading of development processes. We're too cheap to implement what we all know we really need, so here's something that's better than nothing, for a small fraction of the cost, because it repurposes what we have on hand.