How to Mentor a Junior Developer

Question

This title is a little broad but I may need to give a little background before I can ask my question properly.

I know that similar questions have been asked here already. But in my case I'm not asking if I should be mentoring someone or if the person is a good fit for being a software developer. That is not my place to judge. I have not been asked outright, but it is apparent that myself and other fellow senior developers are to mentor the new developers that start here. I have no problem with this whatsoever and, in many cases, it lends me a fresh perspective on things and I end up learning in the process. Also, I remember how beneficial it was in the beginning of my career when someone would take some time to teach me something.

When I say "new developer" they could be anywhere from fresh out of college to having a year or two of experience.

Recently we've had people start here who seem to have an attitude toward development/programming which is different from my own and hard for me to reconcile; they extract just enough information to get the task done but not really learn from it. I find myself going over and over the same issues with them. I understand that part of this could be a personality thing, but I feel it's my job to do my best and push them out of the nest while they're under my wing, so to speak.

How can I impart just enough information so that they will learn but not give so much as to solve the problem for them?

Or perhaps:

What's the proper response to questions that are designed to take the path of least resistance and, in essence, force them to learn instead of take the easy way out?

These questions are probably more general teaching questions and don't have that much to do specifically with software development.

Note: I do not get a say in what tasks they are working on. Management doles the task out and it could be anything from a very simple bug fix to starting an entire application by themselves. While this is not ideal by any means and obviously presents its own gauntlet of challenges, I feel it's a topic best left for another question. So the best I can do is help them with the problem at hand and try to help them break it down into simpler problems and also check their commit logs and point out mistakes that they made.

My main objectives are to:

• Help them out and give them the tools they need to start becoming more self-reliant.
• Steer them in the right direction and break bad development habits early on.
• Lessen the amount of time I spend with them (the personality type described above tends to need much more one-on-one time and does not do well over IM or email. While that's generally fine, I can't always stop what I'm working on, break my stride, and help them debug an error on a moments notice; I have my own projects that need to get done).

Answer 1

There was once a question around here that contained this kind of information, and the piece that stuck with me the most was don't touch their keyboard

In short, tell your junior how to accomplish what they are trying to do, but do not do it for them.

But in addition to that, here are some other tips:

• Encourage Google (or any other search tool). If you know the answer can be found online easily, tell them to look it up instead of telling them the answer. Ultimately you want to teach them how to teach themselves, and not have them become dependent on you.
• Make yourself available to answer questions. If you are ever not available or do not wish to be interrupted, make it clear to them that they should hold their questions until a specified time.
• Do code reviews regularly to tell them what they are doing right/wrong. Use this as an opportunity to point out best practices
• Begin early with best practices. It's better to take extra time to teach them the right way, than to try and change their methods later on.
• Get them started early with planning/documentating what they are going to be doing instead of letting them begin by writing code.
• Be open to learning from them. They probably spend more time than you learning, and it's possible that they learn something that you didn't know.

• Help them learn from their mistakes. There are going to be mistakes, so be sure you show them that mistakes are part of learning, and that they should use them as an opportunity to learn.

• (From RuneFS below) Instead of telling them how to do something, try to help them figure it out themself. This will help improve their ability to logically work through a problem, and increases their learning ability

• (From RuneFS below) Instead of telling them what they did wrong, tell them of ways they can improve it. Be sure to include why your way is better than theirs. This will boost their confidence instead of weaken it. Of course, if they aren't listening to you then don't be afraid to just tell them to do it the right way :)

Answer 2

I have about 4 years of experience, and I can tell you from my experience as a junior developer what I wish I had in terms of mentoring. It seems that you are actually describing the type of developer I was when I started :)

Essentially you want to encourage them to learn. Some people think that after they are done with college, they don't have to read books or learn anymore. This kind of attitude can lead to looking for shortcuts and just "getting it done".
Get them "The Pragmatic Programmer" and have them read it. This book will help them realize that programming is a craft/career and not just a job. Recommend books for them to read every quarter or so. Help them build their "knowledge portfolio" (as mentioned in Pragmatic Programmer). I highly recommend Safari Books Online which has a lot of CS/Programming books.

