Generally agreed with this, and I had a similar experience.
I think overall it comes down to trying to help them build empathy by showing them that they aren't the only one that will have to interact with what they build, as they are a part of a team.
An easy way to start is, like the parent suggests, with showing "How does making it easier to read or reason about ultimately benefit you?" (e.g., not having to be asked for help by junior engineers). The downside of this is it's kind of abstract, and ultimately a selfish motivator ("what benefits me?" over "what benefits the team?"), as another commenter mentioned.
One option that might be more tangible and team-oriented is to discuss design options as a team. Hopefully in doing so they can understand the complexity in their approach as other people ask questions. If you're able to structure in such a way, one trick here is to separate the design phase from the actual implementation phase. So, whoever designs the approach isn't the one that implements it (within reason -- you could also pair program here, with the whoever designed it as a reviewer and not the primary).
Some of this is also about them realizing what is obvious to them is not obvious to others. One tell here is if they use "why don't you just..." a lot when asked questions.
One phrase I use a lot on my team is "don't be a hero". Heroics in a team setting (willingness to write overly complex features, take on indefinite maintenance of code they wrote so others don't have to reason with it, etc.) are generally detrimental to the team overall. If they find themselves having the need to "carry the team" a lot, you could direct some of their energy/problem solving towards how they could help up-level the team overall or fix team processes.
Anyway, a bit of a ramble, but that's my 2 cents. YMMV.
I think overall it comes down to trying to help them build empathy by showing them that they aren't the only one that will have to interact with what they build, as they are a part of a team.
An easy way to start is, like the parent suggests, with showing "How does making it easier to read or reason about ultimately benefit you?" (e.g., not having to be asked for help by junior engineers). The downside of this is it's kind of abstract, and ultimately a selfish motivator ("what benefits me?" over "what benefits the team?"), as another commenter mentioned.
One option that might be more tangible and team-oriented is to discuss design options as a team. Hopefully in doing so they can understand the complexity in their approach as other people ask questions. If you're able to structure in such a way, one trick here is to separate the design phase from the actual implementation phase. So, whoever designs the approach isn't the one that implements it (within reason -- you could also pair program here, with the whoever designed it as a reviewer and not the primary).
Some of this is also about them realizing what is obvious to them is not obvious to others. One tell here is if they use "why don't you just..." a lot when asked questions.
One phrase I use a lot on my team is "don't be a hero". Heroics in a team setting (willingness to write overly complex features, take on indefinite maintenance of code they wrote so others don't have to reason with it, etc.) are generally detrimental to the team overall. If they find themselves having the need to "carry the team" a lot, you could direct some of their energy/problem solving towards how they could help up-level the team overall or fix team processes.
Anyway, a bit of a ramble, but that's my 2 cents. YMMV.