Hacker News Reader

Comment by marceloabsousa | Hacker News Reader

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...

View on HN

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 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.

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.

Sure it is

Reply on news.ycombinator.com