Passing on your knowledge has the potential to provide more value than actually writing code. Smart companies know this and reward it.
Mentoring can have a huge impact on the world. It creates a ripple effect, where you influence someone's mental models and approaches to code in the years to come.
You become a better developer, and your understanding deepens as you learn to articulate topics well.
Mentoring is about empathy and clarity. A mentor acts as a guide and provides support so the junior can focus and learn.
Roles
The terms junior and senior are thrown around a lot these days, but they continue to be fuzzy.
We're going to assume for this article that the mentor is a senior developer and the one being mentored is a junior. Let's explore what the differences are between them.
Junior
At this stage a developer learns about the pieces so they can form a bigger picture over time.
It's impossible to take it all in at once, so it's important for a junior developer to have focus. There's a danger of jumping from one thing to the next without understanding how that thing connects to the whole.
Senior
The senior role implies technical knowledge, but this is not the defining characteristic.
Seniors have experience to draw analogies from. A senior developer understands how a decision today can affect a project or the entire company in the future.
A defining trait for a senior developer is security in their lack of knowledge. They are willing to ask questions, and experience gives them realistic confidence in their ability to figure something out.
They have picked up meta skills along the way that make them adaptable. They know how to get themselves unstuck. They can impart this wisdom because they have walked the path themselves.
Onboarding
Starting out in a new codebase or company can be exciting and scary. Understand how overwhelming it can be for a junior in the beginning.
Start with the broadest information and slowly work your way down. Make it clear there's no need to understand every little thing in the beginning.
This is the tech stack we work with, these are some of our repositories, this is our folder structure...
There is a lot that the junior has to absorb, so documentation should be easily referenced and accessible. Project README files are a great place for project-specific information.
Many open source projects will use the good first issue tag on GitHub for first-time contributors. These are tasks that are not too complex and ideal to familiarise oneself with the codebase.
Start with these kinds of small tasks and celebrate small wins. Ease the junior into reading and writing code.
Teach
The priority for a junior is focus. If you find a potential 'teachable moment', pause and question whether it's beneficial for them to learn this right now.
It's okay to gloss over something and come back to it later when it's relevant. Practice just-in-time teaching, and the junior will be able to apply the knowledge.
Check in with the junior to see how confident they feel about a particular topic.
Don't overwhelm them with unnecessary implementation details, but don't exclude crucial pieces that are necessary to understand. There's a balance in finding the right level of abstraction.
Everyone is different and not everyone learns the same way. Gather feedback on what's working and what isn't. Many people struggle to understand a theoretical concept until it is applied, so provide ways for the junior to practice what they've learnt.
Peer code and work through tasks together. Small habits that you may not think to point out explicitly are shown — things like keyboard shortcuts, git commands and editor extensions.
Explain your reasoning as you go and don't be afraid to look things up and debug. This is a part of the job and immensely valuable for a junior to see.
A junior should ask for help and describe what they've tried once they've spent time on the problem themselves. A little bit of struggle is a part of learning, but not so much that they feel helpless.
Small wins and guard rails are great in the beginning, but step back and provide more independence as the junior starts to get the hang of things.
Review
Reviews put things in perspective. They are a chance to reflect on what's been learnt, and refine processes going forward.
Plan one-on-one meetings sometimes. Ask the junior how they think you could improve, or if there is anything you can do to help them.
Code reviews encourage communication. Cultivate a healthy feedback cycle as part of your flow. Have your code reviewed by the junior if it's within their grasp and relevant to their current focus. Be prepared to explain why you did something a certain way.
Consider how you manage your time. Batch it so that you can get your own work done, along with focused sessions with the junior.
They can prepare things to go through together at your next meeting. This gives the junior time to get themselves unstuck, and to articulate the problem well if they do need help.
You don't have to wait for permission to mentor others. Leave breadcrumbs to help other motivated people walk the path.
If you have struggled with something, others will too. Leave a comment on a GitHub issue, or write a blog post about it.
A powerful way to learn is to lend a helping hand to those who are just behind you on their journey.
Passing on knowledge brings value not only to juniors, seniors, and companies, but ultimately — to the entire community
Top comments (5)
This was a good read. I learned about being the junior and senior both.
The best part:
"A junior should ask for help and describe what they've tried once they've spent time on the problem themselves"
Glad you liked this part!
The senior is there to guide the junior to a solution on their own, rather than provide it for them. This approach helps the junior the most in the long run.
These points are good!
Thanks for reading, Andrew!