> Have you ever met somebody who was always against exploring suggested changes to their code in a pull request? Perhaps they got upset if somebody else went in

> Have you ever met somebody who was always against exploring suggested changes to their code in a pull request? Perhaps they got upset if somebody else went in and refactored some code they worked on in the past? There are at least three dynamics going in here that overlap and get conflated frequently. 1. Ego, inability to accept criticism. Obviously this is just something the engineer needs to grow past. 2. Sometimes another engineer not familiar with the codebase will do a drive by commit. They need to make a specific change and find the code around that change to be confusing, so they refactor it to be easier to understand in isolation. However they don't understand the idioms and patterns of the codebase as a whole, and the net effect is that the system as a whole becomes less coherent and maintainable. This creates both-sides-are-right arguments, like, "Yes you did give that variable a clearer name, except we use the other name consistently everywhere else, so if you rename it here you should rename it everywhere, and it's not really worth doing a such a big refactor and invalidating everyone's familiarity, is it?" 3. Familiarity. When you work in the same system for a long time, you develop a mental map of how everything works. That map can be a source of great productivity. Sometimes it's actually not worth making an improvement because it will necessitate the long term maintainers having to relearn how things work, and they have other things to do more important than this improvement.