Should senior programmers be required to take on and mentor a junior developer?

Question

In a shop that is intended to be tight-knit and supportive, should it be part of the culture that senior developers are paired with junior developers as mentors? Or should this mentoring be something that is more organic and spontaneous, i.e. not required, but allowed to develop without artificial encouragement?

Mandates do not work; in fact they often have the opposite effect. Al Capone was created by government legislature. Some East Germans who had to study Russian for 4 years prided themselves in not being able to say a single sentence in that language. Same thing can happen if you mandate the teaching of evolution or having the senior guy mentor the junior one. — Job, Jun 22 '11 at 20:50
It has to be organic to be worth anything, but it can still be forced in a way by deciding who is there in the first place. Anyone who isn't working closely with the other developers, wether junior or senior, isn't worth much. There should be an ongoing conversation among your team, and everyone should be learning and teaching. Its a good reason to start people off as contractors or provisional employees to see if they gel properly. — Peter DeWeese, Jun 23 '11 at 02:22
@Job Do you ever wonder that a dev might end up doing the same crap all his _life_ [harmless exaggeration] if he **doesnt mentor** a junior to do _his_ [i mean common .. hes not gonna mentor her in physics] job ? — Chani, Jun 23 '11 at 06:50

score 38 · Accepted Answer · answered Jun 22 '11 at 20:20

38

I think it should be encouraged but not required; seniors shouldn't be assigned to juniors or anything like that, or else you'll end up in Dilbert-land. The "mentor-mentee" relationship requires some level of friendship at its core, as well as a healthy dose of MUTUAL respect. You don't get that by just telling to people to go off and "ment".

answered Jun 22 '11 at 20:20

KeithS

21,994
6
52
79

3

How do you encourage this then? How can you make sure the seniors and the juniors know it's ok to take work time to mentor/be mentored? – richard Jun 22 '11 at 20:23
3

If you encourage a pair-programming model, often this kind of relationship simply falls out if you simply encourage juniors and seniors to pair. Besides that, foster friendships through the entire team; team-building exercises, outings, and other non-work interaction. – KeithS Jun 22 '11 at 20:28
That does seem like a good way to foster friendships which should naturally lead to mentoring. – richard Jun 22 '11 at 20:31
I agree completely, mentorship at its best gives back to the mentor as much as to the mentee, so open, "eye-level" conversations are a prerequisite – Asaf Jun 23 '11 at 04:42

score 21 · Answer 2 · edited Jan 11 '18 at 16:41

21

should it be part of the culture that senior developers are paired with junior developers as mentors?

Yes.

organic and spontaneous, i.e. not required, but allowed to develop without artificial encouragement

It won't happen often enough to actually help anyone.

Folks with existing relationships in the organizations will be perceived as cliques or elitists by new people. The cliques will not normally break down. We stick with people we know -- it's an essential element of human nature.

As a consultant for over 30 years (100's of client engagements) I can assert that new people are always outsiders. It isn't a feature of "culture" or "atmospherics". It's an essential feature of how people work. The consultants form their own clique because the established staff don't tend to include them in anything.

The only way to establish mentoring is to insert new people into the cliques.

edited Jan 11 '18 at 16:41

Macondo2Seattle

101
4

answered Jun 22 '11 at 20:33

S.Lott

45,264
6
90
154

@David Thornley and S.Lott: Can you share what you have seen in your experiences? Annecdotes? I am getting really mixed answers here! – richard Jun 22 '11 at 20:39
@Richard DesLonde: I've almost never seen mentorships spontaneously form, although I might not be the best person to ask (I'm a bit on the asocial side for a software developer). The only time I saw it happen on a significant scale was when management asked for people interested in being mentors and mentees and suggested pairings. – David Thornley Jun 22 '11 at 20:45
1

@Richard DesLonde: "I am getting really mixed answers"? What did you expect? It's a subjective question about "socialization". There's no right answer. If there was, we'd already be doing it. – S.Lott Jun 22 '11 at 20:54
That _is_ what I expected. But you and David are coming at it from the other side than most of the other answers, so I wanted you to way in a little more to balance out the answers. I want as much info from both sides as I can get. Thanks! :-) – richard Jun 22 '11 at 20:55

score 8 · Answer 3 · answered Jun 22 '11 at 20:21

8

The traditional meaning of a "mentor" somewhat defies assignments. You might as well try and assign friends.

