There are two tools I usually employ in "technical arguments":

* The socratic method. I ask questions. Why did you do it this way? What are the tradeoffs? Get them to explain their reasoning. And not in an accusative way, I'm genuinely interested in how they arrived at the decision. Sometimes I just need more context; sometimes they rethink; sometimes we figure out something new together. It is a voyage of discovery, no egos involved.

* Be tolerant. Sometimes design issues are bikesheddy, and my rule is to err on the side of "let the person doing the work decide". Even if it isn't the way I would do it. I will usually phrase it something along the lines of "this is how I would do it, but if you strongly prefer this other way, it's fine". Pick battles that are important; help engineers develop "good taste"; but try to empower, not disempower, them.

I have some hard lines but they're easy and everyone knows them. Immutable data structures, use the typechecker, constructor injection, don't use null, etc etc. I wrote up a doc that all new employees read and it's distilled into a CLAUDE.md file. AI review usually takes care of these.

The only place I find that I still have to push a little is applying the YAGNI rule. Folks aren't particularly resistant, they often don't realize when they're violating it. Over-engineering is habitual. But people eventually get it.

> Why did you do it this way?

One thing that I find helps is just avoiding the word "why" as well. Restructuring to say "how come" or "I'm wondering..." or "am I understanding right that..." helps avoid putting people on their guard.

It even works on AIs, interestingly enough.