With their knowledge portfolio, they will know where to look if they have issues. Teach them where to look. I myself discovered the usefulness of StackOverflow recently (and as you know, it's better looking here then just Google).

It looks like you can't spend a lot of time with them, but Pair Programming is very helpful. If you can't do that, then at least do code reviews using CodeCollaborator or another similar tool. They don't take as much time as you think they do.

Unit tests are very important as well. They can quickly reveal bad development practices, especially if you couple that with continuous integration.

Answer 3

Ask leading questions back to steer him to answers rather than simply telling him (well you can tell him some basic things like what the server name is and what database stores the information). Show him how to find his answers.

And never rewrite his code when it is wrong, tell him what is wrong and expect him to fix it. You get what you expect. You don't help anyone by making him dependant on you.

Code reviews are critical too. And if you pair program, let him have the keyboard frequently. Even if you are telling him what to type, he will learn from doing the typing more that he will learn just sitting next to you while you program.

Take some examples from the software that are typical of how the application is structured and go through them with him line by line making sure he understands why each line is needed and what it does. It is your job to ensure he knows the coding standards and how the code is organized and why you (as a company) do things the way you do.

If he has a different way to suggest, listen carefully. In the first place he may be right. In the second place, listening will tell you where his weakness in understanding are if what he suggests is not practical. Further, people tend to respect you more if you listen to them. When he is wrong, then back to the leading questions to get him to see for himself why the idea is wrong. IF he is even close to being right, go with his ideas sometimes, nothing is more discouraging than always being told that your ideas are worthless.

Ask questions about his background. He may know some things you haven't had a chance to work with. If so and the opportunity to use them comes up, ask him questions about his knowledge.

If your application is at all old, it probably has some sneaky "gotchas" than someone new won't have any way to know about. So when he is starting to work on an areas where you have one or more of these gotchas, you might tell him about them as he is getting up to speed before coding, then look to see if he fell into the gotcha when he coded.

Finally, you get respect in part by giving respect. Treat everyone you mentor respectfully. Don't make them feel belittled or stupid. They will listen to you alot better if you treat them with respect.

Answer 4

• I always make sure the developer wants my help, and I take great care not to go deeper into explanations than their patience can tolerate. Like everybody, I love the sound of my own voice!
• I treat them as equals, and make sure to ask their opinion as often as I sound off.
• Catch them doing something right and let them know.
• I always learn something when I do this right -- about my craft, about my profession, about the developer, and about teaching.
• The first lesson always is: when to know you've been trying it on your own too long. Many people take pride in finding their own answers, and burn valuable time going in circles.

Answer 5

I'm a junior developer and I think that my mentor deals with these things very well. Generally, he will tell me a couple of ways to do something, but not how to do it. Then I used to sit there and try out both ways, and decide which was the cleanest solution to the problem.

Also, if ever he was doing something that might be useful to me, he would call me over just to give a walk through of what he was doing and why.

This resulted in a small amount of time being spent with me and essentially meaning that I had to myself learn the right answers and how to implement things. Of course, if I ever get stuck he'd be there to help out but this was a handful of times. After only 5 months working with him I probably gained more knowledge of things than the whole of my university course.

The important thing to remember is that I am just an individual and this worked well for me because of how I am and how he is. It is about finding a suitable structure that will help both of you.

Answer 6

Depending on the task given, I'd be tempted to take a few different approaches:

• Ask them what would they try next to complete the task. This can give an idea of where from the "I don't know what to do" to "Well, I would try this but..." category are they in terms of having their own idea that may be useful for a starting point.

• Take a quick look at what they want to do and offer hints so that they figure out the problem. This is rather than give the answer of, "Just take out this line of code," suggest they look at what is there and is it all necessary.

• If the first couple aren't going to work, then I'd try to get them to follow my directions on what to do to resolve the issue. This is the next step in the progression where if they have no idea where to start and the hints don't work, this is the next point.

• Lastly, if nothing else works then I'd do the work for them but I'd try to avoid this as much as possible since this is how issues like one person intimately knowing a system get created as someone may take a view of offloading work onto me for this system that I seem to know so well.

Answer 7

One thing I've done here in my job that I found really useful was to setup a forum (i.e. PHPbb) for internal Q&A, and follow the rule that if the question and/or the answer takes more than 5 min, it should be asked and answered via the forum. The benefits:

• It forces the junior dev to state clearly the question, which makes it easier to answer, not to mention the times in which he finds the answer himself, just by thinking a little more about it
• It avoids duplicated questions, since the junior dev should start by searching for similar questions already made
• It helps in building a knowledge base that will be useful for future hires and for documenting many small things that could be lost in time.

Answer 8

I'm going to buck the trend here and suggest that you not try to encourage junior developers to learn how to find the answers themselves. This looks like a game of "I have it but I'm not going to give it to you."

Instead, pair up with them in finding the answer. You're going to google it anyway, so do it while sitting with them. They'll pick up that this is the way to find answers.

If you work closely with them, they'll pick up how to use the IDE properly; How to normalize a database; how to DRY out your code... whatever you know that is worth knowing.

The keys are: one - to make yourself available to them so they can see how you work. And two - to say out loud why you are doing what you are doing. "This code repeats itself, so I'm going to refactor it," not "use extract method on those three lines."

Answer 9

I have only ever had to train a junior programmer once. It was to help maintain a system I had built. The goal was to eventually hand the entire system off to him.

After a short period where he shadowed me, I threw him into the fire. I would assign cases to him, and expect them to be completed. If he had trouble, I would have him explain what the problem was, and where he had looked. I would then advise him in the most general terms, where to look next. (Which app, maybe which module to look at etc). I would never leave him floundering, but I also would never do any of the work. Only provide direction. If he still had trouble, I would just shrug my shoulders and say "Start tracing the code". And every time I said that, he would cringe - knowing he was in for a tedious exercise. It drove him nuts, because we both knew I could probably find the problem in 10 minutes if I would just get off my butt and help.

Years later, he has moved on to bigger things and now he's training his own juniors. And his favorite story is how I would always tell him to "trace the code", and how those code tracing exercises were crucial to making him the programmer that he is today.

Answer 10

Whenever I am asked a question that I know can be resolved by a quick Google search, I will find documentation or a relative article and relay that to the person asking the question.

Knowing where to look things up is an important skill, and it is sometimes more difficult than you'd think for a new developer. They may not even know what they are looking for, and this is where you need to help them.

Once in their hand, articles and documentation will force them to read about the solution instead of clawing at other developers for a quick answer.

This will accomplish the following:

• Taking some of the burden off of seasoned developers.
• Forcing the new developer to learn.
• Happiness for all.

Sometimes you just have to give them some tough love, especially if they don't seem as if they want to learn. Don't give them the answer, but make sure you point them in the right direction.

Answer 11

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.

Answer 12

I've taught people various subjects in the past, and the thing that has most struck me is how most people do not have any problem solving skills. That is, if you show them an exact solution, then they are able to reuse it later if they recognize or are told they need it.

But, very few situations in life are like that. Unless your job is a "mental factory" involving sticking widget A to widget B with tool C, then you will need to have a couple of items:

• A toolbox of skills and tools
• A problem solving method

For example, take a look at this answer I posted. That covers the problem solving method that many people do not have. College did not teach this to anyone in the CompSci program, you either already knew or figured it out yourself.

Once the junior dev understand how to go about solving problems, they need a set of tools with which to do so.

• Debugger (College never mentioned this)
• Profilers
• Text editor
• Shell (and associated utils)
• Resources (books, google, SO, manpages)

Determine what is lacking for the junior dev, and you can help them improve. Just be aware that some people really aren't interested in learning how to solve their own problems and just want an "obvious step by step" solution handed to them. These are not good developers.

Hopefully, you won't have any of those. If you do, realize that no matter how much time you spend, they won't every help themselves. It would require effort, and it is easier to just ask you to do it for them. It's similar to the welfare problem, and explained by economic theory.

Enlightened self interest says people will take what they view as the most advantageous option in any given situation. Notice that it is what they view. I see the most important thing as being self sufficient and learning. So, I do things myself. But others may see that they just need to provide working code by the deadline. So they look for the least costly method of doing so. By providing them with "freebies" they need outlay the smallest effort to complete their objective. Until you remove that crutch, they will not grow.

Answer 13

Your organisation as you describe it is very different from mine. I am in contol of my juniors work, and I do see it as my role to judge. So a lot is different.

One thing that I'd like to advise you to do anyway, is to frequently visit their desk in the first two weeks especcially. Something like three times a day the first week, gradually decreasing.

The message I try to send this way is that I care about their productivity. I make sure they dont get stuck. I ensure they follow the rules, and don't reinvent the wheel. I teach them to commit as often as possible. Learn them to develop incrementally, and think about design incrementally.

My worst nightmare are developers that each day tell you that they need just one more day to get their feature done. After weeks delay, you get an overcomplicated design, which is hacked from the start by its author. Extra unrequested buggy features, are thrown in the mix to compensate for the delay, and because they were a free side effect of the design.

I believe that many developers are inclined to this approach. If you're left on your own with a compex task, it is a natural reaction to try to prove you can do it on your own. But it is the wrong response. Quality is teamwork, and the sooner they learn, the better.

Answer 14

The other answers are very good, but I wanted to comment on this one sentence.

Recently and in the past we've had people start here who seem to have an attitude toward development/programming which is different from mine and hard for me to reconcile; they seem to extract just enough information to get the task done but not really learn from it.

Most people want to know how to do something. This attitude is fine in the beginning when you're overwhelmed with learning new things and learning how to do your job.

Rare are the people that want to know why something is done. These are the people that smart managers want, even if they are hard to manage at times.

Some people code to get paid well. Others happily accept money for coding. It's much nicer to work with people that have a passion for design and coding. Unfortunately for me, it was also pretty rare. At least until I found Stack Overflow.

Answer 15

A thing to watch out for, for those getting excited at the prospect of doing all this mentoring for junior developers: make sure your management understands what's going on.

Teaching other people is hard work, in general. It takes focus and concentration, planning and effort, and most of all it takes time. Whatever approach you take, if you're teaching and mentoring in any serious fashion it's going to be eating into your time.

• If your management hires less-experienced developers with the expectation that senior developers will take on training duties, make sure that's explicit. Find out what the time frame will be and make sure that your development schedules reflect the time and effort spent on training. Make sure management has some plans for evaluating the success of the mentoring efforts at some agreed-upon time(s). (Of course, if they're hiring developers that need teaching and mentoring, but management is not planning for it, then that's obviously a serious problem.)

• Not everybody is a good teacher or mentor, and not everybody wants to be. I don't mean to sound crusty or bitter; I like teaching, a lot. But it's silly to expect that everybody's going to be good at it (despite their own talents), nor can we expect everyone to enjoy the process (remember, it's not easy). Furthermore, if you're a senior developer who does not enjoy mentoring, or if you really feel you're a poor choice for a teacher or mentor, make sure your management understands that a plan involving you doing those duties is a plan with a serious flaw. On the other hand, if you want to become good at teaching or mentoring, that's something to communicate as well.