It is fine, in my experience, to assign a new team member to use an established team member as their primary contact for questions during the first week, month, or so.

answered Jun 22 '11 at 20:21

Christopher Bibbs

2,709
15
12

1

How would you then encourage mentoring? You want juniors to feel confortable being mentored, and you want seniors to feel comfortable mentoring. – richard Jun 22 '11 at 20:22
1

@Richard: As a senior developer mentoring is a primary task. You don't become senior by getting old and growing a beard. If you can't mentor, don't get into this role. "Just" be a developer. – back2dos Jun 22 '11 at 21:38
1

@Richard Usually the conversation goes something like: Senior Developer: "Those guys are writing terrible interfaces! It's screwing up everything I designed last year." Me: "You know, if you want the new guys to write cleaner interfaces you might want to sit down with them and explain your thinking." – Christopher Bibbs Jun 23 '11 at 12:08

score 7 · Answer 4 · answered Jun 22 '11 at 21:19

Should senior developers be required to mentor junior developers?

Absolutely not. Some good senior developers are going to be horrible mentors and the matchup of personalities is a must have for successful mentor ship. I think, however, that senior developers should be required to make something about the development team better. That could be prototyping something on the side, improving a process or practice, pioneering new tools, presenting technical material to the group, leading a team or something else. In other words, they should have a responsibility for something that is bigger than the individual workshare.

Or should this mentoring be something that is more organic and spontaneous, i.e. not required, but allowed to develop without artificial encouragement?

Nope, don't agree with that take, either. I've seen too many situations where mentoring is expected to be "organic and spontaneous" and it happens all too rarely. I think organizations do need to take on the onus of giving mentorships a chance to get infectious - but it can't be forced. That's hard, but worthwhile. I think the organization could do things like:

Informal meet-ups between potential mentors and potential proteges
Suggested ways and opportunities for mentorship to be formally recognized by the organization (for example, if you are a place that has a charge number for virtually everything, create a charge number for mentor ship meetings - clarifying that this IS a viable part of the work)
Training and support for mentors
guidance to proteges for how to select a mentor and what to expect
guidance to mentors on what to expect and what to offer
Suggested (or enforced) patterns for mentorships with templates for participation - for example, it's much easier to give it a shot if you know in advance that your goal is a 3 month experience with weekly meetups and a goal of helping a new developer get up and going in the company. Not to say it won't develop into more... but it gives a place for folks to start.

Mike O'Connor · Answer 5 · 2011-06-22T21:35:17.150

I think that making it a requirement could potentially backfire, as some people just aren't wired that way, and would be very turned off by the idea. That being said, you should identify the people that you think are suited to be mentors, and approach them about taking a more active role in mentoring (if they aren't already). This lead-by-example approach could catch on and inspire more spontaneous mentoring.

You might also schedule regularly occurring group activities, which will help the team to jell. These could be completely social activities, like a team lunch, or activities that incorporate learning about programming, like a weekly programming book club.

You could also have regular "mini postmortems" on systems, which would function like a group code review. One benefit of doing the review in a group setting is that everyone can benefit from the feedback, rather than just the person who wrote the original code. You might need to get some volunteers who are comfortable having their code judged to get things started, and be sure to maintain civility.

score 4 · Answer 6 · answered Jun 23 '11 at 00:06

I have been in environments that do things both ways.

The first job I had out of school, I was assigned a mentor. I didn't like the guy, and I certainly didn't agree with him on everything. I resented being forced to work with him, and I was pretty sure my employer had made a mistake, but in retrospect I learned a lot.

Fast forward a few years, and now I'm with a company that treats developers with an every-man-for-himself attitude. Developers are under tight deadlines, and few if any allowances are made for developers who spend time taking others under their wings to show them the ropes. I think it's a shame. I see how junior developers struggle with the same things I did, but without a mentor to help them out it takes them a lot longer.

I have developed a reputation as "the mentor" because new hires "seem to appreciate the help I'm able to provide them". As far as I can tell, this is a fancy HR way of saying that I am willing to tolerate mediocre productivity reviews so I can do the right thing, which is to enable junior developers to do their jobs effectively and to improve rapidly.

I think that's what our junior employees deserve, and with the benefit of hindsight and experience, I think that first company I worked for, and that guy that mentored me, had a lot more figured out than I thought at the time.

