So you got that team lead promotion. Congratulations!. Chances are that the team you are about to take responsibility for has few junior developers and you are wondering how to handle it.
Or maybe, a new junior developer is about to join your team. It's been a while since that last happened so you want to refresh how to make sure fresh acquisition has a smooth start. Take this article as an opinionated step-by-step guide for turning fresh out of Bootcamp/Uni newcomers into valuable team members you can rely on.
During my career, I have mentored dozens of juniors. Each of them was unique and I had to make adjustments here and there, but generally, the following points worked for most of them.
Write documentation
Over the days and months, your product grows, and naturally, the codebase follows. People who wrote the code will come and go and so will the knowledge.
It's not in human power to keep all the information about business logic, architecture, infrastructure, and processes in your head. It's not the most fun task but find time to do it.
It is obviously a no-brainer and ideally needs to be set up beforehand. But in case you haven't done this yet no worries. Sit with newcomer go through module or service, explain high-level view. Then leave figuring out details to them and as a final step let them write docs. Win-win situation.
Overcommunicate & undercommunicate (sometimes)
So new guy went through the initial onboarding process and is ready for the first task. You click that assign button on what you think is a trivial task that would take you half an hour.
You are a reasonable guy so you expect results at the end of the day or tomorrow at worst. But well that was Monday now it's Thursday afternoon and no PR was submitted.
The problem with the juniors is that they tend to be afraid to ask any questions, especially what would they perceive as stupid ones. Or on the other hand, would spam you with stuff they should be able to figure out by themself.
The first group would be stuck for hours with some random compilation error due to missing access rights or because they forgot to pull a new docker image from the nightly release.
The ideal situation is to have them sitting next to you if you are working onsite to keep an eye on them
As we're living in covid-19 time it's a good idea to ping a new team member once in a while in a chat with friendly hows the task going or is there anything I can help you with? questions. Daily team meetings aren't enough for this. Do it in one or one fashion.
Members of the latter group on the other are very eager in asking questions but if you don't respond immediately they tend to figure it by themselves (if they are any good) and that speeds up their learning process.
It shouldn't be that hard to figure out to which group your new colleague belongs and act accordingly. Most will fall somewhere in between so you want to use a mixture of these approaches
Do code reviews
I have always felt this is somehow a standard part of the development process in every company. Except, it isn't. Among the million reasons why the team is not doing (proper) CR's are - laziness, we don't have time for this, we write golden code mentality or it's so trivial it doesn't need code review. Don't fall for this it is the road to hell.
Don't get me wrong it consumes the time of senior team members but benefits for juniors are invaluable and over time you will realize that they greatly benefit the whole team.
Now, you should be pretty hard on code reviews. It's not uncommon for the newbie to have that first PR approved on 4-5th iteration. When I'm doing code review I do actually make difference between senior's and junior's PR. For seniors, I usually leave brief comments ie "Does this impact performance in any way ?". For juniors, though I tend to leave lengthy comments with links to resources I think could help them understand what I'm concerned about.
From my experience, almost 100% of juniors are happy and have a real sense of accomplishment after their first pull request was approved. Afterward, I asked all of them the very same question. "Hey Susan how does your first draft of code compares to what we are actually merging into master". The answer is always "I love it".
I'm not saying it because it sounds good for the article but because it's true. It requires your time, a lot of time, in the beginning, to be honest. But in the long run, it will pay off I promise.
Don't let them get comfortable
I have a little story here. At some point, I joined the project as a senior front-end engineer. Everything went well I was shipping features, improving performance, had sleepless nights due to random memory leak, etc. Nothing too unusual you could say.
One day team realized we are hella short on backend developers. In addition, the HR department wasn't doing its best in terms of hiring. So as I already had experience with the backend for some years, I volunteered to help. Sounds good, yeaaaaah no.
My experience was Java 6 monolithic project compiling for 2 hours. Instead, this was Scala microservices exposing GraphQL API, using things like Kafka or gazillion of AWS services. Needless to say, I was clueless.
I can tell you time travel is real. In a blink of an eye, I went back 8 years back to my junior days. People in general, especially programmers tend to quickly forget how hard is to learn anything once we master it. After some years you know how the network layer works, what are red flags in particular functions, how a web page is rendered inside out, and a lot more. What is blurred is how we have gained that knowledge. Experience, series of AHA moments, and good mentors. Junior devs at the beginning of their careers haven't gone through it. Keep that in mind at every point.
It was hard at first but in 3 weeks with the great help of my mentor, I shipped my first production feature in service A. Oh boy, what a sense of accomplishment I had. Instant endorphins, senior ninja rockstar backend dev at your service high-fiving all his friends. Yeeaaaah no ... again.
I was instantly assigned a new task in service B unrelated to service A. Sigh, back to square one. After that story repeated itself with service C.
This went on for the next at least half of the year. I'm not gonna lie, it was hard, but eventually, I was able to understand and discuss most of the complicated features implemented across multiple services. If, in the beginning, I had settled with my knowledge of service A all of that wouldn't happen.
I have been using this technique since with awesome results. You can apply this on the backend as well as frontend. Just don't let them settle
Ownership
In my mind, this is the last step of "onboarding". Naaaah not that HR checklist onboarding stuff. Think like graduation for a junior developer.
It usually comes 6 to 12 months after joining the team. Junior developer now understands how things work under the hood of your project. Does not make the same mistakes seniors already pointed out in code reviews, ask correct questions, and/or comes with his own ideas on how to improve the codebase.
Select next relatively big isolated task. It can be anything. Implementing new product feature, improving accessibility of mobile app, rewriting legacy module, migrate from MongoDB to DynamoDB. Anything!.
If a task involves architectural decisions, of course, keep eye on the process and help, you don't want to get the product into trouble.
From my experience implementation, itself tends to be the easiest part. Once it passes QA and it's live for some time all bugs and improvements should be handled by the junior. That way they will learn from their own mistakes (again) and see what wasn't thought through.
Conclusion
If you went through all the steps kudos to you. You now no longer have a junior developer but you have a real teammate and maybe friend capable of doing almost any task product requires. It took a lot of time but think of it as an investment that will pay off. Your work is done. Well except that a new junior is joining next week ...
Discuss
Let me know what are your best tips, to introduce junior devs to your team? Or what would you like to be your introduction?
Top comments (0)