Same here. But it's all in the delivery. I find it's better to assume things are the way they are for good reasons you're not aware of. It's so common for progr

Same here. But it's all in the delivery. I find it's better to assume things are the way they are for good reasons you're not aware of. It's so common for programmers to look at some code they don't fully understand and think "this is stupid it shouldn't have been done like that", start to change it and then discover - lo and behold - the previous coder wasn't an idiot. They just knew stuff you didn't. Plus things morph due to different people, politics, time pressures, etc. So I find it much better to first of all ask "hey, why does this bit do this?" Once you've got the answer, if your suggestion still holds, run it past the team at that point. But yeah, I'd be more likely to promote/recommend someone who I can see understands when things are suboptimal, provided they take the time to understand the "why" first.