"Mentor" a senior programmer or colleague without insulting

Question

I don't have great social skills. Like many programmers I know, social skills are something that is worked on and developed over time because it's not a natural and 'inborn' trait.

When a computer is doing something wrong, you can tell it so and 'fix' it so it'll work correctly the next time.

It won't complain. It won't feel insulted. In fact, I tend to think it's 'happier' because it's not grinding away in a dead end.

---

I find it much trickier to work with other programmers at or above my level in a way that enables them to do better work faster without appearing condescending, insulting, or the group's "know-it-all."

I know some programmer's look at this objectively and simply say, "Since it's for the good of the group I will inform them, and if they are insulted that's their problem." This isn't a bad method - all the programmers I have ever worked with take and act on criticism appropriately. It's when they're having a bad day/week/month/year/life that I find it difficult to approach them without a reactive emotional response.

I genuinely enjoy working with those around me, though, and don't want to develop bad blood.

• What skills, techniques, and even outside of work activities do you engage in that enable you to be a support and resource without the tension that can be created in these situations?

• Or, in other words, how do you mentor someone without appearing to mentor them?

I suppose the question could/should be reversed as well - how do you keep yourself 'open' and learning such that you don't scare off people that have useful information for you? How do you keep on top of skills so that the latest college grad isn't necessarily better than you in terms of design patterns, technology, workflow, etc?

Answer 1

Personally, I can't stand questions that begin with "Why don't you"... Such as "Why don't you use generics for that?". How am I supposed to answer that? It's either "because I have a good reason not to", or "because I'm not as smart as you and didn't think of it".

Instead, I like "Have you tried..." suggestions. "Have you tried making that class generic?". Then the answer is "no I haven't, tell me more".

Asking in this manner doesn't assume anything. You're not assuming you know the right answer or are even in a position to mentor the other person. You're simply starting a conversation.

---

Edit

I'd like to clarify something in response to some comments and other posts. The idea here is more than just rewording a question to avoid pushing someone's buttons. The idea is to start a conversation with a coworker rather than confronting him/her with a difference in opinion. There are lots of subtle ways to do this. As someone else pointed out, rephrasing a question from "Why didn't you" to "Why did you" has the same effect. You're asking a legitimate question about a decision the other person made, rather than asserting your own ideas. Remember - there may be a good reason the other person did something a certain way, and you might be the one learning something new today.

Certainly we should be equally aware of this when we're on the other side of the desk. When a peer asks what we interpret as a confrontational question, we should respond in a constructive manner. Just don't assume that everyone else will do the same.

Answer 2

• admit ignorance. many (most?) non-trival questions are best answered with "not sure, but i think so and so. let's find out!"
• most issues are a good excuse for learning, he'll learn from you, you'll learn while doing something again with a fresh approach.
• keep producing. if others respect your work, they won't feel insulted.
• if a point is a trivial question, or an obvious error, try to apporach as a puzzle: "what source of errors am i overseeing?" "is there some ambiguity in the docs?"

Answer 3

This is such a common concern, and rightly so. It's a very odd feeling to have to give feedback to someone in the work environment. These aren't always your friends, who you can joke around with. Many people take feedback very seriously, as they may feel threatened or worried of losing their jobs.

It's very important to establish positive relationships with your co-workers. Doing this will take effort on your part. You'll need to get a general understanding of each person's personality. I myself am relatively quiet; I keep to myself for the most part. Some of my closest co-workers are the exact opposite: they're very outgoing people. If you understand how they want to be treated, this will allow you to establish good relationships.

Some people walk into meetings and want to get right down to business. Give me the facts, spare the fluff. Other people (and these may be people in the same meeting) are very people-oriented, and have a hard time focusing before they do their 'how was your weekend' spiel. To each his/her own. It is often difficult enough trying to get these people together to come to a common agenda.

What I'm trying to say is this: there's no one formula for how to treat people or give them feedback. Me? I'd like to hear "hey man, I understand you're a valuable resource, but could you try doing your work this way instead of that way. Here's why." However, some of the people I've menteed have needed to be more engaged in a conversation. "Bob, could you explain to me why you're doing it this way? Help me understand the logic involved here; I've never seen this before." Then perhaps suggest different ways, if you think your methods are better.

Last, and most important: if someone is frustrating you, take a walk down the hallway! It sounds obvious but it works. No more punches in the face!

Answer 4

I find developers very objective. So you can actually get a rational discussion going. Just be honest and ease the facts in.

