When do you not give help to less experienced programmers? [closed]

Question

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?

Answer 1

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.

Answer 2

Socratic method, i.e. ask them questions that lead them to think in a positive direction

[this is useful even when you don't know what the problem is, much less the solution]

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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 !

Answer 9

I think context matters.

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!"

Answer 10

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.

Answer 11

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.

Answer 12

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.

Answer 13

I stop helping in the following circumstances:

• If I am being used to channel Google/Stack
• If I have provided adequate documentation and comments, and they are shortcutting the RTFM stage
• If they are a dirty, no-comments, "I'll hack this in now and come back to it later" &&£>!$

If I haven't provided adequate docs, or they're working with a tool/class I've authored, then it's my responsibility to help them