>If we want to explore alternative solutions, I’d rather do that before implementing one of them.

>If we want knowledge transfer, pair. Sitting next to someone, physically or virtually, while they reason through a problem teaches you far more than reading their completed solution afterwards.

>If we want junior engineers to learn how experienced engineers think, let them work with experienced engineers while they’re thinking. Pairing comes to mind again here, but teams could also do design sessions collectively with a whiteboard before they write (or instruct the agent to write) anything.

>If we want collective ownership, organise teams so people actually build and operate software collectively rather than relying on a pull request to tell everyone what somebody else has already built. For this again use pairing, mob programming, or team design sessions around whiteboard.

...

So in short, talk to people about decisions before you code (obvious advice, but plenty of shops don't do it) ... and replace all other functions of code review with pair programming!?!?

I mean, seriously, the answer to "what do we do with so much code to review" in this article is moronic! The vast vast majority of shops are not going to adopt Extreme Programming, and cut their velocity in half, by using twice as many programmers as they needed yesterday to get the same amount of work done!

The author frames the whole thing as an argument between her and some other guy, but I don't even know what the other guy's argument is (she left it out). Still, her argument so incredibly tone-deaf and awful, I'm definitely on his side.

If you ever read anything about patterns you'll understand Martin Fowler & Co are about anything but producing decent code.

I didn't read this as "pair program every line".

I write a bunch of features. Most are pretty boring. A junior isn't going to learn much by pairing. But occasionally, I do big architecture changes. Those ones are perfect for early collaborative design, pairing, and discussion. The whole team benefits from understanding the architecture better and juniors get to see how seniors think about it. Then you can pair with juniors on the prompting or, more likely, the implementation plan to hand to the agents. That's maybe once a week.

> The vast vast majority of shops are not going to adopt Extreme Programming

True!

> and cut their velocity in half

That’s not how pair programming works.

my performance goes up when i pair program. therefore velocity is not cut in half. depending on the pair, the velocity may even be higher than the combination if the two people working individually.

also if pair programming means saving time on code reviews then that's a further increase in velocity.