Going the other way, if you are not trying to learn all the time, then you are not a great developer.

Answer 5

as long as your ego is invested in your code, you will neither be a good mentor or appreciate others mentoring you

humility is a virtue, especially in other people ;-)

seriously, if he doesn't want to be mentored you can't make him accept it. If you must make "helpful suggestions", do so quietly and only once, then let it go. If the student is ready, he will return for more.

EDIT: I heartily endorse Troy's admonition not to be in the "mentoring mindset" because this places you on a plane above your co-worker, which can be bad for team relationships even if it is only done in your head and temporarily. "Discuss technical issues as equals" is excellent advice. To this I would add "choose your battles", i.e. don't bit-pick every little thing but focus only on the potentially serious mistakes or questionable techniques.

Answer 6

This is a difficult thing to do, as you and several others have noted, but it helps if you pick the right time to do things as well as presenting things in a way that isn't negative. Picking the right time to do things means that you shouldn't say something that will potentially call someone out (e.g. expose their ignorance) in a group setting. In group settings, even the most objective and open to feedback person might react a bit defensively if you are calling them out in a group setting. Unless you have to call them out in front of the group - try to avoid it and just pull them off to the side later on.

In the realm of presenting the "mentoring" - it all depends upon what you are discussing and who you are talking to. In some cases, it doesn't matter what you say, you are going to be wrong. About the only thing you can do at that point it get someone higher up (e.g. boss, well respected co-worker, your mentor) to go and talk to the person. If the person is open to discussion, then try not to come off as being judgmental or arrogant about what you are discussing, doing so will likely just cause the person to tune you out. From my own experiences, the best way of approaching someone is in a more of a "just the facts" matter in which you are presenting a better way of doing something. Most people in IT understand that things change very fast and it doesn't take much time to get out of date on someone. If you approach things from that angle then most people will listen to what you have to say.

Answer 7

So this question seems to have three parts:

1. How do you give people criticism without offending them? It's all about making it safe for the other person. Give them room to save face if appropriate, and ask questions instead of making firm statements. If it's extremely precarious, ask for permission: "I have something I would like to talk to you about that is a little delicate, but I think it's worth it. Is that okay?"

If they start to get offended, back off and make it safe. "I can see that I'm rubbing you the wrong way here. That's not what I'm trying to do. I am trying to give you a little constructive criticism -- is that okay?"

2. How do you stay open so you can continue to grow and recieve from those around you? Be mindful of when and how you react, first of all. If you genuinely want to collaberate and learn from others, and if you can keep your ego from getting involved, this will fall into place.

There is a great book on these subjects called Crucial Conversations and another one - and this one is even better - called Crucial Confrontations. I highly recommend the second one. Among other things, it's about learning how to keep your ego from hurting your relationships... Particularly in the most important situations where a lot is on the line and maybe you're in the middle of an adrenaline rush.

3. How do I stay competitive with the folks who are coming out of school right now? Experience! Most people who are right out of college have a lot of idealism and fire, but no real world experience. They have a lot of learning to do, some of which might be very painful.

Stay curious and be willing to learn from them, and remember the value of experience.

Answer 8

I'd say you've taken the first step: recognizing that good relations with other developers is important. Many developers never realize this, and many who do decide it's not worth the effort to learn how to mentor/direct.

I've had the opportunity to work with many developers over the years, some senior to me, mostly junior. I think every senior developer deals with the "I don't have time for this n00b" reflex when mentoring.

I'd be the first to admit I haven't always done a good job when mentoring. I have found success with some basic communication skills:

1. LISTEN. Your job as mentor is to understand the level of your peer's understanding and identify where his/her understanding is incomplete.
2. Lead by example. If you have a code sample available that offers a solution, provide it with an explanation.
3. Know your peer's limits. If they are not receptive to your criticism, don't offer it. If they are a direct report and they are consistently unresponsive to code reviews, you may have made a bad hiring decision.
4. Avoid "You" statements- "you made an error", "you need to fix this." This may sound cliche and silly, but it helps to phrase your critique generally: "This should be X instead of Y." "X is a common error, Y works better."
5. Share your methods. If you are especially good at something, i.e. design patterns, research, a particular framework- document it and send it around. It helps if you are the recognized SME for the topic.
6. Be specific. Don't just say "that won't work," explain why you think a different way would be better.