All of this is the long way of saying that while I wish you didn't have to assign mentors, it is probably the only fair way of spreading around the work. If you don't, you should give the people that do it their due. It is not easy work; it requires both interpersonal skills and engineering skill; and it is time-consuming.

score 4 · Answer 7 · answered Jun 23 '11 at 02:37

I never liked the terms Junior and Senior programmers. For example, I've been programming for a while and although I have experience in some areas, I am very green in others. For example, we are moving to WPF and although I have tons of windows forms application experience, WPF is still new and foriegn to me. So although I am a "senior" programmer, you could hire someone off the street with way less 'total' experience and they could probably program a WPF application better and faster than me at this point.

Not to say I don't lots of good application design and architecture experience that could be applied to the WPF application, but I know my limits.

I guess you have to be willing to be the mentor at some times and the mentee at others.

If you have team members that are not afraid to be the mentor when they have the knowledge and a mentee at others when they need the knowledge, you will have a fruitful experience.

If you can foster that kind of development environment where developers are humble and are open to new ideas and help others along when needed, the sempai-kohai relationships will come out naturally.

Forcing mentoring will probably create a caste system which developers may resent each other. Its better to treat every developer equally on the same level.

This industry is very different. Senority is not always better.

Sometimes the seniors need to mentored by the juniors.

This answer deserves more than the +1 I can give it. – Peter Taylor Jun 23 '11 at 11:23 — Peter Taylor, Jun 23 '11 at 11:23

score 3 · Answer 8 · edited Jun 23 '11 at 04:34

3

team leads structure, leading to code reviews should do the trick...

You'd have a senior member of your staff responsible for one or more juniors. I don't believe it should be spontaneous help, but rather a formal process; in the sense, that the senior member will be responsible for the quality of work produced by the new comers. This approach has 2 benefits (at least): instruct the seniors in management styles, and make sure the juniors produce quality code.

edited Jun 23 '11 at 04:34

Adam Lear

31,939
8
101
125

answered Jun 22 '11 at 20:23

alawand

21
1

I incorporated your comment that provided additional information into your answer. In the future, if someone asks you to clarify or elaborate on a point, please edit your answer to include the new information. That way people who visit this question later can see a comprehensive response from you without having to dig through the comments. – Adam Lear Jun 23 '11 at 04:35

score 3 · Answer 9 · answered Jun 23 '11 at 01:04

Senior developers should be expected to go beyond the churning out of code. However, the direction they go should not be the same for every senior developer.

Some are well-suited towards mentoring. Others aren't, and should be pursuing some other senior-level goal, whether it be planning and implementing architectural improvements, or evaluating new technology, or planning and leading process improvements (e.g. continuous integration, TDD, etc.)

Basically, a senior shouldn't just be someone who has been cutting code for a few years more than the juniors. It should be someone who is willing and able to take on additional responsibilities that will contribute to the success of the team. Mentoring juniors is important, but it's not the only important thing, and it's not something that everyone is well suited to.

score 3 · Answer 10 · answered Jun 23 '11 at 04:01

Mandating such mentoring is counter-productive because human beings quite naturally strive against forced activities, actions and relationships. A better approach is to reward the people who do good mentoring, thus getting people to want to mentor.

Of course this brings up the problem of measuring "good" in this context. An imperfect, but easily-implemented solution might be to have the newcomers after a year (possibly anonymously) write the names of, say, the top three people who helped them integrate into the company and/or the code base. After that you can reward the people whose names get mentioned most. Monetary rewards won't work here, however. It's better to find some kind of social reward.

score 2 · Answer 11 · answered Jun 22 '11 at 20:21

2

In all things programming it depends. But I would definitely want a senior developer mentoring new hires, whether they're junior or not, to get them the best training for the job at hand.

answered Jun 22 '11 at 20:21

Jesse C. Slicer

6,002
2
32
44

JB King · Answer 12 · 2011-06-22T20:52:09.963

No, because that would imply the number of senior and junior developers be the same all the time. I could see encouraging those senior developers that want to be mentors but enforcing a pairing could be a really bad idea. The idea of supporting mentoring relationships is good and shouldn't be thrown out here.

Artificial encouragement isn't a bad idea here though. Telling all junior and senior developers that they are going to be mentees and mentors no matter what could be a bit religious and backfire quite quickly.

If there is a framework known within the company of how to handle mentoring that would be great. However, if that doesn't exist then the key becomes having a few different kinds of moments between the mentor and mentee:

