How to mentor a junior programmer

Question

Does anyone have any suggestions on how to mentor a junior programmer ? If you have mentored someone did you follow any process or was it quite informal ?

If you've been mentored in the past what kind of things did you find most helpful ?

Answer 1

Try to set aside between 30-60 minutes a day to review their code together. If you can't do this, then try to get together to review their code whenever they make a code commit, unless it was very basic. Have them explain why they chose the approach they took in lieu of others. A process like this helps to establish a great relationship, as well as really stimulate the student to think on their own and be able to defend their decisions. Not only does the student end up with someone approachable whom they can trust, but you'll notice an improvement in their quality of code and logic almost immediately.

Edit: Also, If you are unable to commit this much time to co-review with your junior, then you probably shouldn't be mentoring them and instead see if anyone else has a schedule that would allow it. The whole point of mentoring is to actively aid in the professional development of the student, and they're not going to learn much if proper attention and guidance is not given to them.

Answer 2

I'd be the junior, I guess :) I think I'd value an informal approach. It probably depends a lot on your and your mentee's characters, but I'd say that you learn best if you don't have egos in the way. Break the ice, make sure there's feedback in both directions. Things like code reviewing (both ways?) and occasional pair programming may work, and if there's a good match, it may be a lot of fun, as well!

Answer 3

This question is probably a dupe of this thread.

Mentoring a junior coder is quite a bit different from teaching a complete newbie. Not a dupe.

Answer 4

I have mentored several junior people under me before. My approach varied slightly based on the person a bit based on how they learned.

In short, I gave the junior people small, self-contained projects when I could and gave them a relatively fixed time to complete the task. Once the task was complete I would review their approach, code and solution and made suggestions for improvements or a better way to handle the problem. I think this way they don't feel overwhelmed being part of a much larger project.

Hope this helps a bit.

Answer 5

I had the change of working as an intern (one of two) in a small software company and got the chance of working on a "almost new" project they had. They had me set up with everything needed and gave me an introduction of what the project actually was (basic stuff like what the requirements were etc).

at first we got to do minor tasks like researching things that mattered to the project (they had given us a list of things). This was, I think, to see how much we could handle ourselves, as the things we needed to look up and research were not that trivial and it took a good 2 weeks or so (counting the basic demos we had to create for it). That testing phase was actually done really without much 'coaching'.

However after that period we could work on the actual project itself. This was also the moment we were coached together, almost in a similar style as pair programming, except there were tree of us (2 interns and 1 'coach').

We learned a lot from him, but it was in an informal manner, and he didn't act like the 'all knowing listen to me' guy. When we had suggestions he would listen and think with us if it was any good. or give his meaning on why that should not be done in that way... now that I think of it, he actively encouraged us to make suggestions, and to think about better ways to do things, instead of just sitting there 'taking orders' from someone who probably know it better then you.

So in short:

• Let him work (mostly) on his own to study the materials at hand, give him a list of minor TODO things like looking up information, or building small demo's
• check the work he has done regulary and advice him if there are better ways to do things, also show him the items he actually did nicely, that way he'll remember those for later
• Let him work on a real project, and mentor him by working together at the same project, giving him advice when he has questions
• the effort has to come from both directions: encourage him to ask questions, to challenge 'the way it is currently done', ask him questions on how he thinks it should be done and give him your opinion as well.
• make it 'enjoyable', don't let it look like you are giving orders

Answer 6

I would recommend start giving parts of real assignments you have and make everything to be able to use his code. In other words train him as replacement for yourself.

This way you will commit yourself to allocating time to work with junior and he will be able to see "real life". By working on real assignments and hearing lively feedback he will be able to get p to speed rather quickly.

Drawback of this approach is that it is possible that it will have too narrow focus on you particular project. So be sure to show the trainee possible alternatives and encourage trade-offs analysis to widen his professional horizon.

Answer 7

