131–136 of 136 posts
Earlier quoted context omitted.
Do they? I am on a team of two, and yet, I rarely have time to audit code that my fellow has written, simply because the rest of the day demands other tasks to be focused upon
If you don't have time to review, would you have time to pair? I think time constraints are a deeper problem
I used to be diametrically opposed to pair programming back when I was a junior developer. These days I often find myself parachuting into troubled code bases and trying to fix technical debt while under time pressure to launch a new feature. I often see things that, I can only imagine, were written by some junior dev trying to impress their boss by just hacking something together and throwing it over the wall. More…
That's what code reviews are for. You don't need pair programing for that. Places like google go even beyond by having a 'readibility' pass score for the code to be able to ship. Pair programing is something from the early 2000s, where code review tools were non-existent (I remember, people would just email diffs to each other), back in the day.
That said, it's not an intrinsic problem with code review, but a team culture problem.
Earlier quoted context omitted.
"IMO this is a very wrong way to look at pairing. It's not about one person being incapable of delivering a solution on their own, it's that having multiple perspectives on the code will lead to a higher quality and more well designed product." That's what PRs are for. One can't use the same argument to oppose PRs, as you suggest, because of this key difference: in a PR, the person doing the review has (or ought to h…
As the design evolves, this stuff should really be communicated to the rest of the team before the PR. The purpose of PRs should be almost entirely about finding bugs and typos.
Anyway, the sibling article says:
"A pair of programmers tends to produce better code than someone working alone."
Let's assume this is true (I'm reasonably sure it's false). If one programmer can type code that's at quality N, then add a second one to look at what they're typing and perhaps you can say that quality will be >N since the second person might spot errors made by the first. But we just used TWICE as many people to write that "better" code. I expect there are industries where this burning of resources makes sense, but most of the time it won't regardless of the improved code quality achieved. We could write 2x the amount of crappy code and most organizations would opt to do that.
If we're pairing up at the terminal to teach/train/transfer knowledge, that makes much sense and has been done since the ASR-33. Also sometimes it helps to have two or more people stare at a debugging session together to crack a gnarly problem. Designing at the whiteboard has been a thing since Von Neumann and Turing (chalk board...)
Programming however, isn't a thing you do in pairs, imho. It's creepy and weird.
Earlier quoted context omitted.
As the design evolves, this stuff should really be communicated to the rest of the team before the PR. The purpose of PRs should be almost entirely about finding bugs and typos.
What are "draft PRs" for then?