Remaining open to criticism can be difficult- I think this is because, as we're discussing, it is difficult to offer constructive criticism without seeming condescending. I think it is very helpful to receive criticism if you have already honestly and perhaps harshly criticized your own work. When someone else points out a flaw you have already identified (and we all know there's no such thing as flawless software!) it is much less emotional. Beyond that, I try to calmly evaluate the criticism I receive, decide if it has merit, and move on accordingly. You don't have to agree with your critics, and you don't always have to tell them when you disagree. Smile and nod, everyone's a critic! :)

Answer 9

If you think something is wrong, come up with a question about that piece of code where, for which the answer includes the mistake. Do this in a polite and honest manner, and don't make fun of the answer. Be prepared to come up with another question when your collegue missed the point.

Q: Why are you using a Hashmap here?

A: Because over here it is... erhm... wait a minute... this is wrong!

By doing this you are very safe. If you were wrong, you appear just having asked a question, and have gotten the anser so you can think and talk about the subject. If you were right, you also get an answer and an oportunity to figure the solution out together.

Remarks start quarrels. Questions start conversations.

Answer 10

The key is not to be in the "mentoring mindset". By that I mean, if you have a feeling of humility about your ideas and suggestions, then you wouldn't be calling it mentoring, you'd call it discussing. There's a presumption there that you are the teacher and they the student. If you approach the situation with an egalitarian mindset as a peer, your ideas will be much more palatable.

Beyond that I really dislike the current most popular answer here.. Changing the wording of how you say something so as to appear less confrontational (ie, "Have you tried..." vs "Why don't you..." ) is far MORE annoying than simply being direct. It's passive-aggressive. Ugh. Software developers see right through that kind of thing.

I guess my point is that if your humility is insincere, then it doesn't matter what you do, it's going to be offensive. The more you try to create indirection around that, the more annoying it will be to the guy you're "mentoring".

I prefer the most straightforward method possible. I actually love the phrase "Why don't you.." because it gets right to the point. You, the reviewer, look at the code, and it creates the question in your mind. "Why didn't he do it the way I would have?" Then, the developer can respond to the real question "Why didn't you do it XYZ way?" and can simply explain why he choose to do it differently, rather than having to inventory all the things he may or may not have tried, without explnation as to why he should even be thinking about that, or trying that...

When I find myself in this situation, for example, in a code review, or when I encounter someone elses code that isn't what I expect, I make sure that I know why I object to it first. I make sure I have a set of reasons and an opinion about a better solution that's consistent with that reasoning. Then I will say "I noticed that you're doing XYZ in the ABC class. That doesn't seem like the best way to do it, because of [insert reasons here]. To avoid this problem, I usually do [insert opinions here]. What do you think? Is there a reason why you're doing it that way instead?"

So now, my coworker has reasons, a solution, and an opportunity to explain to me why my solution might not make as much sense as theirs did. This might result in a long conversation where we find out that either I was wrong, they were wrong, or both solutions were wrong. In the process we all learn something.

So, I guess my one-line answer is: "Don't mentor, explain, or tell someone what to do, offer your observations and solutions, and discuss them as equals". If you can't get into that mindset, you're going to piss people off no matter how right you are.

Answer 11

Great question, and one to which I don't really have an answer.

The only time I've found I can have any effect is if I have a very concrete suggestion having a demonstrable benefit.

For example, in performance tuning, our programmers are like most in that they a) talk about profiling, b) proceed to guess and fix their guesses. I may use my halting technique and then tell them, for example "By the way, the program is initializing structure X three times during startup, and that's accounting for 40% of the time." Then they say "Oh. OK. I can probably fix that."

Even then, they may simply not do it. So it's better to stay quiet and keep peace.

Answer 12

I don't have great social skills. Like many programmers I know, social skills are >something that is worked on and developed over time because it's not a natural and >'inborn' trait.

Social skills are developed over time for everyone. Why is it such a common misconception that developers don't have or have to work extra hard to develop social skills?

Answer 13

One of the best approaches that I have ever seen is to show that you are enthuiastic about something. "Wanna see something cool.." or "Check this out..." is a great way to share information.

If you don't want to seem like you are targeting a single person, you can also do this at your weekly developer sessions (if you have them), and present things to the group as a whole. Chances are, it will reinforce everybody's understanding of something.

Everyone can develop social skills, though. It does take time and work. One of the biggest obstacles to having strong social interaction skills is having a strong sense of self-confidence. If you have a problem in a social environment, or feel that it is something you need to work on, focus on your self-confidence first. People can tell when you aren't confident in yourself and will actually take it as a sign that you aren't at all sure about what it is your are trying to convey.