Couple of years ago I worked for a small company, where on the first day I was given a list of small task to complete - do some little changes in code, find and fix a small bug in the project. It really helped me to ask the right questions from my mentor and familiarize myself with the environment, the code base. These tasks were easy to complete, so I had a little bit of self confidence, before turning to the bigger tasks.

This way of mentoring really worked with me very well, so I am planning to do the same with our new colleague.

Answer 8

During an internship w/ a large company that had a lot of in house IT, I was paired w/ a mentor. The practice definitely aided my career development, both in terms of technical skills and business skills. Here are some of the reasons the mentoring worked out so well:

• Credible: The mentor had 8+ years of experience and an accomplished background to draw upon in leading and training. He'd been through different challenges, worked in different environments, so he had a great perspective.
• Genuine: The mentorship was encouraged by the supervisor, but not so formal as to make it an exercise in going through the motions. The mentor wanted to mentor, and I wanted someone to learn from.
• Passion: The mentor loved the field he was in, the problems he was solving, and the technologies he was using. When I came under his wing, I found this to be infectious.
• Sharp and Articulate: The mentor approached issues critically and framed them concisely. There wasn't a lot of fuzziness in our discussions; we got to the root of the matter and he directed me on wise courses of problem solving and action.
• Meaningful: The work I was doing w/ the mentor was meaningful work, not just an exercise to keep busy or ramp up in a skill set. By jointly working on a task that tangibly aided the organization, that helped focus my interest and legitimize the mentoring process.

Answer 9

Because I had to explain why I wanted to co-op (besides needing the money) during my interview, my manager made sure my first project allowed me to work on what I had identified as weak areas: very little Linux experience (I chose a Linux-only R&D team so I would be forced to learn), not knowing a useful text editor (I really wanted to learn Vim), and how to learn another programming language (very different approach than learning a language as you learn to program). He told me I was being paid to study for a while.

I learn best by reading books, so after chuckling over Unix for Dummies (yay! I wasn't the only one who thought this was obscure and knuckleheaded sometimes) I started with Unix in a Nutshell and Sobell's Practical Guide to Linux Commands. After that I printed out the Vim documentation and started going through it. Then I looked through a couple books on Python, the language of my first project. I was given all the time I needed to feel comfortable about these things (which was the real problem, as I now understand) and then began adding functionality to a previous co-op's project.

I realize now it would have been terrific to meet with someone every day or two for code review, as Kamikaze Mercenary said.

Answer 10

Here would be my short list:

Pair programming - This is helpful for many things, like reinforcing various ideas and practices. Getting used to Resharper is much easier when you pair with someone that uses it often.

Informal chats - This is where we would go get a drink, go outside for someone to have a smoke break, go for lunch together, etc. While away from the desks, the discussion may be related to work immediately being done or it may be abstract philosophical stuff that can help bring someone's game up a notch or two. Talking about various upcoming technologies or changes in what coming can be exciting and help form bonds as well.

Feedback and suggestions - This is what occured in both above cases. Books like "How to Win Friends and Influence People" by Dale Carnegie can help in understanding various human relationship dynamics, which while that sounds quite technical is really just about how to motivate someone else in various ways. A key point here is to know how to leave a trail of breadcrumbs to pick up some practices, like giving hint after hint about something rather than just give the answer. I have had various Math teachers that had a gift for this for how I developed some of this skill.

So part of this is merely motivating the other person and trying to guide them as when someone figures something out for themself it can be an empowering and enlightening experience. The, "I did it! That's right, moi, yours truly!" kind of self-talk is quite nice when it happens.

Answer 11

In my experience when mentoring someone it is very important for the mentoree to really WANT to learn more.

Never ever spoon feed them. Instead point them towards things of value and have them utilize the new information they are learning in projects that they are using. Knowledge is useless if not put into practice. So encourage your mentoree to code, code, code.

Answer 12

At my first place of employment there was this really patient dude that would always help me solve my immediate problem, and then teach me some important underlying principle. I loved this because he would help me stay productive while teaching me how to become a better programmer.