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!
Latest comments (43)
Interesting post for me as a junior developer still finding it challenging to navigate through the system, I think it's high time for me to get a mentor... Ready to learn any offer out here?
Hi Tiamiyu, this post here might interest you!
Changelog: Mentor Matchmaking!
Jess Lee
Thanks, i just updated my profile.
I'm a junior web developer too but I've taught students how to develop websites (static ones ) , maybe that may not be your case but I really concentrate when sharing my knowledge on showing the big picture. Describe the big picture for him , the concept generally not just the technology. Sometimes people know the answer for their problems but they think they don't, it's really important for me that I concentrate on solving the problem with the knowledge that I have, if my skills don't do the work, then I should learn the one that solve it.
Hi Lynne,
Speaking from a junior developers point of view since I am one. I would say be prepared for lots of questions and sometimes blank stares.Being a junior developer and asking questions can sometimes be quite scary and intimidating.
So what I have found useful with the mentor on my current project is that has soon as I ask him a question he's like sure not a problem but I will be asking you questions in return.
So the process of his mentoring is for every question I ask he will answer it with another question which really worked for me reason being it help me to think a little out of the box and instead of giving me the answer he guides me towards it .
This way proves to be more effective because he does not just spew out the answer,
he makes me re-think and analyse the problem at hand and if that fails a good session of pair programming is quite beneficial because your mentee then see's the missing pieces by discussing as well as sharing ideas and thought processes.
Another really awesome thing that actually works for me is before my mentor can leave my desk he just asks one last question and that question is What did you learn? This question is a great way for the mentee to reflect on what they have learnt by summarising it in their own terms.
This just my point of view.I hope it helps.
Thanks Ryhila, that's very helpful :)
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!
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!
Hey Lynne,
I regularly teach other people to do statistical analyses. In our company, we have a lot of code from previous projects. When I teach somebody, I usually give them old projects that are somewhat related to what they will be doing and ask them to read the code. Thats it, just reading the code. When they have questions about a specific piece, I always answer them immediatelly and try to explain the piece as best I can.
The thing that helped me the most, when I started programming was the following realization: You will always have a deadline, and the code will never look as pretty as you want it to be. You have to find the right balance between making the program nice and clean and finishing it on time. Best, Flo
Thanks for this Florian, very true!
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!
Best advice that I got from my mentors is "It's okay to fail; don't be afraid of making mistakes".
My preferred way of teaching development work is to give simple tasks to gauge their programming skills and progressively increase the difficulty of tasks. When they complete their tasks, I like to ask a simple 'Why' with a smile, and let them answer their decision making process. May be following up with another question 'What could happen in xxx scenario? or 'Have you considered this scenario?'. Just help them understand the problem, but let them decide the implementation. If it's something that they weren't aware completely, I would just give few hints about the 'concept' or let them google and find the answers.
One more suggestion that I would give is not to be over-protective of the junior developers. When you see them making mistakes, it's very easy to jump in and help them solve their issues. But it wouldn't help them grow. So sometimes it's okay to let them fail. They can learn from their mistakes and come up stronger.
Thanks Subbu, good tips! It is definitely harder than I thought to try to not give them the answer and let them work it out!
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.
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.
Hii Lynne, I'm a "brand new" developer, I had some mentors during my periods of work on little startUps. And in my opinion the most important thing is stablishing a connection with your pupil, I did the things better when my mentors and me had a good relation. I think you have to give them liberty enogh to do the things by themselves and help them when they are in trouble.
Hi Carlos, thanks for your reply and advice. I'll take that on board!
Luckily my workplace is very welcoming to new people, and we all go out of our way to make new people feel like a part of the team.
Here what I use to do:
I think is pretty much this...
Thanks Leandro!
I am an autodidact developer and here are some of the things that helped me in my junior days.
Learn your language of choice before what ever platform you want to work with.
Read documentation for everything you're currently working with like it's your best friend.
Learn what S.O.L.I.D means and be able to recite it on command. Even if you do functional programming.
At the very least learn the benefits of functional programming. OO languages these days are moving towards functional styles. Scott Wlaschin, know who he is.
TDD for at least your business logic.
Use git and then start playing with stuff. With git you don't have to care about breaking stuff. Play play play
Build as much stuff as you can. Build more stuff.
After you have all that down move on to algorithms for sorting and parsing.
HAVE FUN!
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.
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
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!
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.