How does one avoid becoming a crutch?

Question

Question

During my career as a software engineer, I have been both the learner and the mentor, and I have noticed that it can be very easy for the mentor to become a crutch to the learner. Rather than teaching the learner to catch fish for themselves, the mentor ends up doing all the fishing (I think I destroyed that analogy - apologies).

How can this be avoided? How can a mentor properly support their charge without the charge becoming overly dependent on the mentor?

A mentor hopes to teach not only the tricks of the trade with regards to programming, but also with regards to resourcefulness and the self-reliance required to research things one doesn't know. However, what tends to happen is that the student just learns to ask the mentor (until persuaded to do otherwise).

In my experience, the student usually uses the mentor as a crutch until rudeness plays its part ("Go do it yourself! You whiny b*tch!" for example), which is obviously not preferential in polite quarters where colleagues are to get along amicably and be encouraged to grow. Does anyone have any other, less demeaning approaches that effectively teach someone the ropes of how to go about finding information for themselves?

---

Update

Well, there have been some very interesting answers here, so I thought I'd summarize what I see as the most popular approaches and give my take on them. This is in no way the end of this topic as there are many other suggestions that I feel play a part (though to a lesser extent than the ones I mention), I just wanted to summarize what I feel are the pertinent points given so far - if you disagree, I'd love to hear your take on things.

So far, the most popular appear to relate to:

• Time management
• Learning from mistakes
• Recruitment and management

Time Management

The essence of this is to restrict a student's access to their mentor so that the student must carefully select what questions to ask to get the most out of that time. I think that this can be a positive and a negative approach - positive because a good student will realise that they can learn and achieve most things on their own, and negative because a bad or inexperienced student might waste time on something that will not teach them much or instill confidence.

Learning From Mistakes

A lot of answers here took the approach that a mentor should give the student just enough information to get them to a point where they could work out the rest for themselves, right or wrong. For example, ask the student what they think they should do and then provide advice on that approach rather than give them a direct approach. Another example would be to point them to a resource where they might find more information.

I think this approach is by far the most effective in all but the most extreme situations and, when coupled with time management, could very well lead to a successful mentor/student relationship (within the bounds of the law, you understand).

Recruitment and Management

Of course, an important point raised is with a bad mentor or a bad student, no approach is really going to work, which is down to recruitment and management more than anything else. I mean, you don't want to recruit people who are bad at what they do and you don't want to assign tasks to those who don't have the aptitude to complete them, and let's face it, not everyone is good at teaching others even if they are extraordinarily good at everything else.

Answer 1

Possible solutions

Limit question/interruptions to a few per day. The questioner has to then keep a list of things to ask and quite possibly figures out the answer prior to having to bother/ask the others.

Appropriate questioning from the mentor - every time the learner comes to ask a question. Make the learner think. They will them become used to being asked and be more prepared each time they consult. Eventually they will answer more and more questions themselves.

There is no quick fix.

Answer 2

You simply have to find more polite ways to say "go away."

Another approach might be to restrict the times of day the learner has access to you - or even the amount of time per week. Tell them that you're busy and that you need to limit how much time you spend with them. If they are mature, and professional, they should not have a problem with that.

Answer 3

This may not work for you, but it worked wonders in my office. Set up sacred time. This is time in which no one is allowed to interrupt any one else's work barring an emergency. This means the "learners" have to do for themselves in that time.

It cannot prevent a determined question, but it usually slows the painfully obvious questions down dramatically, and since it is enforced for every developer it is not seen as rude. Additionally most developers like the concept of having a dedicated time for pure coding or reading slashdot. ;)

We set aside 2 hours a day for this.

Answer 4

Having dealt with this from both sides, I think the best way to deal with this is not to provide direct answers to the learner, but to show them how you find the answers. So if they come to you with a question about how to do something, instead of telling them how to do it, engage them in the process of finding out how, even if you already know. The process is a little bit longer, but it'll pay off in the long run, as they can find out themselves much easier.

In this way, your domain knowledge as the mentor is used well, because you can more effectively winnow the search and learning process for them, and at the same time, they're learning how to learn more about the topic and be more independent.

Answer 5

Part of the secret could be in showing what the tricks are for finding various answers along with being good at giving tips so that the learner figures it out on their own, e.g. you could recommend someone go over to MSDN to look up a class' members or methods rather than doing the work yourself.

