On my team, we often require the most senior programmers to train/mentor the brand new junior programmers. However, these same senior programmers are the ones who are doing the bulk of the real, important work.

I've tried to argue to my manager that it makes sense to have the junior programmers, who are showing a high aptitude, take the new programmers under their wing. First off, it will free up the senior developers to work on more important initiatives (not that mentoring isn't important). Next, it will give the junior programmers a bit of pride in their job that they would be looked to for such a responsibility and they may learn something in teaching. Finally, it will save the company money, as senior developers cost a great deal more than juniors.

My boss has failed to be persuaded since this is how it has worked on this team since the beginning of time, apparently. Assuming that the decision has been made that some sort of training/mentoring is mandatory, can anyone provide me with some better arguments or tell me why I am wrong? What does your team do?

**We can all agree that seniority does not necessarily denote competence so just assume by "senior programmers" i mean "top programmers".

  • 1
    I wish I would have worded this question as "Top Programmers vs Intermediate to Mid-Level Programmers". Some great answers though. – smp7d Nov 10 '11 at 21:53
  • You can edit it you know... – ChrisF Nov 10 '11 at 22:04
  • ha, wouldn't be fair to those who have answered already. – smp7d Nov 10 '11 at 22:06
  • I thought you were talking about the title... – ChrisF Nov 10 '11 at 22:06
  • Well if they always did it that way it must be the right way to do things. – SoylentGray Nov 10 '11 at 22:07

10 Answers 10


I had this situation at a previous company. The senior developers, which were only a few, were mentoring an increasing number of junior developers to the point where they could not do the other tasks assigned to them. After a while the senior developers brought it up with our manager and it was decided that the developers who were somewhere in between junior and senior would act as mentors but for difficult issues they could go ask the senior developers.

It worked out pretty well. Before that, a few of the senior developers were starting to look for new jobs because they were not being challenged at work. After, they were able to work on new features and get stuff done. What do your senior developers think of the situation?

In my view, being senior is not just about expertise in the domain, the title in your email footer or for how long you have worked. It's also a mindset, to help and guide junior developers. And what better way to get more senior developers in a team than letting the not so senior do the mentoring?

| improve this answer | |
  • 2
    this sounds very similar my current situation. – smp7d Nov 10 '11 at 22:07

Not every top programmer is a top teacher. I would recommend to make the training by somebody who can explain and who has an overview on the 'environment' of your company (technical things, but also organizational like contacts).

| improve this answer | |
  • definitely true, but the right question may be "do these technically great seniors even try to be more supportive and to teach less experienced?". I think they are missing an important part of the job. nobody became a senior by themselves, I guess. – zeroDivider Jun 18 '19 at 7:45

I'm reiterating some of the things that have been said already but I have two views.

Business: As a business, you want productivity and lower risks. Although senior developers are doing the bulk of the work, you want them to transfer their knowledge of the system down which lowers risk. Productivity wouldn't be affected that much because you need to give these seniors some rest time to do less critical things (teaching junior devs). Aside from systems, they also have many disciplines that junior devs do not yet know or grasp.

Respect: Juniors taking new developers under their wing is kind of like the blind leading the blind. Juniors are not yet up-to-speed with everything to be in charged of teaching others. Also, it might not work out because the respect may not be there. Respect towards the junior developer is in question because your skill set vs the beginner's skill set is probably not that far off. Tackling a problem together is a different story though. There is no question of respect in terms of senior devs teaching beginners or even juniors. We all know that when respect is lacking in two individuals or in a team, disaster is waiting to happen...

| improve this answer | |

Look at this from another angle. What kinds of skills and knowledge are you wanting to have transferred amongst the programmers here? If the senior programmers are doing most of the real, important work doesn't this maintain a bit of isolation in terms of who knows which system? Getting the juniors in to know the system so that they can be backups for the senior is a rather logical direction to take as it is that senior knowledge of potentially years of built up knowledge getting passed along that is the most important here. Seniors mentoring juniors does seem like a kind of natural formation to my mind.

A junior programmer mentoring another junior programmer doesn't quite make sense to my mind. Pairing a couple of junior programmers together though could make sense in a way. In having a couple of people work together on a task so that it isn't just one person's idea can be quite useful as well as help foster a more collaborative environment where a team pulls together in a sense. Depending on the environment you have this may or may not make a lot of sense to do.

| improve this answer | |

