If you are on my team and make a possibly stupid suggestion, I would kindly point out that due to the development trajectory the suggestion isn't feasible (an example). If a junior dev (any dev!) is afraid of speaking, he/she will be missing an opportunity to either learn or improve. Of course, the tone of the suggestion (you should do this vs I think we may try this) and context can make or break the interaction. I don't buy into the respect by antiquity thing. Antiquity in a company only brings context and experience, not necessarily intelligence.
Asking and querying even hard question is one thing, but having " a lot of suggestions for improving the codebase" is a totally different level.
Even if you are convinced that your suggestions are the best and absolute truth, at a minimum be attentive and humble.
On one occasion a senior engineer came to my team and on the second week brought some major suggestions that were immediately accepted by the front end team, but that's the exception and not the norm
It doesn't matter if you are a newbie or more experienced, give some respect to the rest of the team
> If you are on my team and make a possibly stupid suggestion, I would kindly point out that due to the development trajectory the suggestion isn't feasible (an example)
I welcome input from even very junior people on my team. But important advice: if your idea is (respectfully) rejected by your team lead, then let it go. Don't try to passive aggressively (or openly) push for your idea after that time.
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.
