4 ms·

This. Don't even make suggestions in the first SIX MONTHS. Just listen and meet expectations for a bit and then take off like a rocket once you have context.

by winrid 7y ago

mping 7y ago
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.
- nprateem 7y ago
  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.
- 2rsf 7y ago
  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
- jnbiche 7y ago
  > 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.
rowanG077 7y ago
This would be a huge red flag for me. I fully expect suggestions from newly on boarded devs. That is actually one of their most important skill since they aren't encumbered yet by the existing context and can see things in different lights.
- winrid 7y ago
  You can throw around ideas and ask questions etc. Just try not to sound judgemental, in this case sounds like OP was. That was my point (I want to edit my comment but it seems I can't). I also look forward to what ideas new people bring. That's why you want a flow of people in/out of the company.
  - jhatemyjob 7y ago
    I was not being judgemental. As you could imagine, I am pretty upset at the moment...
joshstrange 7y ago
Six months? Kill me. If I can't join a new team and be a productive/contributing member within the first 2 months then I'm going to be looking for the door. I 100% agree you don't want to go in guns blazing and most importantly PHRASING. Don't go in and tell people they are doing something wrong, make suggestions and ask questions like: "Hey I saw you are using X here, is there a reason you are using X instead of Y?" The response will be one of the following: 1. Oh, I didn't know about Y or I didn't know Y could do that 2. Yes we looked into Y but picked X because of A, B, C 3. X is just better, Y is stupid <- This is the mark of an insecure dev and you need to think long and hard about if you want to stay at the company Also be able to READ THE ROOM, if you respond the #2 with "Ahh but Y can do A, B, C as well..." and you aren't getting any traction then cut your losses.
- winrid 7y ago
  You can be productive. Just have to be careful not to be a judgemental jerk is all.

This. Don't even make suggestions in the first SIX MONTHS. Just listen and meet expectations for a bit and then take off like a rocket once you have context.

by winrid 7y ago

This. Don't even make suggestions in the first SIX MONTHS. Just listen and meet expectations for a bit and then take off like a rocket once you have context.

mping 7y ago

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.

nprateem 7y ago
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.
2rsf 7y ago
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
jnbiche 7y ago
> 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.

rowanG077 7y ago

This would be a huge red flag for me. I fully expect suggestions from newly on boarded devs. That is actually one of their most important skill since they aren't encumbered yet by the existing context and can see things in different lights.

winrid 7y ago
You can throw around ideas and ask questions etc. Just try not to sound judgemental, in this case sounds like OP was. That was my point (I want to edit my comment but it seems I can't). I also look forward to what ideas new people bring. That's why you want a flow of people in/out of the company.
- jhatemyjob 7y ago
  I was not being judgemental. As you could imagine, I am pretty upset at the moment...

joshstrange 7y ago

Six months? Kill me. If I can't join a new team and be a productive/contributing member within the first 2 months then I'm going to be looking for the door. I 100% agree you don't want to go in guns blazing and most importantly PHRASING. Don't go in and tell people they are doing something wrong, make suggestions and ask questions like: "Hey I saw you are using X here, is there a reason you are using X instead of Y?" The response will be one of the following: 1. Oh, I didn't know about Y or I didn't know Y could do that 2. Yes we looked into Y but picked X because of A, B, C 3. X is just better, Y is stupid <- This is the mark of an insecure dev and you need to think long and hard about if you want to stay at the company Also be able to READ THE ROOM, if you respond the #2 with "Ahh but Y can do A, B, C as well..." and you aren't getting any traction then cut your losses.

winrid 7y ago
You can be productive. Just have to be careful not to be a judgemental jerk is all.