> 2. Having Less comments on their PRs: for some drastically dumb reason, having a PR thoroughly reviewed
I'm very far away from liking Amazon's engineering culture and general work culture, but having PRs with countless of discussions and feedback on it does signal that you've done a lot of work without collaborating with others before doing the work. Generally in teams that work well together and build great software, the PRs tend to have very little on them, as most of the issues were resolved while designing together with others.
If the review tooling is any good, getting the code somewhere it can see it is a convenient way for people to give and receive feedback. As the saying goes, the system is what it does!
(And/but yes/no, I have never worked at NAGFAM...)
Eh I feel like there are some features where you just have to get in the weeds to even design it and the code review itself is part of the process of designing/figuring out the edge cases.
> Eh I feel like there are some features where you just have to get in the weeds to even design it and the code review
I agree, but those are separate tasks completely (in my view) compared to "Someone writes code that goes into production", usually called "spikes" or something else to differentiate them from "normal" tasks. They're quite literally just about exploration and figuring out the design, before the "real" work starts.
I'm very far away from liking Amazon's engineering culture and general work culture, but having PRs with countless of discussions and feedback on it does signal that you've done a lot of work without collaborating with others before doing the work. Generally in teams that work well together and build great software, the PRs tend to have very little on them, as most of the issues were resolved while designing together with others.