Hacker News Reader

Comment by uvesten | Hacker News Reader

Pair programming is sooo much better than PR’s. I really loathe reviewing pull requests, no matter if you do it absolutely correct, and don’t miss anything, it’s extremely wasteful of the time of both the coder and the reviewer, even if there are no changes that need to be made. There is the context switch for the reviewer, ditto for the coder, waiting for feedback. Ugh. Just have two people do the work together, and lose the need for constant context switches and wasted time.

View on HN

> Just have two people do the work together, and lose the need for constant context switches and wasted time.

What kind of PR process do you have where reviewing the PR takes as long as writing the code in the first place? Because that's the only way pair programming is as efficient as code reviewing.

I find I work more efficiently when I pair program, and am usually more likely to choose an approach that is good for the future of the product, so I don’t think your statement holds.

I think there is a middle ground.

If I'm doing a PR (e.g. for a new dev), and it's becoming a real bloodbath, I stop doing the PR and do a 1:1 pair programming session w/ the dev. This helps save face and keeps the advice private and inculcation.

Don't let PR's turn into public floggings.

Yeah I’ve always felt that PRs are ineffective. It’s to late a stage in the development process to give feedback.

Code reviews and PRs are different things. Still, PRs can be effective with the right tooling and methodology. We've doing continuous code reviews with PRs and it's been working great to have early feedback. More details at: https://reviewpad.com/blog/continuous-code-reviews-are-the-w...

If we want to argue semantics, sure, but (at least in my experience) a PR is by far the most common way. And from the linked article, they seem to say that pair programming is the ideal, but that continuous code reviews bring most of the same benefits. Sounds good to me. But. I’m still convinced that just doing proper pair programming from the start saves time for the organization, it’s just that the upfront investment seems too great. (I’d argue that spending 2x programmer time is easily the cheapest way to get a feature done, and if you think you are saving costs/being more productive doing solo dev + code review you’re not accurately measuring time spent. (Or that the review is very superficial.))

I personally feel quite comfortable working on something and pinging a peer if I've having an issue figuring out a good way to do something or I want to vet the approach.

then they don't need to spend all afternoon watching me get tea and pick my nose and we still get to have the interesting discussions.

I find that there’s a lot of bias in pair programming. One takes the role of the lead dev and the other of the ‘copilot’ but not actively reviewing the code. It works great if you want to review later asynchronously without needing to ask for more context. Still pair programming doesn’t replace an asynchronous code review afterwards. Ideally every dev should let the code sink a bit and then review it before distributing it. I see both approaches working together - don’t get this trend of advocating for pair programming as the best of getting the highest quality.

Sure it is

PRs are perfect in open source . In companies they’re just an illusion of minimising risk.

Reply on news.ycombinator.com