Current status - Where are things now? What is the current challenge that the mentor may provide assistance in resolving?
Future state - What is wanted: A hint, a solution, questions to ask, who to ask?
Retrospective - What worked and didn't work in making changes?
Future changes - What will be tried in the future that may work better than what was done previously?

At least those are states that I can see and make sense from my view to take a logical top-down approach. Others may want something much more organic and free-form which can work as well. The key is to get an idea of how to get each side to have some skills that should be honed through the practice of communicating in this relationship. Each side should be gaining something from the relationship and there should be some common ground rules in having this kind of relationship as feedback is a big deal here.

How much time one spends in this is a fair question that realistically one has to look at what is being done and to what extent it is acceptable to spend time developing skills and building relationships. I could see some pairs wanting an hour a week to go through this while others may want a couple hours a day to cover this. Don't forget that there can be other interactions where a senior and junior may work together though not within a formal mentoring relationship.

Yeah I see that. I wonder how you encourage mentoring and make them comfortable taking paid work time to do it? — richard, Jun 22 '11 at 20:25

score 2 · Answer 13 · answered Jun 22 '11 at 21:14

I've seen a couple of different attempts at mentorship systems. The ones I liked best were ones where the senior dev had a specific set of tasks that they performed to help the junior dev, which paved the way for mentoring without requiring it. For example, an assigned senior dev one-on-one code-reviewer for the first six months could be very useful and would be likely to lead to mentorship. The ones that I disliked were the ones that felt like extra busywork and which didn't seem to be directly related to the work being done - e.g., meet with your assigned mentor for half an hour every week. This was especially annoying when the two members of the mentorship relationship generally didn't interact with each other during the week and didn't have anything to do with each other's projects. It felt very forced and touchy-feely rather than focused on growing professionally. The last thing you want is for a mentorship relationship to feel like a counseling session.

IME, you can't count on mentorship relationships developing, so providing a potential mentor by pairing a senior dev and a junior dev for a set of normal paired business activities (code reviews, debugging, pair programming, etc.), at least at first, is a great idea. Ideally, the senior member should be volunteering for the role and should be able to perceive some personal benefit. At my current company, senior devs are almost leads for their projects, and the benefit is that they are building up their own project's team. At the other company, mentors were often investigating the management track.

score 2 · Answer 14 · answered Jun 23 '11 at 10:54

I think every company that hires young developers should have some sort of a reasonably effective mentoring program. But I'm not sure the default position should be every senior developer should do it for the simple reason that lots of developers, regardless of how good they are at developing, are lousy at mentoring. It goes with the territory unfortunately. Some of us just aren't great people people if you like.

On the other hand, where there are people who are good at it, they should get recognition for it, and not blackmarks because their actual development output falls while they are explaining some simple localised issue regarding, oh IDE implementation to some newbie who has always used NotePad and Javac, for example.

This requires some balanced management. I'm not certain it's common.

score 2 · Answer 15 · answered Jun 23 '11 at 11:58

For any mentoring to work it is essential that management recognizes that this is important and allocate time for this, and actively encourage this!

For anyone 100% booked with assignments there literally is no time to do or receive mentoring, and it will not happen.

score 1 · Answer 16 · answered Jun 23 '11 at 13:13

Generally mentor ships are good stepping ground for transition from senior to team lead or manager. It is more effective to link the mentorship to advancement in a PDP(Personal Development Plan) or what ever merit plan your company uses. Tying their pay increase and career development at least in part to their ability to pass on knowledge and groom new developers is key to building a strong IT Staff that can weather changes in management and staff turnover. Providing key goals and working with staff to help them improve is part of that growth into leadership. For those who think it is not fair to tie a seniors evaluation to a juniors performance that is part of the growth. In most cases you are not talking about a pay cut but rather reduced increase or slowed advancement. Seeing as part of that advancement is the ability to lead and teach those under your leadership this seems quite natural to me.

score 0 · Answer 17 · answered Jun 22 '11 at 21:14

When I first came to the team I had the owner and a lead developer giving me instruction. I could ask either of them anything and they both would reply. Though, I was respectful enough to not keep bothering them unless I just couldn't figure it out in a timely manner.

It worked great but then again, you probably need nice people with a sense of humor to get this to work.

Should senior programmers be required to take on and mentor a junior developer?

17 Answers17

Linked