In my experience, these types of people never really learned software engineering beyond "don't repeat yourself." They learned to code and they're smart enough to come up with clever solutions to complex problems. They don't understand the value of maintainability because they enjoy figuring out complex code.
The software industry often values this–myopically, since their opaque code and misunderstanding of DRY are sure to cause bugs. Some junior engineer five years later will misunderstand how coupled some 300-line function is with unrelated components and introduce a bug while implementing a feature. It happens all the time.
I've seen managers who encourage this and I've seen managers who see the big picture and value simplicity and maintainability. Beyond being in the right environment, it's hard to mitigate the problem. These programmers don't think they need to learn anything from you and are unlikely to ask, and unsolicited advice is not likely to be well received. I've sometimes found that leading by example can help, if they notice that the code you contribute is more pleasant to work with. Perhaps pushing for more pair programming on your team so that members can learn from each other.
Ultimately these people are more interested in solving puzzles than producing software that will stand several years from now. If you can present that challenge as a puzzle they may start to find satisfaction in it, but if not then this will weigh on more than just you and is bad for your product and company.
The software industry often values this–myopically, since their opaque code and misunderstanding of DRY are sure to cause bugs. Some junior engineer five years later will misunderstand how coupled some 300-line function is with unrelated components and introduce a bug while implementing a feature. It happens all the time.
I've seen managers who encourage this and I've seen managers who see the big picture and value simplicity and maintainability. Beyond being in the right environment, it's hard to mitigate the problem. These programmers don't think they need to learn anything from you and are unlikely to ask, and unsolicited advice is not likely to be well received. I've sometimes found that leading by example can help, if they notice that the code you contribute is more pleasant to work with. Perhaps pushing for more pair programming on your team so that members can learn from each other.
Ultimately these people are more interested in solving puzzles than producing software that will stand several years from now. If you can present that challenge as a puzzle they may start to find satisfaction in it, but if not then this will weigh on more than just you and is bad for your product and company.