Well. One could argue that if you have to discuss these very deep topics in a PR, you better had brought them up before coding that stuff wrong in the first place. Oh, that is not considered agile you say?

Discussing these deep topics is also socially very challenging and you need some quite grown up people to discuss them (that late after the damage has been done) without awkward "but I spent all this time" moments and at least some personal animosity. But the grown ups think and discuss first typically, which also might be why you don't see them discuss those topics in PRs...

It's really nice to have these discussions in person with the person sitting next to you. That's probably what I missed the most during the pandemic--impromptu code/design discussions. Screen sharing works but it's less spontaneous and natural.

> One could argue that if you have to discuss these very deep topics in a PR, you better had brought them up before coding that stuff wrong in the first place.

Fair point, and 100% on the nose. The times when this comes in handy is when you have to PR on a project you don’t know a lot about (which could be argued is a process problem, but I am getting way off trail now).

However, with your excellent point in mind, I am even more confused on what a “culture of rigorous code reviews” is.

It is a culture thing. People who receive reviews that address issues of design, structure, maintainability, and abstraction will learn to do the same for others. This is hard to establish but once it is there it sticks. Early stories about how some Googlers managed to shift the entire company to seeing code review as normal and expected are fascinating.

Google also has documentation, guidance, and training on how to review code effectively.