4 ms·

I work at a small Japanese company with only two developers; myself and a junior developer (also American) we brought on as my assistant a year ago. He came on

I work at a small Japanese company with only two developers; myself and a junior developer (also American) we brought on as my assistant a year ago. He came on with little to no development and technological experience but an incredible work/study ethic and a willingness to learn, which are both MUCH more important to me. The skills can be learned and refined over time, but the fundamentals need to be there; if a developer doesn't have the right mindset or ability to learn, then they're never going to grow, no matter how much you poke at them. One issue I've been fighting (with myself) is knowing when to criticize and knowing when to let him go; I err toward the latter a lot, especially technically, but lean toward giving advice sessions or examples when it comes to communication/professional growth skills. The reason I do this is because it's much, much easier to refine technical skills than it is to refine personal skills... and the personal skills are equally as important at a small company when time is precious and you're working directly with other people who are also under heavy loads and pressure. I bring this up because I was surprised to see zero mention of independence as a prized quality after the author commented that he did NOT feel like a cog in the machine at the BBC. There is, I feel, a fine line between needing to be told what to do every time and being able to make the right decisions on your own. The latter quality -- reasoned independence -- is something I think every work environment should foster in its team members in order to have a team that respects and can support each other. Teams fall apart if members need to be told each and every thing they're supposed to do: members will either grow to hate that or will become mindless minions; the team falls apart when the order-giver is no longer there; over-communication becomes an issue and more time is spent in meetings or replying to 100+ e-mail chains instead of developing things for customers. I rarely see much talk about this kind of growth in developers here though... and it makes me wonder if I'm misguided in placing so much importance on this concept.

austincheney 9y ago
Agreed. It is more about personality than anything else. If you want to learn and solve problems you will simply work at it until you figure it out. I have seen so many developers utterly fail at this. They require not just a particular language, but a particular framework and a certain specific mountain of abstractions. Any less that could remotely expose their incompetence is immediate cause for rebellion. Their strong arguments are whining and excuses instead of simply figuring it out. I don't want to have to work at as a baby sitter if I am hired to be a senior developer. Some junior devs are a pleasure to work with and really bring appreciation to the job and others make me want to quit and go do something else. I say junior devs, but I have also encountered some senior devs whom I would describe as junior.
- sdrothrock 9y ago
  > They require not just a particular language, but a particular framework and a certain specific mountain of abstractions. Any less that could remotely expose their incompetence is immediate cause for rebellion. I would actually rephrase this and go a step farther -- I have met many people who don't like to learn, full stop. They learn the minimal amount necessary to carve out safe, known territory, and do all the work they possibly can to NOT LEAVE THAT AREA. This is obviously a great survival trait and may be good in some careers, but it's not a trait I'd like to see in a developer, especially one I fully intend to do my best in growing.
skyisblue 9y ago
Currently have a junior dev on the team that asks way too many questions, most that can be easily googled. How do we push him in the right direction to become more independant.
- striking 9y ago
  One approach some people take is asking "how much time did you spend on this?", where if time is less than 15 minutes you can usually reject the question outright.
- sdrothrock 9y ago
  Your particular handling of him will depend on his personality and relation to the team, but one way I've found to handle this is to sit with him on a few questions and walk him through the most basic levels of your thought process as you think of queries and Google them, select results, etc. This way you're "teaching him to fish" so that he can use that methodology in the future. While it may often seem simple to "just Google it," it can be difficult for people to come up with appropriate queries and weigh results, especially in new/unknown contexts. A lot of the time we have ready answers if other people ask us questions because we're actively ready to attack and criticize to get an answer, but we're more reluctant to do that with ourselves. So if the teaching approach doesn't work, then another way is to ask him to list up the questions he has, give it 10-15 minutes, then review them himself to see how he would answer them -- the idea is to give him some time to "reset" and get a fresh perspective.