Answer 14

The first thing I do when mentoring is recite the following to the students:

There are no stupid questions...just stupid people who ask questions.

Just kidding!!! :)

I've done quite a bit of mentoring in my years in the business and there a few observations I've made along the way:

• Not everyone learns the same way. Adjust your teach methodology to the person, don't make them adjust to you.
• You can't free a fish from water. If someone does not want to learn, you can't force it. Wait for them to ask for help.
• Use metaphors and illustrations as much as possible. Programmers tend to think visually.
• Be patient! People learn at their own pace. Your job as a mentor is to help them learn, not to be a tyrannical martinet!
• Be enthusiastic, it's contagious.

---

Mentoring is a skill that develops with practice, but personality is built in!

Answer 15

You do it by example. If you can find a way to do so, volunteer to work on co-developing a project with the other person. Agree on API's, review each other's code, pass code back and forth. Don't criticize their work, let them make mistakes and let them realize the mistake, and correct it themselves. Let them contribute. Wait for them to ask you "How do I make this better." Be open to what they know, too, you might learn from them as well.

This is not an easy thing to do, and it takes above all patience. You need to establish trust and learn to just work together with the other person first, if you just say "ur doing it wrong", the lesson won't stick. Some people are (perhaps) beyond help, convinced that they are always right, unwilling to learn. But most people really do want to learn and teach (just look at this site for evidence of that), they just need a safe environment to do so.

Answer 16

Drop the word "mentor" from your vocabulary and your thinking, and you'll go a long way toward being less condescending.

I love finding the best way to do something. I would love to have someone share programming and design tips.

I will fight back if I think the design you give me is not as good as what I have in mind, or if I think that the time involved in implementing your idea (or the time involved in merely discussing your idea!) is not worth it. You should expect that; it's the way we get to the truth of the subject. If you can't handle it, then I don't think you should initiate conversations on the subject. :) This will definitely be debate-like and maybe even somewhat adversarial, but it doesn't mean I'm taking things personally or that you should, and it doesn't mean I'm not open to input. It also doesn't mean we can't enjoy each other's friendship, if we are friends.

Good programmers want to collaborate with good programmers, even if they don't always agree. If you have something productive to suggest, just suggest it. As a peer, not as my "mentor." And be willing to be corrected, by a peer. :)

Answer 17

If you want to mentor someone, first prove yourself worthy to be a mentor.

As a now rather "senior" programmer and educator, I've seen far more than my share of "hot shots" and "know it alls" at every level.

One thing never seems to change, however - and that is the universal learning curve:

1. beginner - just learning, full of questions, pretty humble, eager and thirsting for more.
2. advanced beginner - has learned some stuff, but still knows there's much to learn.
3. intermediate - gaining confidence in some areas, but still knows there are gaps.
4. advanced - confident in many areas, willing to learn new things but pretty solid.
5. expert - knows all, sees all. Nothing more to learn - seen it and done it all.
6. beginner - just discovered how much he/she does not know. Return to #1.

Sadly, too many stop when they reach #5 and become total pains-in-the-asses to everyone they work with.

So if you want to assist others (I too dislike the "mentor" term - sounds like a kind of mint), then be sure you are not operating at level 5.

Cheers,

-Richard

Answer 18

From Richards answer IMHO those who

knows all, sees all. Nothing more to learn - seen it and done it all

don't exist, except in their minds... its the beauty of this job we've found ourselves in that the tools/environment/market is always changing... so the capacity for learning is always there... the next big thing is just around the corner and you're not that far from becoming a FORTRAN dinosaur if you sit still...

Thus one bit of advice that I'd have is to look to learn from others on your team also... we all find it nice when presented with a problem/challenge to plough in and solve it ourselves, even easier now with the web (e.g. stackoverflow) available... but by asking your colleagues opinion or help, they will probably be more open to asking your help/guidance next time they need it... or to being more open to unsolicited advice/guidance..

If they don't have the answer you can also search it out together and both learn, if it feels collaborative they will be more receptive.

Answer 19

Reality often works wonders here. When their dumb idea fails miserably, point out politely and with humility that you had an alternate suggestion that would have worked if they'd listened to you. They might argue with you in an attempt to save face. In fact, if that's the case, you should let them win that argument. But they won't be able to escape the fact that you were right all along and will likely be more willing to listen later on.