Comment by lmm
9 months ago
> which contains brilliance like requiring pair programming for every line of code written
Because it works. Have you tried it?
9 months ago
> which contains brilliance like requiring pair programming for every line of code written
Because it works. Have you tried it?
Force it on people, you'll see how much it works. Getting another pair of eyes on the code that you wrote is useful, but it's not free (effort, tolerance) and it's not for everyone. Just do proper code reviews. Middle ground.
Pair programming should never be forced, but when applied... Jeez, it's powerful!
IME code reviews are a bullshit half-measure that ends up as the worst of all worlds. It's tragic that so many companies settle on them as a compromise position.
> Getting another pair of eyes on the code that you wrote is useful, but it's not free (effort, tolerance) and it's not for everyone.
Yeah, but to be fair I would argue that in the limit, real code reviews end up looking a lot like pair programming, and you can avoid a bunch of back and forth by both people being present during development.
Obviously you still need code review (for regulatory reasons in a lot of cases), but the amount of times I've ended up on a Zoom talking through mine and others PRs makes me believe that pair programming would help here.
> and you can avoid a bunch of back and forth by both people being present during development.
I don't like pair programming for personal and cultural reasons (eg: I am uncomfortable with the _process_, but not the results), but the people in the pro-pair-programming camp will say the quoted bit above is one of its strengths. You back/forth and fix or change things early in the process.
Doing a code review is "too late", since these early decisions that could have been made differently/better effect all the code that follows it into a further less-optimal space.