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.
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.
I've done pair programming (at an Extreme Programming shop).
There are lots of benefits to the practice in terms of knowledge transfer, catching bugs (and otherwise benefiting from having "two sets of eyes") and so on.
But ... it definitely lowers how much code you produce. Maybe two people work a little faster than one (maybe it only cuts velocity to 55% or 60%) ... but it definitely cuts output by a lot.
Pair programming is not about getting more done, it's about getting less done (but done better).
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.
Comments
...
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.
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.
True!
That’s not how pair programming works.
I've done pair programming (at an Extreme Programming shop).
There are lots of benefits to the practice in terms of knowledge transfer, catching bugs (and otherwise benefiting from having "two sets of eyes") and so on.
But ... it definitely lowers how much code you produce. Maybe two people work a little faster than one (maybe it only cuts velocity to 55% or 60%) ... but it definitely cuts output by a lot.
Pair programming is not about getting more done, it's about getting less done (but done better).
You must not be familiar with Thoughtworks. Even before AI they were happy to bill you 5x more consultant hours than necessary.
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.
If you ever read anything about patterns you'll understand Martin Fowler & Co are about anything but producing decent code.