I have been an engineer like this. What I see is a developer who is insufficiently challenged or uninterested by the straight-forward solution. The difficulty-l

I have been an engineer like this. What I see is a developer who is insufficiently challenged or uninterested by the straight-forward solution. The difficulty-level and/or amount of work is too low, so they have the capacity to propose and implement a more complex one that's interesting. Phrasing as "too smart" is curious. Do you mean too smart for their own (or product/company's) good or for you to manage? I think it really means that they're not productively directed. Including them in some longer term problems/discussions might give them context on how to weigh things better. I think the idea of "unnecessary complexity" can be avoided two ways: 1. in terms of opportunity cost, if they don't have anything better to work on then it's hard to refute this way, and 2. in terms of maintainability or added risk--they won't see it as a problem but it would be for other team members. I don't know what your development/shipping process is like but one good way to level your team is to adopt pair programming and rotate pairings e.g. weekly/biweekly depending on the nature of the work. This settles the dev culture/conventions better than anything else I've experienced. It also means that knowledge gets shared and generally more confident that you have 2x coverage. I agree with comment about allowing some "probably-unnecessary complexity" as your assessment may not always be correct and even if it were allowing it sometimes adds meaning to the times you don't. It also avoids demoralizing their enthusiasm. Another good idea proposed is about side-projects. But I would say have one for them at the company rather than a personal project. Something that could benefit the product and team to improve a process or validate correctness, completeness, etc. The great thing about this is that it's out-of-band--it runs outside of the shipped product. I've often written complex generators or validators where the results end up in the product but not the complex thing itself. As for the whitespace thing, I advocate for the amount of space to be proportional to how important a piece is to the overall processing. Making each thing as easy to read as possible by adding whitespace detracts from understanding the whole. Any common idioms can be written as densely as possible with no loss of comprehension. I find jr devs putting one argument per line far too often "for readability"--beware consistency for its own sake. Length of a var name should be roughly proportional to how distantly it's used.