"Smart," can mean all sorts of things and it heavily depends on whose using the word. It sounds like you have mismatched expectations and poor communication on

"Smart," can mean all sorts of things and it heavily depends on whose using the word. It sounds like you have mismatched expectations and poor communication on the team. > The proposed change typically does indeed make the system objectively better, and they're the one taking responsibility for doing the work and ensuring its correctness Okay, how? If they're writing a proof or a model and using a model checker to validate their model, they are able to communicate their reasoning and teach others how to read the proof or understand the model, and it's sufficient to convince an educated person that it's correct: what's the problem? You only have to understand the reasoning. It sounds to me that you have differing opinions on how things should be done. Take a dozen programmers, give them a specification for a problem, and you will get a dozen different solutions. Let's assume we can verify they all implement the specification faithfully: which one is the one we should use? Which one is better? Endless debate. It's like asking a room full of programmers which programming language should be used for a given problem. What matters is that the code works for the intended use. It's best not to bother too much with the details unless the details matter. If you have two implementations of a specification but you prefer one because it has the right performance characteristics -- those characteristics probably matter and should be in the specification. If the performance characteristics don't matter then either solution is fine... Another way to help solve differences in expectations and start communicating on the same level: make sure everyone knows what your shared values are. Write down your list of values (readability, performance, terseness, etc) and get everyone to do the same. Make sure to clarify what you mean by each word. The set intersection of everyone's values are likely the teams' shared values: what makes the team stronger together than any individual can achieve working alone. Use those values to set preferences for things that are "debatable" like code style or when you have implementations that are equal in terms of meeting the specification and you have a stalemate on which implementation to prefer. > I got into a debate about code style with the smartest person I've ever worked with. It boiled down to me advocating for more whitespace in his code and him arguing that adding whitespace made the code harder to read. This is an immense waste of time. You don't have to be "smart" to have this argument. I've seen lots of programmers of all stripes over the years debate endlessly about syntactic and stylistic things like this. Pick a style, put it in a guideline or auto-formatter, and be done with it. There are more pernicious goblins hiding in your code.