In my ideal world all engineers get to do the work they find interesting that also helps meet team demands. In the interest of not fostering resentment or loss

In my ideal world all engineers get to do the work they find interesting that also helps meet team demands. In the interest of not fostering resentment or loss of energy in those contributors I’m wondering what kinds of incentive, goals, metrics, and policies might make you all happy. I would focus on the end impact instead of the implementation. If someone wants to save a few bytes of memory, why? You state it doesn’t seem worth it to you. Is it a value your team actually measures? If not, try starting there. Having conversations about what’s worth optimizing and why will leave everyone feeling heard. I believe most people want to do a good job and want to have an impact. If they see that there’s little gain in minor optimizations then maybe they might stop code golfing. Another (likely) theory is that they just don’t see the complexity in their code. To them it’s not complicated. If that’s the case what heuristic could we use? It’s my experience that tested code is easier to modify, so maybe let them write complicated things, but also make it a requirement to do the leg work to make it more maintainable. Last option that comes to mind: pair with them with the explicit goal of making the code easier to reason about. They’re stuffing the curse of knowledge, you’ve got beginners eyes. Together you might choose to rewrite parts, add tests or lints or docs. Go into the process expecting change from them, but also from yourself. Oh and also if you’re struggling to bring this up without yelling at people I recommend using the non violent communication (NVC) framework it will help you to be heard. Good luck.