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.
> 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<p><a href="https://humanwhocodes.com/blog/2014/01/07/how-to-be-a-mentor/" rel="nofollow">https://humanwhocodes.com/blog/2014/01/07/how-to-be-a-mentor...</a>
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:<p>1) You're motivated to help<p>2) The junior engineer is motivated to improve<p>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.<p>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.<p>Good luck!
> I can lead him to be a better developer<p>You can lead a horse to water but you cant make it drink, people are more stubborn than horses and will just act out if you try to lead them.<p>You should act as an example of how the junior should behave. If you want the junior to ask for advice when they need it and value that advice then you will have to demonstrate this.<p>Don't limit yourself to asking the lead or asking about things you don't know about. Valuing other peoples advice even when you don't need it is a sign of seniority not a sign of being incapable, it shows that you understand that improving your skills never stops and you can find improvement in anything.<p>When the junior asks you for your advice your job is to act as a sign post point them down the right path. Tell them warn them of gotchas and encourage them but don't carry them for the journey or spoil whats at the end, thats for them to figure out.
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 <i>lot</i> 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.<p>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.<p>Is such a thing patronizing? I think, yes, but that without it being nefarious.
Ask them to keep a written log of the stories they work on, and during “mentoring time” use it for things to talk about. (Why did you do this? What did you think would happen? Etc)<p>> 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.<p>With the lead dev define what “progress” would look like as specific, measurable goals and then work towards those goals with the jr.<p>In the classroom a common technique is I Do (E.g. the jr watches you break down a story), We Do (break it down together), You Do (it’s all them, but you give support and feedback).
Intuition is built-up over time. I would try and carve out smaller, well-defined tasks for the individual.<p>It may also be worth your company’s time and money to find some online training courses to target specific weak-points.
One of the most important skills for a junior developer is the ability to ask good questions. As a lead, you're never going to be able to perfectly set them up with <i>all</i> the context they need for a task, so they're going to need to be able to get the bits that they're missing.<p>The best guide I've seen so far on how to do this is by Julia Evans: <a href="https://jvns.ca/blog/good-questions/" rel="nofollow">https://jvns.ca/blog/good-questions/</a>
> ... as they have worked together for quite a while without any substantial progress on the juniors side.<p>Seems like a misalignment on ability and expectations of the jr. What is "substantial" progress defined as? Was that definition shared with jr? It's hard to make progress towards something if that something is nebulous.<p>>He seems motivated to learn but has a bad intuition on how to do things the "right" way.<p>What is the "right" way in context? Is it the difference between a non-working and working a solution? Or is the difference between a sub-optimal solution and the best possible solution?<p>To me this sounds like an ideal jr hire. Eager to learn, and still green. This sounds ultimately like a case of poorly defined expectations.<p>What do you expect the responsibilities of the jr to look like in 6 months? A year? If you start there you can work backwards and help set smaller goals.<p>Without a strong idea of where you want them to end up, you're just asking them to "get good" which is bound to be frustrating for all parties.
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.<p>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.
There's a lot of great advice here already.<p>> Tried to break down tasks together, to a point where I rather have implemented the stuff myself<p>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.<p>Hopefully if you're taking that much time together, you enjoy each others company, which I think is a good sign!
Get them to read at least the first 13 chapters of "Clean Code" by Robert C Martin. I read it 6 months into my first professional engagement and it helped my development a lot. It will make your life easier too.