Hi!
I work as a front-end developer, and have recently found myself in the position of mentoring and training a new junior front-end developer.
I'm relatively good at dealing with people on a personal level, but in terms of training and teaching good coding practices, I haven't really had to do this kind of thing before.
I thought it would be an interesting discussion in the Dev community, to find out what other people's experiences are with this kind of thing. As a developer, taking on a role that involves managing another person can be daunting. At the moment I find that I just want to be as helpful as possible. How do you start to transfer knowledge and experience that you've gained over years?
Here are a few questions that I'm curious to know:
What is the best piece of advice you were given as a junior developer?
Have you ever had a 'mentor' of some kind?
Do you have any preferred methods of teaching development work to another person?
Discuss!
Top comments (43)
Hey Lynne. I have been a mentor for this past year, what I do simply gave them freedom to do task and challenges. But firstly, I'll tell them what I usually do and let them do the rest and creatively. Also, be there when they need to ask
Hi Ahmad, thanks for your reply.
I'll definitely try to give them as much creative freedom as possible!
so how is it going with you?
It going well, thanks for asking :)
Just making myself always available for questions and trying to take a more active role in reviewing code. How about you?
It's been a year on leadership/mentorship position, I felt invest time on people and process boosted high impact. Right now, I am going to venture let my team self organize freely and give them much more time to guide others too :)
I'm a junior dev so I'm just going to talk about the best environment I could think of.
From my experience, the people who helped me gave me a lot of freedom. Just: "Here is the codebase. Here is what I want you to do. If you have ANY questions, I'm here." They were a safety net. But I think the most important thing they did was that they never made me feel out of place. It's easy to feel like an impostor when you start out. The right comments when the developer fucks up can go a long way.
Hi Damien, this is very helpful, thank you!
Especially the part about it being ok to fail. I definitely don't want anyone to think they are bad at something, or doing a bad job, it is completely expected (whether you are junior or not). So I will keep that in mind!
You want to put a seed down and watch it grow. Give it some water every now and then, but don't force it.
More specifically, to mentor a Junior dev give them a very high level idea of how you would solve the problem, and especially WHY you'd do it that way. Spend most of the time on the why. Do not give them an exact idea of the how. They need to come up with the soution by themselves, but they need that initial seed to start growing.
Tacking onto this: Promote their critical thinking and googling skills by either asking them 'leading' questions or working off their current solution/code.
Context: I teach mathematics for a living, so when interacting with students I always ask to see what working they've done first, or what they think, and then work from there. Sometimes when they ask questions I respond with a 'leading' question that ideally leads them down the correct logical path.
It's hard to consistently get right and heavily dependent on the student, but a generic conversation might be:
Jr: How do I do $task?
Me: Did you have any ideas to begin with?
Jr: There's $idea1 and possibly $idea2.
Me: OK, how would you do $idea1? What do you need to know to execute $idea1?
Matthew. This is the most terrible thing you can do to me in a work or school environment, it doesn't matter. I understand the reason you do it and in many cases it probably proves successful but for those people like me please just provide the answer and simply be specific and complete as to why that is the answer.
If the answer is sufficiently substantiated then I can continue what I'm doing. When I ask somebody how to perform $task it is never the main task but just a step towards whatever I want to achieve.
I can figure out myself that if I have two or three possible solutions/directions I simply have to explore them both and I'm sure I am not alone in the universe with this natural ability. Someone who does not should not be solving problems.
The last thing I want is every time that I need a binary answer, some teacher has the bright idea to make it a riddle and reflect on it extensively or involve the entire class. It is inefficient and annoying and it completely shuts me off preventing me to provide any type of helpful response.
That all being said. I am well aware that I am sometimes different than others so please do not interpret this as criticism. You are a teacher and I am not so you know better.
Thanks for this Matthew, great tip!
My best mentor led the way but never gave me solutions. Making me struggle to find the answer helped me learn about how to learn
That's a great analogy!
I'll definitely try to focus on the 'why'. Thanks for your advice Lorenzo :)
My pleasure. Let me know how it goes.
Hi, Lynne
This is my personal experience, so, please, don't take it as an ultimate truth.
Thanks to all people that have spent time in this discussion, I found many points very valuable.
From my small experience in mentoring a junior dev I can safely say that the most important thing(for me) is TRUST. Whenever he/she feels like you're always there, ready to help, great things start to happen.
This is difficult to build as any human relationship, but believe me, it does pay off.
Among other important things (in no particular order):
Don't overmentor. I fell into this trap many times. As a more senior dev, you certainly know how to do things the right way, but don't force it. Give them time to learn and figure out things.
Don't put too much on their plate. New place and people is already an overwhelming experience. I tried to give some small tasks in the beginning, explaining the context and reasons behind some of the technical decisions. It certainly made our process more manageable.
Ask questions. Be genuinely interested. Mentoring is a bidirectional process. My junior dev was amazing. We asked each other questions about the solutions we found. We justified our thought process and shared ideas.
Give freedom. Software development is art (in my opinion). Therefore, embrace their creativity and direct it when necessary.
Thanks for reading, I hope it will be helpful to you.
Hi Danil, thanks for the advice. I think the 'Don't overmentor' part is important and also probably the hardest thing to do!
I think it is most important to create an enviroment which allows them to fail. I mean things can quickly get overwhelming in the beginning. Mistakes will be made. With a good guidance there is a great potential to grow from these. The trick imho is to create a lifeline which limits the mistakes to a managable level. For the company and the junior. Make code reviews with them and have a routine in which you talk about current challenges. And all solutions are valid if they work. Elegant or clean code should be a result of refactoring and not the initial expectation. Explain which things could be improved without stomping the current solution to the ground.
Great advice, Steffen! "Make code reviews with them and have a routine in which you talk about current challenges" - as a not-so-junior back-end developer who joined a company recently, this will allow me to onboard/start contributing faster
Thanks for this Steffen, I'll keep that in mind!
I've had a mentor in the past, and for the past year I mentored a few devs myself. What I think you can never do (unless the dev loses a whole day or week on a task) is to give them the solution. "I can only show you the door. You're the one that has to walk through it.". I often shift them in the correct path, without telling them much, just an overview of things. What usually happens is, either they learn a lot, or..if they're not passionate enough, they just quit and don't even bother to google for 5 minutes. Either way it's a good thing, because, either he learns, or you know he's not passionate enough about web dev and that you'll probably wasting your time. "When the student is ready...the master will appear.". I often did the mistake that trying to help everyone, and that doesn't work, they must have the initiative to come to you, that way you know their intent is pure and both of you will be rewarded with fulfilment. That being said, practically you should know what's their level, and assign them with tasks a little bit over their level, that way they'll use all the resources they know, and they need to learn a little bit more to finish the task you gave them. Thoughts?
This is very true, thanks for the advice.
I guess it's a balance. Sometimes I find I want to give them an answer because it is something I've found a good solution to myself, and it's not something everyone would know. So in some ways I see it as trying to pass on my experience. But I guess it depends on the situation/problem!
Hmm, I had a colleague who taught me some very basics of frontend webdev, and a HTML/CSS-course at Uni (Design-Student), but other than that I had no coding-lessons/teachers. Luckily I was given time to learn at an OK pace, since in the first 2 years I didn't have to do JS at all, and then could ease-in and do more and more in the following years.
Nowadays our junior frontend-devs don't have that luxury, but at the same time we have more frontend-devs who can help each other out.
Currently I'm taking care of one junior-dev in my project, and I always try to give her some practise-tasks that kinda match the work we have to do for the client.
For example I gave her an assignment to make a website that consumes the Spotify-API, plays song-previews and fetches cover-images. The purpose was to get her to know Ajax/Fetch and media-controls, for some feature we were doing for the actual project.
I also try to encourage our junior-developers to learn fundamentals. Not only Web-Tech, but CS in general, since most frontend-people (including me) don't have an academic CS-background.
Thanks for the advice Antonio! I definitely agree that learning the fundamentals is best.
The practice tasks are a good idea, I'll try to line a few more of these up and think about how they can relate to our projects.
Here what I use to do:
I think is pretty much this...
Thanks Leandro!
Helping junior developers is great fun. For me it all comes down to sitting next to them and letting them try to develop difficult functionality. I don't believe in the "Sit down and listen to me" way of teaching (in any form, really) so I let my developers try things, make mistakes and improve by searching for better solutions. When they have questions, I'm always available to answer those questions, even when I'm knee-deep in a module myself.
At most of my jobs/projects we've used pull requests that require code review to be accepted. This helped developers be critical of their own code and learn from their peers.
If you have developers working under you, at some point you'll find yourself writing less and less code as you're helping your developers improve but I think that's the point of being a senior developer/CTO.
Thanks for the advice Stefan!
When I mentor someone I usually move my things and sit right beside the person. I find this makes a big difference especially when its that person's first job and they're not sure if they should ask a question. I also tend to ask what they're up to regularly so that by the time they open a PR the code is less likely to get rejected.