> upwards of 75% of the time I see better ways to do something. It's often small things, like making what's being build more configurable / hard coding less, abstracting differently so code is more reusable, naming things better, organising the code in a more logical way, etc. Other times I simply don't agree with the change because it adds complexity with little benefit.

Are there general rules about this that your colleagues can learn from (and are learning from), so that their PRs will improve over time?

And are these general rules documented somewhere in a coding standards document, so that less experienced developers can refer to it?

Or are the "better ways" you see of doing something different from case to case?

If you cannot write down general rules that can be put in an agreed-upon coding standards document, then it's possible you are not as good a developer as you think you are, and that you may not be good to work with either.

> You know those requests, "could we make this button green with larger text in this one specific place"? My answer to these requests are typically, no, because unless it's extremely important it's just adding complexity and making thins harder to maintain down the road.

Is your codebase so brittle that you can change the format of a button without "adding complexity and making things harder to maintain"? Or are you being a control freak about minor stuff?

I used to work for a company that had a few developers who were full of themselves, and nitpicked at every PR, often being given contradictory changes between PRs and even told that "I know it when I see it" when confronted about this. They were so obsessed with making code that was clean and easy to maintain, but the codebase was an insecure and inconsistent mess, and they painted themselves into corners that made bug fixes or refactoring difficult. It was a toxic place to work, with a significant turnover of developers.