Live data from Hacker News

Ask HN: How to Guide a Junior Developer?

news.ycombinator.com

1–10 of 18 posts

Ask HN: How to Guide a Junior Developer?

#1
I recently started a new position as a senior developer in a small company. The setup is basically CTO/Lead Dev - Me - Junior Developer. The junior is a newcomer with a non IT background. We do webdevelopment and I have a bit of a hard time to understand how I can lead him to be a better developer. He seems motivated to learn but has a bad intuition on how to do things the "right" way. Happy about tips on literature or any practical advice how to guide him. We do Kanban style development with code reviews, CI/CD for context. Tried to break down tasks together, to a point where I rather have implemented the stuff myself. I can spend roughly about 20% of my time to invest in him for a couple of month. Lead dev seems happy to not be involved in the process as they have worked together for quite a while without any substantial progress on the juniors side.

Re: Ask HN: How to Guide a Junior Developer?

#4

> 1) Make it their time 2) Mentor the whole person 3) Don’t give answers, provide strategies 4) Give homework 5) Don’t prevent all mistakes, just horrible ones 6) Don’t try to create a you-clone https://humanwhocodes.com/blog/2014/01/07/how-to-be-a-mentor...

This is a great answer. People have different learning styles.

Some mentees will also likely have a desire to impress you so they'll get good at doing things exactly how you want them to do it. This is also learning, but not the learning you want.

Re: Ask HN: How to Guide a Junior Developer?

#6
I've been mentoring junior engineers for fifteen years and I've found a lot of techniques that work but there are two ingredients that I think have to be present:

1) You're motivated to help

2) The junior engineer is motivated to improve

I don't think it matters what techniques you use if these two things are in place. If they're not in place then it is very likely not going to pay off regardless of how you approach the mechanics.

Code reviews are critical. Pair programming can be a valuable technique. Going over concepts and best practices can help. Creating a plan for the junior engineer to study the craft. Books like Clean Code can be great at starting discussions.

Good luck!

Re: Ask HN: How to Guide a Junior Developer?

#7
A key focus that I always have when mentoring juniors is confining their work scope to something they can refer back to. It is a common mentality to simply allow them to browse around the code and perhaps solve some simple bugs. To allow them to understand the system and how it all works. My thoughts on this is that doing so is akin to giving someone new to a spoken language a novel, suggesting they peruse the book and perhaps find a typo. Understandably this can be a lot to take in.

For me I assign them a fully refined task to create something and go through the full end to end process with them. It will allow them in the future when hitting a road-block at any step of the process to go back to this code, ask themselves "what did I do here which was right" and try to apply it to their current work.

Re: Ask HN: How to Guide a Junior Developer?

#8
There's a lot of great advice here already.

> Tried to break down tasks together, to a point where I rather have implemented the stuff myself

I know this happens. I've felt it myself sometimes. But I just try to remind myself that this is the investment part - sometimes it takes a lot longer, but the question is what will they be able to produce this time next year? It's a good feeling when someone goes from taking a long time and having bad intuition, and seeing them get to a better place. The red flag is when they don't seem to improve over quite some time.

Hopefully if you're taking that much time together, you enjoy each others company, which I think is a good sign!

Re: Ask HN: How to Guide a Junior Developer?

#9
That 10,000 hours of work to master some process - that happens after 4 years of full time, salaried work, and after a quarter century, balloons towards 60,000 hours of doing this stuff. I never feel like I know very much, but as I start to notice grey hairs here and there, it occurs to me that I do know a lot of stuff. Broad stuff. None of it makes me a genius, and, I'm not a genius so the math works out. My junk drawer is just 50 feet deep.

But taking someone with more like 150 hours of experience, who has just barely been indoctrinated into a complex process, who has no idea what they don't know they don't know ... yikes! We have to sometimes literally pretend that we have magic, and then work backwards from that so as not to overload them. I have found myself adopting a naive persona as I teach, a sort of fool that is also discovering as I demonstrate, to try and relieve some of that intimidation.

Is such a thing patronizing? I think, yes, but that without it being nefarious.

Post reply on HN