You need not a benevolent dictator for each language but a design/code guru for each system, who communicates clearly and builds standards into process. Bad st

You need not a benevolent dictator for each language but a design/code guru for each system, who communicates clearly and builds standards into process. Bad style is just confusion: noise, but not necessarily error. The real problem is history and architecture. E.g., Swift has new concurrency, and the old grand central dispatch, and thread-local's, and you can reach for atomics and even C-style locks, and each of these can be used in different ways. But your application will die unknowable deaths if you don't pick exactly one and stick with it. The same is true for data modeling and liveness. And given the (testing) cost of migrating legacy code, the best thing is often to keep doing things the same way. So to my mind, the most valuable people are not language mavens or even the design theorist who can make a greenfield work of algorithmic art, but the person who can migrate a system, knowing both the old and new ways and the incremental steps that can be taken while the system is running. Recent examples are moving from Google moving to Go, or Apple moving from x86 to Apple silicon, or C/Objective-C to Swift, and even Java iterating much faster these last few years. In many cases it's as much a people problem: getting stakeholders to be patient, oldsters to be flexible, and everyone to be happy with limited improvements.