> In fact, I’d argue that the code author, by virtue of their time and effort, deserves the chance to see their proposals in action. They’ve earned the opportun

> In fact, I’d argue that the code author, by virtue of their time and effort, deserves the chance to see their proposals in action. They’ve earned the opportunity to prove their detractors wrong. That sounds so whiny. Code review doesn't comment on the coder. It comments on the code. Other people who aren't the whiny coder know how well it matches the expectations of surrounding code, how the design will age, what a newcomer to the code next year will need to know to maintain it. They will point out missing test cases. No one is forcing the code author to even write code, that is their choice. I had a teammate that would take problems away and work on them for a couple of weeks. Come back with a hairball, with obvious design issues like interfaces depending on concrete classes and byzantine relationships. Very tough to usefully feed back on. Go away for longer. After several months of that kind of progress, rather than review more I just rewrote the entire subsystem in 2 weeks. A dev spending time on a system is measuring their time, not their effectiveness.