Do you think that its a good idea when a junior programmer needs help to always jump in and try to educate them? Or will they ignore all the "teaching to fish" advice you give them and just focus on the "fish" you just brought them? Do you let them always figure things out on their own, knowing that mistakes are the best way to learn? Or are you afraid that they'll get so burnt and frustrated that they'll lose the desire to come up to speed?

When do you choose when to help someone more junior then you and when to stand back and let them learn through their mistakes?

+1. Very good question. Spoon feeding helps no one, but then letting someone flounder is also a big fail.
–
Steve HaighApr 13 '11 at 21:23

1

Don't forget that you can't always do stuff by yourself, sometime you have a problem or an error and you need a fresh mind to solve it. And btw if they lose the desire to put more effort, that's maybe they don't really deserve to be educated. You can't spoon-feed a brain, that never works. I often ask question that my teachers can't answer for a lot of reasons: for some reason I have some kind of always hungry curiosity that keeps me not doing my work until I know a lot. beware of those kind of students, they'll not suck only your time, but theirs too. On the bright side, I'm more lucid...
–
jokoonApr 14 '11 at 11:57

Do not write their code. Show them yours. Give them advices (if they want to listen).
–
Kamil TomšíkApr 19 '11 at 5:58

13 Answers
13

At one of my jobs, I was both learning and teaching(because I of course don't know everything, but I know more than some)

Do not at all costs lay your hands on the keyboard. This is frustrating both for you, and the person you are teaching. Even if you give them step by step instructions, when you put your hands on the keyboard it's the equivalent of giving them a piece of code and saying "this fixes it".

In what I've learned:

Don't type the code for them

Try to teach on their level(if they understand the syntax, don't explain it to them. This will just bore them; instead teach the classes/functions used)

Don't ignore them or say "figure it out on your own". What you'll end up with is them coming to you later except for now the 3 lines of code they had problems with, is now 50 lines spread across 8 files trying to work around the problem.

Teach them to learn on their own. One of the best ways is tell them to use stackoverflow. I sometimes, even knowing the answer, if they asked me. I'd say "well, I'm going to ask this question on stackoverflow". and I'd give them a link to the question. Take a coffee break and look at some different code. When they came back asking "so how do I fix that problem" just tell them to look up their question on SO(using the URL you gave them). I've found that the masses are usually a better teacher than I am.

When they copy and paste code from the internet and ask why it doesn't work, ask them to explain what each line does. If they can't, then tell them to research the functions/classes used. If needed, provide explanations for the class and functions

Conduct code reviews to make sure they are solving the problem, not just working around it for it to show up later.

Be nice. When someone is just starting out in your codebase with no documentation, don't just tell them to read the source code. Give a summarized high level overview of the function in question. Or, better yet, start writing documentation :)

Be humble. Don't BS about the problem. If you don't know it, say you don't and help them look it up. Many times, just knowing the domain enough to know what keywords to search for is enough help for you to give them.

+1 for "Don't type the code for them" to which I would add: manipulate their keyboard so that pressing Ctrl-V gives an electric shock which force is proportional to the number of lines in the clipboard. :)
–
IngoApr 14 '11 at 9:15

Wow. I did not expect to get this many upvotes lol
–
EarlzApr 14 '11 at 22:49

2

I guess this is the most important thing: "Many times, just knowing the domain enough to know what keywords to search for is enough help for you to give them." -- been there (as a junior)
–
JCassoApr 15 '11 at 0:13

"Teach them to learn on their own.", I definitely agree.
–
Steven MouJun 30 '11 at 15:24

+1 For the use of SO. On top of getting varied opinions, the answer is also recorded for review later. I find that not everyone retains the knowledge of a solution as well.
–
ChrisJul 10 '12 at 12:46

+1 for asking questions. This is surprisingly an amazing way to teach. I can't remember where the article is, but somewhere a teacher taught a bunch of 1st graders binary addition and subtraction by asking only questions.
–
EarlzApr 14 '11 at 3:23

-1 for not directly answering the question... +100 for providing an excellent answer to the underlying issue of mentoring :-)...
–
NewtopianApr 14 '11 at 5:09