Culture can play a role in this as well. Does the learner want to be a good developer and self-sufficient or do they want to pass the buck of, "Well, I haven't done this before and wanted some help..." which can lead to some ugly political situations. Is there adequate training and processes in play to ensure that some basics are covered in the initial work of a new hire, e.g. where is the documentation of systems, coding styles, process of software development like when is code written, how are designs reviewed?

I think those basics should be covered first, and then the question may become how well is the newbie meeting expectations of understanding the systems and processes that should be part of an annual, or possibly more frequent, review? After all, isn't part of the job fiting in and growing one's skills?

Answer 6

Same as @Tim. One of my former managers was great at this, he would always start with:

"And what do you reckon you should do?"

Often it turns out the mentoree already has an idea which they may be unsure of sharing.

If that doesn't work, perhaps pair programming, making sure the mentoree drives, and a lot of patience.

Answer 7

Here are some of my suggestions:

1) Show them where to find the answer and have them think about it. If you do this enough times, they will get the idea they need to doing better research before asking questions.

2) Give them small hints without telling them the answer directly. Have them congnitively thing before giving a response.

3) Ask them to do more projects that get them up to speed on whatever they need to be learning.

Remember, the goal of a mentor is not to generate more work for yourself. If you are just going to give them the answer then you could do it yourself (which defeats the purpose of that learner). The goal is to teach them how to learn and teach them how to become independent in their research.

Answer 8

Call me simple, but once the initial technology transition phase has occured, the learner must be given the opportunity to take over the area without having the teacher looking over the shoulder and being too available.

A simple way is to have the teacher/architect only be available for a scheduled meeting, not watercooler types of discussions. The teacher can have milestones in a project plan or lifecycle to do design reviews, code walkthroughs, architecture, etc. But beyond those milestones, the teacher has to be away enough to let the learner both prove themselves and be given the opportunity to shine.

Answer 9

I think the ultimate answer is to hire people who have the "independence gene," that is, a healthy enough ego that they want to be independent contributors themselves, and their personal pride will cause them to exhaust their own resources before bugging others.

Now, this can be taken too far, in that you don't want people who just do their own thing and think they can't learn from others and end up re-inventing the wheel, except this time in a square shape for "improved stability."

Of course, the problem comes when people without that gene are already established on the team and have some skills and knowledge you don't want to lose...

Answer 10

This is kind of mean, but take a vacation, and loose your cell phone, ( atleast for calls from the office ).

This will force the person to figure it out on their own since you are not there to lean on.

Besides that, I agree with McWafflestix and Tim.

Answer 11

Give them the tools, resources, point them in the right direction and let them go. Of course, this is task dependent. We called it "Baptism Under Fire" in the military.

As long as the student has some idea of what they should be doing, what they are doing, and thier supervisors have given them the tools and resources to do the job, the individual should only come to you with competent questions, and not questions like "What should I put on next, this or that."

They need to learn what to do when you aren't around, and feel comfortable doing it and makeing competent decisions. At the same time, the mentor needs to have patience and the willingness to teach. If the mentor does not have the willingness, the time, or the patience the mentor needs to inform his manager that the current arrangement isn't going to work. All that will happen is you will get an annoyed 'mentor' and a nervous employee looking for another job and a manager asking "what happened?"

It is also the students job to ask for the resources and tools to do the job. If the supervisor ignores and brushes off questions of this nature, they fail in this capacity, and are just setting themselves and you the student up for failure and might as well stop and rethink what they are doing.

Answer 12

@D Scott, I agree. If the teacher doesn't want to or can't teach you have a break down in the learning process and possibly some deeper problems within in the team.

At the same time, if the teacher is busy, and forgets something, the student needs to at least make an effort to ask, or ask someone else.

I have watched new hires waste two entire days 'sitting around' because their supervisor got them all set up, but forgot to install a piece of software, or a request for access when all they needed to do was just ask someone else. They waited until it became a problem.

Teacher & Student it's a "50/50" relationship.

Answer 13

If you have the luxury of time, have the learner solve, design, and implement solutions alone or mostly alone, then have a code review. Instead of just saying "this is wrong", "that is wrong", or "do it this way" etc... ask the learner to explain the design decisions regarding the areas you find problematic. Then explain why that part of the code smells, and then have them go back and improve those areas with or without subtle hints as how to make it better. Learning by iterating on the same problem is very powerful. Also often the act of just talking through why they did certain things leads to aha moments in learning the craft.

