[gboss]

Whenever I encounter a pull request that I find many issues with, I ask to meet with the engineer and review it one on one. More than half of the workplace problems engineers have is due to their introverted nature and their refusal to get on a teams/zoom call to explain their issues and get resolution. Comments are a really poor mechanism for teaching programming best practices.

[BurningFrog]

At my last job, the rule was if the PR is big enough, get on a call and go over it in person. ideally with more than one "reviewer", to break stalemates. Worked really well!

I used to be that introverted guy, but a few years of pair programming completely cured that, and I'm now very comfortable discussing design in detail and at length, in a (if I may say so myself) friendly and constructive way.

If you've never discussed design with other people, it's a genuinely difficult thing to do!

[skydhash]

A PR big enough should probably have its changes implemented and reviewed unit by unit on a feature branch before its creation. Or it should be an already approved work (refactoring, reformatting,...)

[t-writescode]

And if it's refactoring / reformatting, then it should be pair-programmed to validate that exactly what was said to have been done was done and the pair programmer should confirm such in the PR.

[mckn1ght]

I would love this approach, but the people reviewing my PRs are 10 tzs ahead of me, so we basically can’t meet synchronously unless someone is willing to meet early in the morning or late in the evening.

Maybe prerecorded code walkthroughs would help here, but nothing replaces instant face to face pairing. That’s where you can provide somewhat nitpicky feedback but with the empathy that comes with our instinctual responses to body language and voice tone… which over time builds a much better culture IMO.