Who should train new programmers? Junior or senior programmers? [closed]

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).

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...

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.

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.

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.

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.

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.

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.

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.