8 ms·

I don't think dedicated mentorship is required for junior devs. There's usually code reviews in which they can pick up on a lot, a mountain of resources online

by Vadoff 9y ago

I don't think dedicated mentorship is required for junior devs. There's usually code reviews in which they can pick up on a lot, a mountain of resources online, and there's nothing stopping them from asking for help/opinions from fellow co-workers when tackling a problem.

sidlls 9y ago
Junior programmers may not (even probably don't) have a good idea of what questions to even ask. Younger juniors (e.g. right out of college) may even feel intimated or anxious that their question is "stupid". This isn't helped by the software industry's reputation (well deserved, in my opinion) of being populated by arrogant people with little or no tact or empathy. Reliance on online resources is, in my view not a substitute for experienced mentorship: there is the paradox of choice, and the plethora that creates this paradox is of generally poor quality. Except for textbook or trivial problems, moreover, much of the resource material online is too generic or only marginally applicable to the depth and breadth of technology issues that face a real business and its needs.
- Groxx 9y ago
  Totally agreed. This is, in essence, what I would define as the line between "junior" and someone escaping it. Learning how to discern relevant info from random and how to ask useful questions in new areas are skills that take time (and a ton of context) to acquire, but are utterly essential to doing anything beyond what other people tell you to do.
- tanilama 9y ago
  Ask the right question is a skill, and a good indicator for growth. If you have an ineffective team member on your team, you will know the pain. Junior dev isn't necessarily bad, some of them can ramp and contribute really fast, but some are just lacking.
- Caveman_Coder 9y ago
  > "This isn't helped by the software industry's reputation (well deserved, in my opinion) of being populated by arrogant people with little or no tact or empathy." I don't get this attitude at all, but perhaps that is because I transitioned into software dev from the trades. In the trades you want your apprentices to ask questions, I don't see why Senior Devs would be assholes. In my experience, when I asked my Senior Devs questions, and this was after initial research efforts on my part, they were all receptive and helpful. It is much better to ask the question as a Junior than commit to prod and create even more work for the Seniors.
watwut 9y ago
Code review is horrible way to teach. Especially with reviewers common in tech who just can't tell difference between differences of opinion and crappy code. Or difference between "how I would did it" and bad code.
- mlazos 9y ago
  I don’t agree with this at all. It’s up to the participants to argue their points and see who has more valid designs. I became a much much better programmer by learning from senior devs who review my code.
  - sidlls 9y ago
    On the other hand it's possible for this to lead to senior developers who can't or won't leave their comfort zones entrenching designs and patterns that degrade the efficiency of the organization.
  - watwut 9y ago
    Except when Juniors are humble and like "yes sir yes sir", don't defend their design assuming seniors know more and internalize everything. And except when seniors give conflicting feedback based on what they read yesterday. It was mostly impact on those juniors I found bad. They were told their code is crappier then it really was and lost a lot of confidence. They started humble and ended afraid to do anything except simplest tasks. Also, they got only and exclusively negative feedback. Instead of being told in advance how to do things where we are opinionated or being encouraged to ask questions or just being led/given hints, they were expected to do it alone. Then they were told they done it badly and were effectively dictated how to rewrite it. Tech is not different from anything else - teaching people should involve more then just telling them they suck. It should involve telling them what they are expected to do in advance.
    - maxst 9y ago
      Yeah, it was a long time ago (2000-2003) but I still clearly remember implementing everything twice as a Junior Developer - first my way, then their way.
fyfy18 9y ago
When I started my first job out of university I worked in a team where we were tasked with fixing various issues and requests (e.g. reports or minor features) from the business, so that teams working on features could focus on those. Even senior developers would be rotated around into this team, but as a junior develop it was where you first started, to learn the ropes. It was a great experience, as other members of the team, who were more senior than you, may not have even understood how the application you were looking at worked (we had ~40 applications/services), so you would have to work together to figure it out - both completely clueless. Usually we would pair because of the unfamiliarity, but if we were familiar with the application we would occasionally work solo, even as a junior. The best bit was the management: there was enough pressure that you knew you had to get this fixed soon, but not so much that you were stressing out.
cturner 9y ago
When you hire a junior developer, they are themselves a project. How else could it be? The need for mentoring is what makes them a junior. If they didn't need mentoring, they would not be a junior. Code reviews are a reactive exercise. They allow people of influence to criticise work. But it is important that people of influence have first stepped up, and laid out a clear direction. As the mentor, you should have a mental plan for their one month, three months and eighteen month progressions. If you do not have this in mind, you should not have hired them. From here, you should set a tempo that steers the junior to grow. The things you are growing are their skills, judgement and initiative. You need to balance the need to make sure they are heading down a good path against the momentum of their own initiative, which is valuable but also prone to misfiring. This path will be different for each person. So: have a plan, but be prepared to adjust it regularly. There comes a crossover point where their judgement and ability becomes strong. You realise that your steering efforts are holding them back vs their own initiative. There should be some conversation where you explain that you are stepping back, and that they should be careful with the extra rope they will be getting. With graduate hires this will be at least eighteen months out.
- zackya89 9y ago
  Im hired as junior dev. at a relatively large non-tech company, to provide them with software tools, I built all these tools by myself with no mentoring and no help, My fear is this, my code looks clunky (probably not written according to good software design ?), and hard to read for others, I also have no skills in collaboration, how would I be able to grow these skills without a mentor ?.
  - rjsw 9y ago
    You sound as if you are already able to teach yourself, just read more open-source code to find out what is good or bad style.
    - mwdalrymple 9y ago
      I would consider soliciting a formal mentor here on hackernews. Hacking on a open source project together would be a way to recieve that help in a remote fashion. Sounds like there should be a thread to match mentors and mentees here on hackernews. Maybe a bunch of mentors post some open source projects that they want mentees for?

by Vadoff 9y ago

sidlls 9y ago

Junior programmers may not (even probably don't) have a good idea of what questions to even ask. Younger juniors (e.g. right out of college) may even feel intimated or anxious that their question is "stupid". This isn't helped by the software industry's reputation (well deserved, in my opinion) of being populated by arrogant people with little or no tact or empathy. Reliance on online resources is, in my view not a substitute for experienced mentorship: there is the paradox of choice, and the plethora that creates this paradox is of generally poor quality. Except for textbook or trivial problems, moreover, much of the resource material online is too generic or only marginally applicable to the depth and breadth of technology issues that face a real business and its needs.

Groxx 9y ago
Totally agreed. This is, in essence, what I would define as the line between "junior" and someone escaping it. Learning how to discern relevant info from random and how to ask useful questions in new areas are skills that take time (and a ton of context) to acquire, but are utterly essential to doing anything beyond what other people tell you to do.
tanilama 9y ago
Ask the right question is a skill, and a good indicator for growth. If you have an ineffective team member on your team, you will know the pain. Junior dev isn't necessarily bad, some of them can ramp and contribute really fast, but some are just lacking.
Caveman_Coder 9y ago
> "This isn't helped by the software industry's reputation (well deserved, in my opinion) of being populated by arrogant people with little or no tact or empathy." I don't get this attitude at all, but perhaps that is because I transitioned into software dev from the trades. In the trades you want your apprentices to ask questions, I don't see why Senior Devs would be assholes. In my experience, when I asked my Senior Devs questions, and this was after initial research efforts on my part, they were all receptive and helpful. It is much better to ask the question as a Junior than commit to prod and create even more work for the Seniors.

watwut 9y ago

Code review is horrible way to teach. Especially with reviewers common in tech who just can't tell difference between differences of opinion and crappy code. Or difference between "how I would did it" and bad code.

mlazos 9y ago
I don’t agree with this at all. It’s up to the participants to argue their points and see who has more valid designs. I became a much much better programmer by learning from senior devs who review my code.
- sidlls 9y ago
  On the other hand it's possible for this to lead to senior developers who can't or won't leave their comfort zones entrenching designs and patterns that degrade the efficiency of the organization.
- watwut 9y ago
  Except when Juniors are humble and like "yes sir yes sir", don't defend their design assuming seniors know more and internalize everything. And except when seniors give conflicting feedback based on what they read yesterday. It was mostly impact on those juniors I found bad. They were told their code is crappier then it really was and lost a lot of confidence. They started humble and ended afraid to do anything except simplest tasks. Also, they got only and exclusively negative feedback. Instead of being told in advance how to do things where we are opinionated or being encouraged to ask questions or just being led/given hints, they were expected to do it alone. Then they were told they done it badly and were effectively dictated how to rewrite it. Tech is not different from anything else - teaching people should involve more then just telling them they suck. It should involve telling them what they are expected to do in advance.
  - maxst 9y ago
    Yeah, it was a long time ago (2000-2003) but I still clearly remember implementing everything twice as a Junior Developer - first my way, then their way.

fyfy18 9y ago

When I started my first job out of university I worked in a team where we were tasked with fixing various issues and requests (e.g. reports or minor features) from the business, so that teams working on features could focus on those. Even senior developers would be rotated around into this team, but as a junior develop it was where you first started, to learn the ropes. It was a great experience, as other members of the team, who were more senior than you, may not have even understood how the application you were looking at worked (we had ~40 applications/services), so you would have to work together to figure it out - both completely clueless. Usually we would pair because of the unfamiliarity, but if we were familiar with the application we would occasionally work solo, even as a junior. The best bit was the management: there was enough pressure that you knew you had to get this fixed soon, but not so much that you were stressing out.

cturner 9y ago

When you hire a junior developer, they are themselves a project. How else could it be? The need for mentoring is what makes them a junior. If they didn't need mentoring, they would not be a junior. Code reviews are a reactive exercise. They allow people of influence to criticise work. But it is important that people of influence have first stepped up, and laid out a clear direction. As the mentor, you should have a mental plan for their one month, three months and eighteen month progressions. If you do not have this in mind, you should not have hired them. From here, you should set a tempo that steers the junior to grow. The things you are growing are their skills, judgement and initiative. You need to balance the need to make sure they are heading down a good path against the momentum of their own initiative, which is valuable but also prone to misfiring. This path will be different for each person. So: have a plan, but be prepared to adjust it regularly. There comes a crossover point where their judgement and ability becomes strong. You realise that your steering efforts are holding them back vs their own initiative. There should be some conversation where you explain that you are stepping back, and that they should be careful with the extra rope they will be getting. With graduate hires this will be at least eighteen months out.

zackya89 9y ago
Im hired as junior dev. at a relatively large non-tech company, to provide them with software tools, I built all these tools by myself with no mentoring and no help, My fear is this, my code looks clunky (probably not written according to good software design ?), and hard to read for others, I also have no skills in collaboration, how would I be able to grow these skills without a mentor ?.
- rjsw 9y ago
  You sound as if you are already able to teach yourself, just read more open-source code to find out what is good or bad style.
  - mwdalrymple 9y ago
    I would consider soliciting a formal mentor here on hackernews. Hacking on a open source project together would be a way to recieve that help in a remote fashion. Sounds like there should be a thread to match mentors and mentees here on hackernews. Maybe a bunch of mentors post some open source projects that they want mentees for?