Mentoring as an activity is something which happened naturally in all the companies I have worked at; and it was often a two-way approach. Well, "mentoring" here would be a misnomer ... mentoring through code-reviews is what I precisely went through!
However, the position that our team is in, we have junior developers who need a lot of mentoring to pick up pace, so to say!
In this regard, I would be grateful to hear from the fine folks here; the strategies/processes which (you follow | you have followed | have helped you), for mentoring junior software developers!
I've been in a company that did this for years (I still do it with my current company!). I'll talk about my previous company as I stayed there for five years first as a mid-level and moved on to be a senior.
I learned from my boss who was a great programmer. We pair programmed almost 100% of the time and suffice to say, I learned A LOT in a short span of time. I leveled up my skills just by being with him - I began to think like him, to think of solutions like him and to debug like him. This is the number one thing that helped me understand and learn a lot of things.
Fast forward a couple of years later, our country had a shortage of Ruby developers and we needed more. By shortage I mean there were only atm ost 20 people attending the meetups and most of them had jobs already. My boss then thought of training students, juniors and even seniors in other languages so that's what we did. Since we were a pair programming company, every Ruby senior paired with a beginner or intermediate person to pass on the knowledge. This is the key thing: pair programming made you BOTH focus on the task at hand, and it was also an exercise of learning for both the senior and the student.
In some cases, we also hired interns. Now with the company at full capacity, we 'bootstrapped' interns by 'shadowing'. Interns would join a pair and watch behind them. They were not to be ignored, they can join in the discussion and offer solutions, ask questions etc. While this slowed the teams down a bit, it was an investment of time and effort.
Soon, these interns moved on to become juniors, mid-level developers, and seniors. Up until now, this 'developer ecosystem' is still thriving in my country and by my estimate, there are about 150-200 Ruby developers now.
I work for a small firm now (7 people altogether), so letʼs take a step back.
In my previous position I quickly became the “Git goto guy”. It was a multinational corporation figuring out how to switch from their proprietary version control system to Git, and even though the Hungarian division didnʼt have much to say, my words found listening ears.
So what I did was accepting every mail and chat message related to Git and tried to answer them as soon as possible. As there were still a lot of concerns after this, me and some team leaders organised training sessions where I taught about everything, and also answering the questions.
It wasnʼt organised mentoring per se (which also existed within the company, but I wasnʼt eligible as I was an outsourced worker), but worked really well. The secret was the same as building your own brand: have your opinion, spread your opinion, and dare to change if your opinion is not popular.
Mentoring is not teaching. This is improving. If a person knows Javascript and works with me, I would ask him to go through existing codebase and analyse how code is written against his current code. This will improve his code but will improve the overall codebase as eventually he has to start merging his code into working codebase.
Will ask him to do a lot of online coding puzzles not to learn the coding logic only but to learn to manage time. The problem with most new guys are they don't value time. They need to work within time. I see a lot of them stay late at night and finish things but can do the same without staying late. I believe in writing clean code and if my code-review tool says otherwise, I will not merge the code. Even if that means weeks of his work. In the end we need to enforce such things for better code instead of giving in for such short time pressures.
Lot more can be done, but I just mentioned few that I deemed as important.
I work as an individual, so there isn't a very big team dynamic, but mentoring is still vey important.
Ways I've been mentored:
found a code golfer who was sharing his amazing code on Hacker News, we collaborated on some projects together, and have been part of the growing JS code golf community. He had been mentored before I showed up by another programmer, and in theory I should be turning around and mentoring a new golfer sometime now :D
I know HTML and CSS pretty well, so I hopped onto IRC to see if I could chat and help anybody on there. I have been able to help a lot of people, but I've also found some really caring people who can help answer my questions too, usually about programming. Yesterday one of them took the time to write out a library pattern for me in about 3 different ways until I understood it and I was able to write the code I was trying to write in a better way. I'll make sure to keep helping people in a similar way who have questions I can answer.
I know quite a few designers and developers here in Toronto. We all have very overlapping skill sets, but that also means that we know things that the others don't know. I have been able to "Let me show you this one thing really quick" to show them a tool, technique, or idea - and they're smart enough to see it, understand it, and know how to put it to use. I don't think of them as my 'students', but those little moments are undeniably mentoring in action, just between peers.
So I don't think you need a super formal process, and I don't think it's hard to get started - but I do think it's sorely needed.
Basically everybody should be a mentor. If you're on a learning journey and you've taken a few steps from the starting line, that means already there will be plenty of beginners behind you on the same learning path that you can help, even if you haven't reached 'mastery' yet.
I usually spend some time giving broad overviews and then leave my door open for any lingering questions. There are no stupid questions during onboarding.
If I had formal responsibility for the junior developer then I'd set up some achievements
and monitor the progress
In general I try to teach how to fish rather than provide sushi.
However, the position that our team is in, we have junior developers who need a lot of mentoring to pick up pace, so to say!
Business is NOT a school
Private coding schools/bootcamps/online programs exist for that. If person needs to pick up a lot, how this person ended up in your business on the first place? It's called interns not jr.
Mentoring = coaching = teaching = internship
You need a program (curriculum) tailored to a specific student and a plan. What are lowest requirements, what student knows and what are your goals, what should they know and be able to do at the end? Have a clear definition and answers to all questions.
Before teaching someone else - teach yourself
Are you a right person to teach? Are you both a professional software engineer and a teacher? If no, it is better to spend your money not on paying them salaries and wasting your expensive time, but paying for their education. Let someone else do this job and you will get a valuable asset at the end.
1. Bring ONLY right people to the team
You need people who are adults and independent, who can learn on their own very fast and not follow your rules waiting for your orders. I don't have students in a business and whenever I have juniors to mentor, I bring only those who know the basics, have discipline, are extremely hungry and foolish, who will keep learning and moving forward with me or without me. I will be just there to help them achieve their OWN goal faster.
NEVER invest your time and never surround yourself with people who are not aligned with your values and don't want to move forward on their own, who DON'T have personal goals. Don't be desperate and don't just bring people into the team only because you "need some help". You can wait and keep searching for a right person.
All top bootcamps have a strong selection process. Real business is not an exception.
2. Natural selection - test as many people as possible and winner will pick himself
Be a cheap date - test as many people as possible as fast as possible. You don't need to offer them a job, bring them to your community, add them to some of your private Slack channels, give them some test tasks and learning tasks and just follow them, see what they are doing and how active they are, and how do they progress. At the end strongest survives and you just pick the winner.
Time to times I just send them some blog posts and video tutorials or talks and later just ask them about what have they learned (Sometimes I didn't had a time to watch specific video or read an article myself, so it is a win-win, I save a lot of time and get a short summary at the end)
P.S.
How Great leaders inspire action? - Simon Sinek - TED
You can read different blogs from different online educational platforms or bootcamps like Flatiron School to get some more insights.
Well I personally found the talk of Dan North very inspiring youtu.be/lvs7VEsQzKY
Esp the dreyfus learning model.
Beginner need rules, they are not as fast it is natural. Hence style-guides, code-reviews and less freedom is important; at least from a business perspective.
They need clear instructions what they should do, how they should do it and why they should do it like this.
There is nothing worse than giving a beginner ultimate freedom. That's the paradox thing about learning ... you need to force them to learn things so they can be free.
So if I assume what I've written is a truth we could draw one possible conclusion:
With every beginner we trade our current velocity with our future velocity like and additive vector (I know it's overly simplified). So the more we invest now in our beginners the faster we loose the drag of them and the more and faster we can achieve things in the future.
This is basically how I see new people, I won't sidetrack into business needs and these factors but fokus on where are we as a team and where do we want to be.
So basically what you need is one person who is really okay at coding one who knows the rules and lives them by heart. That is the person you should pair your beginner with.
I also do recommend collective code reviews where more advanced coders talk about code and their reasoning.
Demanding to explain the why and how.
Show them your thinking process but don't do in code, do it abstract. train their puzzle solving strategies.
Do small hacking challenges during the day -> 9 am -> 15 minutes we all solve one small algorithmic problem. After that we present it. It should not be to long.
Give positive feed for good things.
Do stuff together outside of work ;) trust needs to built and goes both ways.
I personally plan a little hacking retreat for a weekend with food and drinks. Just some extra team building and I hope they like it.
Anyhow this is as far as I got with my current strategies for beginners till intermediate.
My experience from a place with a lot of junior developers:
It is going to take quite some time, which is the price you pay for hiring less experienced people. I imagine it's a new positive, but I've not seen the numbers.
In my experience, a lot of the questions are about the product rather than technical details.
People don't ask me many questions though, so maybe I'm not the perfect person to answer...
Amith Gotamey
Developer