4 ms·

Fundamentally different to software development on both counts. Aviation and surgery are basically real-time activities. If you make a mistake in either, the c

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.
  - jacques_chester 7y ago
    My experience is that it does catch mistakes early. And it's not mutually exclusive of other ways of spotting errors, it's reinforcing.
    - nikofeyn 7y ago
      with pair programming, you have two people supposedly in the same head space, if it's working as sold, writing code. the benefit of tests and code reviews is that they come from a different head space than what the code was written in.
- cgrealy 7y ago
  > Software mistakes can be pretty dire Absolutely, but again, they don't happen as you're coding, unlike aviation or surgery. > if you want to ensure quality, in practice, you will want different eyes to look at the code Totally agree, but that's an argument for code review, not pair programming. PP is a way to do code review, but I'd argue it's not a very good way, since you're asking the authors to review the code. > The easiest time to catch mistakes is early. TDD and CI are a more effective way of doing this.
  - jacques_chester 7y ago
    > Absolutely, but again, they don't happen as you're coding, unlike aviation or surgery. When do they occur? > PP is a way to do code review, but I'd argue it's not a very good way, since you're asking the authors to review the code. I'd argue that it is a good way, based on my experience of both methods. Code reviews are better than winging it, but given the choice between a PR-and-review process and pair programming with trunk development, I'd take the latter every time. I agree with the virtues of TDD and CI, I see pair programming as a useful way to help with TDD.
    - cgrealy 7y ago
      > When do they occur? When the code is run, not when it’s written. > I'd argue that it is a good way, based on my experience of both methods. And with similar experience, I’d disagree. Paired programmers are focused on writing the code not reviewing. The whole point of code reviews is to let someone divorced from the problem solving process objectively the code.

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.
- jacques_chester 7y ago
  My experience is that it does catch mistakes early. And it's not mutually exclusive of other ways of spotting errors, it's reinforcing.
  - nikofeyn 7y ago
    with pair programming, you have two people supposedly in the same head space, if it's working as sold, writing code. the benefit of tests and code reviews is that they come from a different head space than what the code was written in.
cgrealy 7y ago
> Software mistakes can be pretty dire Absolutely, but again, they don't happen as you're coding, unlike aviation or surgery. > if you want to ensure quality, in practice, you will want different eyes to look at the code Totally agree, but that's an argument for code review, not pair programming. PP is a way to do code review, but I'd argue it's not a very good way, since you're asking the authors to review the code. > The easiest time to catch mistakes is early. TDD and CI are a more effective way of doing this.
- jacques_chester 7y ago
  > Absolutely, but again, they don't happen as you're coding, unlike aviation or surgery. When do they occur? > PP is a way to do code review, but I'd argue it's not a very good way, since you're asking the authors to review the code. I'd argue that it is a good way, based on my experience of both methods. Code reviews are better than winging it, but given the choice between a PR-and-review process and pair programming with trunk development, I'd take the latter every time. I agree with the virtues of TDD and CI, I see pair programming as a useful way to help with TDD.
  - cgrealy 7y ago
    > When do they occur? When the code is run, not when it’s written. > I'd argue that it is a good way, based on my experience of both methods. And with similar experience, I’d disagree. Paired programmers are focused on writing the code not reviewing. The whole point of code reviews is to let someone divorced from the problem solving process objectively the code.