I have learned to help them architect and stop there. Pick the right tools, draw up a general design to a complex problem or two, and let them go at it. If they come back and ask for advice, give it to them in small chunks. If they don't, let them be.

You are totally right about the "burnt and frustrated". They will be exactly that if you micro-manage or nit-pick. Finally, it helps a lot to establish a friendly working relationship with your co-workers. The time spent gaining trust and mutual respect will pay for itself 10x over.

On the other side I once worked with somebody so lazy that every time they needed to remember the parameters for an API they'd ask me instead of looking it up themselves. Drove me crazy: they could look up memcpy just as well as anybody else - if they wanted to. In those days we had printed copies of man pages. I ended up handing the book over and saying "for chrisakes look it up yourself!".
–
quickly_nowApr 14 '11 at 3:10

1

@quickly, or "I'll help you with this simple thing when I have time" and then come back to it ... later...!
–
user1249Apr 14 '11 at 5:32

I help them when I really need things to be finished quickly, when it's clear that they've hit a brick wall, and when it's clearly unreasonable to expect them to figure it out without help. If, however, they haven't put any time towards something, then it's better for them to attempt it first.

As far as taking the "fish" instead of the "teaching to fish", the best way to do that is to not solve people's problems for them. Give them ideas and let them run with it. If they run with it, and fail, then help them more. If they succeed, even better.

If they are a good programmer they should find a way to get it done his/herself. Now in a situation where it is nigh impossible to find information or a solution to a given problem lending a helping hand is seemingly within reason as long as you keep it within reason. Don't spoon feed them the answer.

Perhaps as an example I am 18 and have been learning for years now on my own and have written some crazy things including my own compiler and I am self-taught. I only seek help with things I really am stuck on (as in I have been searching and experimenting for at least a day but to no avail). I would also like to provide a counter-example: In a programming class I once had a student ask me to debug code he hadn't even compiled!

Essentially a good programmer, even a junior one, should be able to experiment and research solutions to most problems.

Giving people ideas at the start of their work is often a serious boost to productivity even if they're senior people. In my experience, in a business environment it's better to ask for help after an hour or two rather than after a day or two, because eight hours of someone's time is too much money for a question that someone else may already know the answer to.
–
jpreteApr 13 '11 at 21:32

5

But remember, it is your client that is paying for your time! Would they be happy with you spending a day researching a solution, that could have been solved in 15 minutes by asking a senior developer?
–
Adam HarteApr 13 '11 at 22:36

3

In a business environment I suppose you would need to ration your time accordingly. A day just wouldn't cut it. However I still think solving problems on your own will benefit you as your problem solving skills should increase. In the end you can pay for it now or later.
–
Glenn NelsonApr 13 '11 at 22:51

1

@Adam, question is if the senior developer should be asked or ask himself. This is after all a learning process.
–
user1249Apr 14 '11 at 5:35

I've recently started using the pomodoro technique. As a result, if I can't answer a question without breaking my train of thought on my current task, I have started asking if I can postpone an answer until the end of the pomodoro, an average of around a 15 minute delay. An interesting side effect of this I have discovered is when I drop by their desk to answer the question, they have often already solved it on their own. If they haven't, at that point I am much more prepared to give them my full attention.

This isn't school. It's not cheating if you quickly provide a fact they could eventually find on their own. On the contrary, it makes good business sense to save them time, and in my experience skills are sharpened very little by trial and error compared to a mentor giving you frequent small pushes in the right direction. I'd rather them learn 10 right ways to do things with my help than 9 wrong ways and one right on their own.

