Why do I love to teach?
The ability to properly onboard and coach Junior Devs is essential for any successful company.
Unfortunately, many companies don´t give enough attention to this process and expect juniors to be productive from day 1, with very little support. Their seniors and managers are too busy working to meet project deadlines, so they cant afford to "lose time" with Juniors.
What they fail to understand is that time is not "lost time" but it's an investment in the future of the company.
Because of these bad processes, many talented developers are lost.
Get to know your mentee
You will be dealing with people and everyone is different, so your first task should be to get to know them.
What´s their background, it's their first job or they have any previous experience, what they prefer to work on (backend, frontend, some specific language), their job/career expectations, how do they like to work, etc.
It's also your opportunity to show you are there to help and to make them feel comfortable with you.
By knowing them well, you will be able to understand better what kind of mentorship they need.
Be patient and understand that people learn at different speed
Sometimes you might see your juniors as a mirror of yourself and if you were a fast learner and the company demands you to keep the rhythm of your other "Senior Level" tasks you might feel frustrated if they can't learn as fast as you would like.
Just be patient.
People learn at different speeds. The key is that you should gradually see some improvement, even if it's small.
I have a very interesting story, about how people from similar backgrounds can be so different and needed different kinds of mentorship.
On that first company I worked on, two devs took a 6th-month internship. Same university, almost the same age, joined the company at the same time.
They were completely different.
One of them was an incredibly fast learner, very curious, and I didn't have to tell him almost anything. He could easily Google around to find an answer to his problems. Our discussions were more "advanced" around patterns and how to organize the code and stuff like that.
The other one was more introverted and needed much more guidance on more "basic" concepts. He was also less autonomous.
The first one stayed in the company after the internship. The second didn´t.
Both of them ended up following very different paths but are now amazing Software Engineers.
Growth is not something linear and varies a lot from people to people. I also think many promotions ladders are flawed because they expect linear growth. (Ex: you can't be promoted more than 1 level at a time, or be promoted in 2 consecutive evaluation processes). But that would be a topic for another post. ;)
It's a bit like football players. There are some wonderful kids that reach a world-class level with 18 y.o but also many ones that only reach their top level at 25 y.o or older.
There are many factors that can affect performance and learning speed even inside the same company, like a project or team environment.
Maybe the team is not friendly and she doesn't feel comfortable asking questions? Or she is working on a very complex project with a lot of legacy code? Or she is jumping between technologies or frameworks and can´t focus on learning anything well.
It's your job as a mentor to understand the context and try to create the best possible environment to let her grow.
Pair programming
Pair programming is often an underrated activity but it's an amazing way to share knowledge.
In many cases, I believe it's much more productive for both mentee and mentor, to spend an entire afternoon together, solving a problem, from start to finish, than being each one in their tasks and constantly interrupt each other with questions.
By doing so, you can also teach them other important skills, like working with other people, or how to brainstorm and discuss ideas. You can even spot ways to improve their development workflow. Ex: Some useful keyboard shortcuts in the IDE that she might not know about.
Just make sure both switches place constantly from driver to navigator. Don't get them too comfortable in one role.
Constant and early feedback
I once read somewhere, "If in a Performance evaluation phase you were surprised with a bad performance, then something is wrong with the process". This is spot on.
If you are a manager, don´t wait till the evaluation process to tell them about their performance. Give constant feedback. What they are doing good, and what they can improve. Listen to their concerns. Understand their career goals and give them conditions to achieve those goals.
Code Review
Code review is one of the most important activities you can do as a mentor. Don´t take it lightly.
Don´t wait till the task is finished where the probabilities of them having to refactor big part of it are quite high. Instead do frequent discussions about a possible implementation of the solution (Ex: in pair programming session).
When reviewing their code, make sure you understand well the context and their ideas regarding the implementation. Make actionable comments and explain the rationale behind them. Dont just say, "this is wrong, do it this way".
If possible do the review together, so they can better explain their ideas behind the implementation and discuss alternative ways if necessary.
Let them take decisions and make mistakes
Everyone make mistakes. And its a great way to learn.
It might be tempting for you to micro-manage and try to make sure they do everything in "your way". Don´t to that. Give them some freedom to try their own approach to a problem.
If it goes wrong, explain how they could have done it in a different way. If it goes right, congratulate them.
Failure is simply the opportunity to begin again, this time more intelligently -Henry Ford
A new pair of fresh eyes, can often see things and propose simple solutions, that people who are already so deep in the problem can´t see.
They won't learn if you put them in a protected "bubble" from the outside world and give them all the answers.
Let them ride the bike without training wheels sometimes.
Help them define their Career Path
There are so many career paths in our industry, that can be hard for someone that just gets off the university and get their first job, to know exactly what they would like to do.
As a mentor, you can help them a lot with that. You could, for example, show or let them working with different technologies from frontend to backend, ops, etc so they can get a feel of what they like more. But be careful. Dont let them become overwhelmed by the possibilities. I believe a junior has to focus on becoming really good at something first, before expanding their horizons.
But that´s why you should "Get to know your mentee". So you can understand their concerns and expectations and help them accordingly. Maybe she already knows exactly that Backend Development is their passion? Everyone is different.
If you are a Junior reading this ...
I also have some advice for you.
Always ask questions!!
Just make sure you spend a little time on your own first.
Many questions can be answered with a simple Google or Stack Overflow search. Always put a time limit on your search. It could be 30min, 1h, but if you feel stuck, ask for help!! The worst thing it can happen is you become stuck for hours in a problem just because you were afraid to ask or didn´t want to interrupt your mentor or someone in the team.
Also, be proactive and think about possible solutions for the problem first and present them to your mentor. It will be a much more interesting conversation and you will learn much more if you deep dive into a problem yourself looking for solutions, than always waiting for someone to give you the right answer.
Be curious and show interest.
Challenge your mentor. The fact that she has much more experience than you, doesn't mean she is always right.
Celebrate your achievements together ;)
Conclusion
Mentorship of Junior Devs is a very important process. I believe, it should be part of any Senior / Team lead daily job. But I also understand that not every Senior Dev have the skills required to be a great mentor. The worst thing you can do is to force a top developer into a bad mentor.
It's not an easy job, especially when you have your own tasks and deadlines and you don't have enough support from your managers.
It's invisible work many times, at least in short term, and others from outside might think you are getting less productive in your coding tasks because you are "loosing" time in your mentorship tasks.
But its also very rewarding when you see your mentees growing and doing great things ;)
That´s all for today.
If you want to buy a coffee, I would appreciate it https://www.buymeacoffee.com/gelopfalcon
Thanks for reading and feel free to comment.
Oldest comments (0)