Simple systems made more complex is an indicator of developer experience, but not in the way you might think.
The Japanese have a system called Shuhari describing three stages of learning; Shu 'obey' for beginner where you follow recipes, Ha 'detach, break' where you mix recipes to mind new approaches, and Ri 'leave, separate' where you forge new paths.
I view developer growth through the lens of Shuhari as:
* Shu - Dev is using known steps from online articles, StackOverflow, etc. to accomplish tasks of limited complexity. Dev is not designing complex systems.
* Ha - Dev has learned much. They are able to design complex systems integrating multiple technologies, but those systems are overly complex. That comes from the subsystems not integrating seamlessly, APIs that could be better, and a tendency for over-engineering at this stage.
* Ri - Dev has learned not just the technologies and how to design complex systems. They have also learned how to design simple systems that work together to handle even more complexity than could be handled by what they designed in Ha stage, without being over-engineered and while still being much easier to understand by less experienced devs.
Based on what you describe, the extremely smart engineers are in the early stages of Ha; some of their practices are still in Shu (e.g., lack of code consistency).
Someone should have a frank conversation with them. Ask them 'At the end of the day, how do we provide value as devs?'. Make it clear you are not asking them to justify themselves, but lead them to the realization that we provide product from timely shipped working and usable product. Your value delivered increases as you increase how timely you ship, how well your code works, and how usable your product is.
But, to quote Admiral Akbar, 'It's a trap'. Because the conversation shouldn't end there. Then ask them, 'Which one is better to increase?'. They will likely jump on how well your code works. Lead them to the understanding that the importance of each is a balance.
* Well working code that is easily usable is useless if it ships a year after your competitors, unless your competitor's code works so badly and is so hard to use that it makes up the difference (in practice, it usually doesn't - people prefer with a 60-80% solution to their pain points now, than a 90% solution in a year).
* Timely shipped code that works well, but is unusable by anyone outside the dev team is useless to your customers (you did hallway tests right?).
* Timely shipped code that is very usable when it works, which is not most of the time, will frustrate your users, tarnish your brand, and provide a massive opportunity to your competitors.
The Japanese have a system called Shuhari describing three stages of learning; Shu 'obey' for beginner where you follow recipes, Ha 'detach, break' where you mix recipes to mind new approaches, and Ri 'leave, separate' where you forge new paths.
I view developer growth through the lens of Shuhari as:
* Shu - Dev is using known steps from online articles, StackOverflow, etc. to accomplish tasks of limited complexity. Dev is not designing complex systems.
* Ha - Dev has learned much. They are able to design complex systems integrating multiple technologies, but those systems are overly complex. That comes from the subsystems not integrating seamlessly, APIs that could be better, and a tendency for over-engineering at this stage.
* Ri - Dev has learned not just the technologies and how to design complex systems. They have also learned how to design simple systems that work together to handle even more complexity than could be handled by what they designed in Ha stage, without being over-engineered and while still being much easier to understand by less experienced devs.
Based on what you describe, the extremely smart engineers are in the early stages of Ha; some of their practices are still in Shu (e.g., lack of code consistency).
Someone should have a frank conversation with them. Ask them 'At the end of the day, how do we provide value as devs?'. Make it clear you are not asking them to justify themselves, but lead them to the realization that we provide product from timely shipped working and usable product. Your value delivered increases as you increase how timely you ship, how well your code works, and how usable your product is.
But, to quote Admiral Akbar, 'It's a trap'. Because the conversation shouldn't end there. Then ask them, 'Which one is better to increase?'. They will likely jump on how well your code works. Lead them to the understanding that the importance of each is a balance.
* Well working code that is easily usable is useless if it ships a year after your competitors, unless your competitor's code works so badly and is so hard to use that it makes up the difference (in practice, it usually doesn't - people prefer with a 60-80% solution to their pain points now, than a 90% solution in a year).
* Timely shipped code that works well, but is unusable by anyone outside the dev team is useless to your customers (you did hallway tests right?).
* Timely shipped code that is very usable when it works, which is not most of the time, will frustrate your users, tarnish your brand, and provide a massive opportunity to your competitors.