If something can be easily looked up, teach them how to do so. On the other hand, if it's something you can only know from experience, like which files to investigate for certain bug symptoms, I see absolutely nothing wrong with just giving an unexplained answer.

Conversely, more subjective things like architecture guidance should always be accompanied by the reasoning behind it. For one thing, the junior developer has thought a lot more in depth about their specific task than you have. Talking it through makes sure you aren't jumping to conclusions. For another, it keeps them from blindly applying rules to future situations where they might not apply.

I can only think of one case where I outright refused to continue helping a coworker, and it was after spending a couple hours explaining something multiple times and going through several examples, after which she literally still didn't know the next statement to type with some very leading hints. At that point she had little hope of keeping her job without some serious relearning of fundamentals, and sure enough she only lasted a couple months.

I will mentor but I walk away if they want me to do their job for them. Typically just some advice on how to solve a problem, or re-wording the task description can go a long way. Even just telling them the words they should be using in google can be enough help. 2 minutes maximum.

I stop helping them when they come back with the same question for a third times.

I tell them I'd be glad to help them but only if they help themselves first. From there either they go seek another pond to fish for free food, in which case they usually get fired a short while after. Or they work at it and hit the jackpot when they come back for more... that is more stuff to learn rather than more of the same !

If we're dealing with a critical production support issue where response time is important, then I would actually provide a lot of help along with a lot of explanation so they could learn the issue.

If the deadline is less sensitive, then complexity becomes the driver. You can, of course, help newbies out a lot just by assigning skill-level appropriate tasks, but if it's something that can be resolved through research, then I agree with the other posters that guiding them without giving the exact answer is a great approach.

If they ask questions that are easily answered by looking elsewhere, then I steer them to doing their own work. Along those lines, if there's a process or solution that's pretty rote and there's little value in making them slave for it, then shame on you if you don't have a wiki handy for them to check.

When it comes to transferring domain knowledge that is custom to the business, then I don't mince words. Lecture it straight as soon as possible. Newbies need that to help with everything that comes later. There is no such thing as being educated about the business too quickly or too easily. I had a boss once that played all kinds of tricks for an hour trying to lead me to an answer. I was brand new, didn't know anything about the app or the business yet, and I was dealing with a production support issue. I wanted to scream, "Why are you &#@$! playing #@&(*$%! games? Users trying to get invoices out are waiting for an answer!"

I think the first thing you have to ask them before helping them is have you investigated about this? if yes ask them what they have found out and point them in the right direction. Investigating it is often undervalue but is one of the best practices i have learned, finding information on what you need gives you the power to learn by yourself, also it will make it clear that they have to try first.

If the problem is more complex try not to tell them what to do but share some ideas, ask them how do they think they could approach the problem.

If they have no clue then try to break it down to a very basic level where you don't give away all the details but describe the solution sufficiently for them to try, there are very helpful tools for this like algorithms or flowcharts.

In conclusion, try to guide them without interfering with the learning process, always helping them will make them depend on you for every task then are assigned, that will take your time and is counter-productive.

I avoid helping on simple things such as syntax which they should know ;or if they dont know they should be able to understand on their own. If it is something more complex, I dont mind explaining once.

When It comes to things like explaining the process, or our organization'/projects coding standards etc, I use the three strikes rule. I really think that a person is lame if he has to be explained things three times over. In fact that is also one of the criterias in our appraisal.

A lot depeneds on the learner. I expect them to pick up a few things on their own. If they come up with :" I faced this problem, I tried A, B and C methods but I couldnt solve the issue", I will help them. If they simply come up with "Im facing this problem" and havent done anything I will ask them to go back to the books and look for a solution.

As a newbie programmer myself (about 9 months in my current job using mostly Perl and SQL and with a) no knowledge of Perl and b) a few months of tinkering with SQL before this job), when asking programming questions, I try to show what I've done thus far, or in the case of something not working (and being difficult to debug), where I think the bug might lie. When possible, I've sought to learn how to fish.