Well if the senior programmers in the team don't really master their trade more than the juniors, only have been around longer and/or have a higher social/political status within the team, then indeed it doesn't really make a big difference who - if anyone - mentors the newcomers. Chances are, they will all gravitate towards the same level of mediocrity anyway... :-(

If, OTOH, a senior is really (at least noticeably closer to) a master programmer in the true sense of the world, it can make a big difference. A junior may easily teach not-so-best practices to the new kid on the block. And it is much more difficult to unlearn a suboptimal or bad approach later, than to start by learning the best practice.

That said, if a junior has the talent, and has reliably demonstrated that (s)he knows what (s)he is doing regarding a certain tool, technique or area, (s)he can indeed be a useful trainer on that specific area.

But note that - from a certain point of view - the whole point of mentoring/training is to enable seniors to delegate some of their not-so-challenging tasks to others, so that they can focus on the really tough stuff. For this to happen, they need to actually teach those tasks and skills to their peers first, and teach them well, so that the tasks are taken over properly, once and for all.

| improve this answer | |

Simple answer: the person who does the training should be the person who is best at training who also wants to do training.

Some people enjoy training and mentoring. Some people hate it. You don't want people doing things they hate - it's bad for them, it's likely bad for the person being trained, and it's probably bad for the whole team. It doesn't add anything. Meanwhile, letting people do what they enjoy is good for them, the team, and hopefully the trainee will catch some enthusiasm.

Similarly, some people are good at training and some people are not. There's a type of human interaction or intelligence that allows some people to be good at understanding how others tick; a trainer should be able to deliver knowledge in a way that the trainee will understand. A good trainer can do this, and can learn that the trainee likes to 'understand' things, or 'see' things, or 'do' things - the various ways that people learn. A bad trainer delivers a rehearsed speech and is inflexible, and will get frustrated when the trainee doesn't catch on to their idiosyncratic ways of learning.

I assume you want the trainees to get the best training - thorough yet efficient. If your 'top programmers' are keen to train then they should do it. If the 'junior programmers' are up to it then they should have a shot, too. It doesn't hurt to have a few people participate in the training program - that way you can determine who wants to train, and who is good at training.

I'm not sure from your question whether you're a senior programmer who wants to get out of training (no criticism - you've got more important things to do, or just don't love it), or a junior programmer who wants to get in to it. But either way, you're trying to do what you enjoy - and don't we all want to do the tasks we enjoy? Happy employees leads to better work environments and better output.

| improve this answer | |

In most companies I have worked in, a Junior programmer was someone with less than 3 years experience. Whilst I would be happy, as an experienced programmer with mentoring experience to refer a new programmer to a junior programmer for training on a particular topic, I would want to retain control, rather than to delegate all mentoring responsibility to someone who still needs mentoring supervision themselves.

| improve this answer | |

I've found that things like the business rules and design guidelines are the most critical things that a more senior programmer has to be able to pass on to junior developers or even newly hired senior/expert developers or contractors. Problems tend to come up when this key information is hoarded or never explained. Perhaps this is what your manager is concerned about more than actual programming knowledge.

As for programming knowledge itself, that is best passed around the group at all levels. Even experienced programmers learn new stuff all the time, especially in complex development frameworks. This sharing can be formal, as in a lunch-and-learn session, or through informal discussions when time permits.

| improve this answer | |

I would opt for mentors primarily being a step or two below the top programmers in the organization.

While you've given some good reasons for that, I'd point out one more that I think is particularly important: teaching is one of the best ways of learning, especially learning enough more to make some of those last steps up from really good to great. One particularly important part of this is learning to not only do things well, but do a good job of articulating what you're doing and why. I, for one, have frequently found that to do a good job of explaining why I'm doing something in a particular way, I have to sit back and think about it enough that 1) my own understanding improves considerably, and 2) I often reevaluate the situation enough to improve my own work.

Although it may well be more difficult for them to do it, this can be particularly helpful for programmers whose social skills may be somewhat...lacking compared to their peers. Pushing them a bit out of their comfort zone from pure coding into more social aspects like mentoring may help them as much as the people they mentor. Obviously if you're going to do that, though, you need to be particularly careful about choosing who to pair together -- the wrong pairing could end up hurting both of them.

| improve this answer | |

I think it works out best when the mentors volunteer for the task. Around here, we don't have a very formal mentoring process. Sometimes our manager has something specific in mind, but other times he says something like, "Anyone have a good idea on a project for the new guy?" and whoever has the best idea ends up doing the mentoring.

What ends up happening is the new hire is put on a project that can afford the learning curve time, and mentored by the person most familiar with the project. That might be someone who's been here 10 months or 10 years. Sometimes people end up mentoring the mentors a little bit, but the advantage is the newer people still remember all the difficulties of being new and how they overcame them.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.