> I was, again, technically stronger. A thousand-string pull request was littered with 200 comments, not leaving the person even a faint hope in his competency. Great.

That's way too much feedback. It makes it very hard determine which problems are critical, and which come down to aesthetics or personal preference. On the flip side, if I was churning out buggy code at that rate, I'd want to know about those bugs in detail.

There's also an opportunity cost of evaluating code so tightly. Not only does it take up more of the reviewer's time, it also eats up developer time that could be spent on other features.

> The reason for these angry code reviews is obvious. As part of the team, I bear full responsibility for the project’s code base. I have to work with it later, after all. It’s a source of many issues for the business. The code doesn’t scale, can’t be tested properly, is littered with bugs. Support gets more and more expensive. It can’t be open-sourced or used to lure new developers.

Premature optimization? The mistake here is trying to optimize the legacy of your code base, possibly thinking too far ahead.