Okay, I'm new to Perlmonks so my comment is mainly related to me being the "One Asked Perl" in my current workplace, and helping friends with programming in both Perl and C++.

Essentially, I try and help with the lightest touch I can whilst keeping them somewhat motivated, and also keeping deadlines in mind.

If I can get away with a simple, "Look in Programming Perl, it's somewhere in Chapter 5" then I will, or if it's a case of looking at their screen and seeing they're trampling all over global variables, then I will just point that out.

Let them make their own mistakes, where practical. A coworker of mine has been writing Perl recently, and being mainly a Java/Sysadmin type viewed Perl mainly as a Shell-script replacement. Result? No 'use strict', no '-w', no modules.. when he first asked for help I commented on this strongly and he claimed they slowed him down. Don't think he claimed it after the first two days of looking for a trivial bug though (%blankHash = {}.. ouch).

On the other hand, where the code was required to be bullet-proofed since it was going to be a main part of a project I pretty much recoded most of the important parts, and commented on why. I simply wasn't going to let Perl take the knocks for bad coding methods, this place is enough of a Java-house as it is.

In a recent example with a friend (C++ thingie) where the deadlines were exceptionally strict things started with gentle hints in the right direction, then progressed to a 'Baby steps' breakdown (Loosely based on my experience with Pair-Programming in an Extreme Programming environment) where we'd discuss the next step and they'd implement it whilst I was working on the next few bits in my own version (Which they didn't see until they had their own, and then only as a "Here's how I'd do it"..) in order to make sure I knew what was happening. Eventually things really set in and I was throwing entire, commented, code fragments at them and saying "This will do it, understand.. ask me if there's any questions". This was the point where to meet deadlines I was the one doing the code.

Essentially I don't think there's one answer. It depends what they're coding, how vital it is (Especially in a work-support environment), the results of it going badly.. even if the management sees this is a badly-bugged piece of work and blames Perl, and, most vitally in my opinion, if they're actually willing to listen.

In the examples above my friend listened, so I'm more than willing to help them again although preferably with looser deadlines and thus less intense help.. but the work-colleage doesn't listen, still views 'strict' and modules (!) as things only Perl wizards use, and so I tend to take over his code more and more, whilst making sure people know I do this. I don't want him to be in the situation of breaking the systems by a badly-coded Perl script. I explain, but when it seems he's not listening then I over-rule.

Frankly, I'm not going to waste my time on trying to teach him when he won't listen or care, but I'll spend my time on his project in order to help the business. To do less in the current economy would be laughably stupid.

Okay, that's my first (Admittedly overly-long) post here dealt with.. I'll go back to lurking again now.