> what other industry or domain does this? none that i know of.
Aviation, some surgeries.
You know, low-stakes stuff.
Aviation, some surgeries.
You know, low-stakes stuff.
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.
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.
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.
plus this: pair programming has only been studied / proven to work in a teaching environment, where one student is literally teaching the other and bringing them up to speed.
i don't know of any study that proves that it works in a professional setting with experienced people having more or less the same background, working on the same task
if there is any study, i would like to read it.
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.
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.
The easiest time to catch mistakes is early.
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?".
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.
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.
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.
> 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.