- foobazzy 9y ago
  Well, my mentor used to yell "RTFM, doood!". Which I did. And got the answer more than once. I would like to agree that(as a sibling comment points out) this depends on his personality and relation to the team. When it was my chance to mentor, I would sit with the junior guy and just talk about the context and problem at hand. Talk about the keywords and then form a query to google. I would sometimes intentionally put in the wrong query and then refine it for better results. It worked. But juniors are sometimes bad at retaining processes and a similar query would pop up in a few weeks again. Then I would just send them a lmgtfy link (which is a dick move. Don't do this). Have some compassion, patience and empathy. It might take longer but that guy will thank you in the long run.
botskonet 9y ago
Exactly. I would rather take a first-semester web development student who shows those foundational bright spots than a 20-year developer who does this as a 9-to-5 job. I work with people who did things their own way for 10+ years, never worked as team, never kept up with a quickly changing industry, never improved their skills, that now they're opinionated, they feel that as long as something works it's good to go, etc. Introducing them to a code review workflow exposed how truly uneducated they were. Code review turned into education sessions, explaining how fundamentally they've misunderstood or misused CSS, javascript, or the tools we use. It's dramatic how much money and time is wasted because no one with authority to fire them wants to. Back when I ran my own studio I let people go the instant it became clear they weren't going to make it, but these people couldn't pass a simple interview with me. My company sees it but keeps trying to find ways to solve the problem. You can't throw training at it, you can't throw more meetings.

austincheney 9y ago

Agreed. It is more about personality than anything else. If you want to learn and solve problems you will simply work at it until you figure it out. I have seen so many developers utterly fail at this. They require not just a particular language, but a particular framework and a certain specific mountain of abstractions. Any less that could remotely expose their incompetence is immediate cause for rebellion. Their strong arguments are whining and excuses instead of simply figuring it out. I don't want to have to work at as a baby sitter if I am hired to be a senior developer. Some junior devs are a pleasure to work with and really bring appreciation to the job and others make me want to quit and go do something else. I say junior devs, but I have also encountered some senior devs whom I would describe as junior.

sdrothrock 9y ago
> They require not just a particular language, but a particular framework and a certain specific mountain of abstractions. Any less that could remotely expose their incompetence is immediate cause for rebellion. I would actually rephrase this and go a step farther -- I have met many people who don't like to learn, full stop. They learn the minimal amount necessary to carve out safe, known territory, and do all the work they possibly can to NOT LEAVE THAT AREA. This is obviously a great survival trait and may be good in some careers, but it's not a trait I'd like to see in a developer, especially one I fully intend to do my best in growing.

skyisblue 9y ago

Currently have a junior dev on the team that asks way too many questions, most that can be easily googled. How do we push him in the right direction to become more independant.

striking 9y ago
One approach some people take is asking "how much time did you spend on this?", where if time is less than 15 minutes you can usually reject the question outright.
sdrothrock 9y ago
Your particular handling of him will depend on his personality and relation to the team, but one way I've found to handle this is to sit with him on a few questions and walk him through the most basic levels of your thought process as you think of queries and Google them, select results, etc. This way you're "teaching him to fish" so that he can use that methodology in the future. While it may often seem simple to "just Google it," it can be difficult for people to come up with appropriate queries and weigh results, especially in new/unknown contexts. A lot of the time we have ready answers if other people ask us questions because we're actively ready to attack and criticize to get an answer, but we're more reluctant to do that with ourselves. So if the teaching approach doesn't work, then another way is to ask him to list up the questions he has, give it 10-15 minutes, then review them himself to see how he would answer them -- the idea is to give him some time to "reset" and get a fresh perspective.
foobazzy 9y ago
Well, my mentor used to yell "RTFM, doood!". Which I did. And got the answer more than once. I would like to agree that(as a sibling comment points out) this depends on his personality and relation to the team. When it was my chance to mentor, I would sit with the junior guy and just talk about the context and problem at hand. Talk about the keywords and then form a query to google. I would sometimes intentionally put in the wrong query and then refine it for better results. It worked. But juniors are sometimes bad at retaining processes and a similar query would pop up in a few weeks again. Then I would just send them a lmgtfy link (which is a dick move. Don't do this). Have some compassion, patience and empathy. It might take longer but that guy will thank you in the long run.

botskonet 9y ago

Exactly. I would rather take a first-semester web development student who shows those foundational bright spots than a 20-year developer who does this as a 9-to-5 job. I work with people who did things their own way for 10+ years, never worked as team, never kept up with a quickly changing industry, never improved their skills, that now they're opinionated, they feel that as long as something works it's good to go, etc. Introducing them to a code review workflow exposed how truly uneducated they were. Code review turned into education sessions, explaining how fundamentally they've misunderstood or misused CSS, javascript, or the tools we use. It's dramatic how much money and time is wasted because no one with authority to fire them wants to. Back when I ran my own studio I let people go the instant it became clear they weren't going to make it, but these people couldn't pass a simple interview with me. My company sees it but keeps trying to find ways to solve the problem. You can't throw training at it, you can't throw more meetings.