[dmuth]

I can offer what much younger me was once told by a senior engineer:

1) With respect to not having whitespace: "Not everyone is as smart as you, and you need to ask yourself, do you want junior engineers working on your code to keep bothering you asking how things work, or would you rather your code by easy to read (and commented) so that they can pick things up on their own?"

2) With respect to complexity: "We are expected to build products that align with business objectives. New and experimental code belongs in your home lab and on your GitHub, not in a production environment."

Depending on how things go with #2, maybe offer to let the engineers spend 20% of their time working on lab projects to improve their product, with the understanding being that the rest of the time they are expected to build products with a minimum of complexity.

[ethanwillis]

I can agree with the spirit of #1 but also I think it has a subtle bad implication. You do want your juniors to talk to you and you should want to talk to them. You should also want to push them out of their comfort zone (slightly at least) so they can grow.

For #2, I don't think it's fair to say complexity is always equivalent to "experimental." We're getting close to conflating code that takes skill to write with code that has no benefits or will be buggy/experimental. The OP doesn't really deny that his engineers can write this code without failing at it or that it wouldn't improve the product in a measurable way. The post in regards to complexity is really more about the spirit of your first point in which he thinks some subset of his team can't easily deal with this type of code.

I would say that "complex" code that provides a measurable benefit and that some of your team can "wrangle" isn't necessarily a bad thing. If you want your product to be differentiated and better versus your competitor's product you're going to have to do this. If we all program (100% of the time) solely to lowest common denominator on a team(and I don't mean this disparagingly) then the company's product can only be as good as its "worst" engineer.

Otherwise, we can all get off of this site and build the same todo app from the same step by step tutorial :)

[goatkey]

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.