https://humanwhocodes.com/blog/2014/01/07/how-to-be-a-mentor...
I think this is critical, and engineers seem to struggle with it more than the average person. Remember your codebase is a business tool, not an art project. It's okay if some of your junior person's inelegant code ships as long as it works acceptably well. If you try to make every line exactly what you would have written, you'll drive yourself crazy.
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.
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!
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.
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.
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.
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.
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.
> 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.
With the lead dev define what “progress” would look like as specific, measurable goals and then work towards those goals with the jr.
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).
It may also be worth your company’s time and money to find some online training courses to target specific weak-points.
The best guide I've seen so far on how to do this is by Julia Evans: https://jvns.ca/blog/good-questions/
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.
>He seems motivated to learn but has a bad intuition on how to do things the "right" way.
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?
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.
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.
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.
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.
> 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!