Answer 14

The expression you were looking for is "give a man a fish, and he'll eat for a day; teach a man to fish, and he'll eat for a lifetime", but that's a common misquotation. The correct version is:

Give a man a fish, and he'll eat for a day. Slap a man upside the head with a salmon, and he'll stop asking you for fish.

This is how you avoid becoming a crutch, grasshopper.

Answer 15

The correct quote may be: "give a man a fish, and he'll eat for a day; teach a man to fish, and he'll eat for a lifetime"

But it should be: "give a man a fish, and he'll eat for a day; teach a man to fish, and he'll sit in a boat all day drinking beer."

As to mentoring or teaching, there are usually two distinct stages. The first is "pure teaching" - when the mentor does not yet have the tools to proceed. At that stage, the student really does rely on the mentor to help them out. In teaching, this is usually the first few lectures. Once the student has a few basic tools, then you can move on to the next stage, which often involves problem solving.

During the second (problem solving) stage, it's so easy to ask the mentor to solve the problem, and some mentors make the mistake of "doing the work" = "being a valuable mentor".

Far better at this point is to start most help-request replies with "what have you done so far to solve this". If the student has done nothing, then the first few times the mentor can suggest a few common strategies to begin. However, if in time the student seems to be coming to the student without doing any "homework" first, the there are two good responses to this:

1. Well, I've shown you what to do, so go away and come back when you have outlined some options and a possible plan or two.

2. My job is not to do your job, nor to solve your problems. It's time you started doing this work before coming to me. (then go to answer #1).

Basically, once you have provided sufficient mentoring to allow a motivated student to begin working on their own with occasional guidance, you must then be prepared to dish out a bit of "tough love" to encourage them to do just that.

Cheers,

-Richard

Answer 16

Hi,

not sure if you're talking about a youngster at the beginning of his career. If so, then...

at the beginning, show off your skills because you have to gain respect from the youngster. This is important to keep me motivated in being a mentor for him. In other words: I don't cast pearls before swine :-) Once you decided the youngster is good enough... explain, but not too much. Set the bar one notch higher, mildly congratulate if he succeeded, be highly disappointed if he fails. Tell him is in the average and he should fight back with good code because he's proud. If he's not proud, he's not a developer and should let go :-)

Forget the above if the learner is a nice girl :-) (but it won't happen, isn't it)

Bye

Stefano

Answer 17

Never actually type ANYTHING for them. Also, never say word-for-word what they should be coding.

Answer 18

you can try instituting office hours, and limit your mentor time to an acceptable amount.

you can try wiki-ing up the common questions and using RTFM when you are swamped or get the crutch vibe.

Answer 19

At the very beginning of my career, I needed to solve a specific programming problem, and I had no clue how to solve it or where to start. I said to my mentor "I don't know how to do [fill in the blank]." He moved my laptop in front of him and said "Neither do I, but I'm a smart guy, I bet I can figure it out." Of course, since my ego was then bruised, I had no choice but to take back the laptop and hunt the answer down myself.

Sometimes it simply takes reminding the mentee he's doing what he does because someone thinks he's smart enough to do it.

Answer 20

I just thought of a better answer:

To avoid becoming a crutch, break both of their legs.

Think about it.

Answer 21

The Mentor at my initial job would say : "Ah I have not thought about how to do it. Can you come up with a few suggestions so that we can discuss?"

After I came up with the suggestions: "Hmm...interesting ..can you tell me which one is better"

By this time, I was very much through all the options and would have a fair idea( i still went to him to get the clarification or so).

At the very end , he would (most likely) agree to my suggestions and would say: "You had the capability to get the answer..even before you came to me..didn't you?"

I remember going to him for a couple of time initially like that..may be because I was stuck or may be because I felt he had a solution off the cuff. This changed after the initial couple of months...

Answer 22

Easy, as the mentor your job is to get the protege to do things for themselves.

The easiest way to do that is to ask them questions back. Never flatout answer questions. Instead ask them questions that will get them to get the answers on their own.

Then you might ask what is the point of being a mentor if you aren't answering questions, but just asking the protege questions? True, you are just asking them questions, but your questions are designed to get them thinking in the right direction.

Essentially your questions are leading them down corridors of understanding. Gently. And it is the protege's responsibility to walk the path. It is the only real way for them to learn and really absorb the material anyway.