• If teaching and mentoring are burdens shared unevenly across the population of senior developers, make sure that those assignments are recognized as valuable to the company in the same way that product development achievements are recognized.

Answer 16

I'll give you my look on it.

Basically, I learn well when I:

1. Am given a formal introduction to the topic. I can never learn something new without somebody (yes, a person) answering all of the questions I have on the new concepts. Once I have that done I...
2. Get a book. As my mentor, you should have the exact same book so I could always say something like, "Hey, what does that mean in chapter four, page 72, paragraph 6..." and you'll know exactly what I'm talking about. Once I have a book, I am more independent, and really only ask questions. Then I...
3. Start a project together. This is the most important part of the process. This is where you can start teaching me about Best Practices, Algorithms, difficult (but useful) language features, etc..

Now you had said that you have your own projects to take care of, and that you don't always have the time. That's why we were blessed with StackOverflow. I'm sure they would be happy to help him debug his code. As for questions that aren't on-topic there, he can ask here.

With that said, you still have to work with him on a regular basis. A general "timeline" should be:

• 1 month. Should know basic syntax. Still not independent when coding.
• 3 months. At this point he should know the syntax like the back of his hand, and should be able to solve simple problems with ease. He is much more independent, just not quite there yet.
• 6 months. They should know, on top of everything else: Best Practices, Common Algorithms, etc. He should be able to make a project himself, maybe with a bit of help from SO.

