Um, I'd say I have both your voice and the voice of the sheep shaving engineers in my head at the same time, all the time. You have to realize, those sorts need

Um, I'd say I have both your voice and the voice of the sheep shaving engineers in my head at the same time, all the time. You have to realize, those sorts need to justify their salary. And they can't do it if everything you write is just fine. They may be incredibly smart. Most of the time they're not adding complexity because they are looking at the bigger picture; they're really just trying to remain relevant. That's not to say that their suggestions might not improve the code, it really just depends whether they have a coherent plan or if success is going to be defined as shaving some cycles while making the whole more brittle, as you say. Likely the best people to determine the time allocation for small optimizations would be people who understand the context; but then again, ALL INPUT is food for writing better code, as long as you're not obligated to follow every idea they toss out off the arm. Sometimes you are too focused on accomplishing a task, and you miss easy things you could do. Also, keep in mind that what may seem brittle from your perspective may work if their goal is to develop a more domain specific, specialized system, and they don't care so much about interoperability.