---

Besides the above, the easiest way to make somebody independent is to give them a difficult topic to learn, and give them nothing to help them but the internet. He will be forced to learn by himself and he will know his stuff.

After he knows what you want him to know, set him free. Allow him to go off and learn what he wants to learn (you could always say you want him to keep working in that language).

I hope this helps! By the way, let him read this: Teach Yourself Programming in Ten Years.

Answer 17

Make a distinction between lower and higher levels of learning. If it's knowledge, comprehension, or application related, I have no problems just straight out giving them the answer, with a brief explanation of how they can look it up next time. This isn't school, it isn't cheating, and they won't rely on you that way forever. Just don't plan on getting anything else done for the first week or two, so it won't annoy you when you don't.

After the first couple weeks, if you get interrupted too often with these kinds of questions, use a pomodoro timer and don't answer any questions until the end of a pomodoro. Google is easy for you now because you know what to search for. They often don't, so if you must tell them to google something, tell them what search terms to use that will get the best results.

If a problem is related to analysis, synthesis, or evaluation, I spend more time on the topic. This is where you provide your reasoning behind your decisions and help them reach the same conclusions. This comes up most often in matters of design and style. Don't just tell them to use a certain design, show them why it's superior to their first choice. Let them make mistakes, and let them fix their own mistakes.

Answer 18

I have not seen anyone here mentioning my personal hero, Randy Pausch.

I think it can be beneficial for anyone actually doing, teaching or mentoring programming (or even for anyone who want to live a meaningful life). You and/or your colleagues might find watching these lectures worth the time as I have, on

• achieving your dreams (he WAS a professor and this is heavily related to motivating others), and
• time management.

Answer 19

I, as a junior developer feel that if I come across an issue would be better put getting the answer straight away and spending time understanding how it was solved.

Im paid. my employer doesnt expect to pay me for learning. im expected to do a job at the end of the day. No point wasting time in a working enviroment try to discover a solution. Thats something I will pick up in time, hopefully quickly if im any good at what I do.