I think the big problem (which is difficult to solve on Perlmonks, especally with new users) is knowing who you are trying to help.

Some people just need a little help: even if their style is different from yours it is not that bad, and a little hint (such as reminding/showing them how to print error messages) will be enough to get them to solve their problem and improve their skills.

Other people, while asking for an answer to a specific problem, show code that exhibits many more problems. To those I think it is worth mentionning the most glaring ones, along with again some hints, at least unless they show they belong to that last category...

...people who really don't get it, and who don't seem to be interested in improving their skills. They just want their ugly code to be fixed, or a canned script that solves the problem. Then it might still be worth explaining what's wrong, less for the original poster and more for others who might be reading the thread, but I admit that I often feel much less incentive to do so, as I know most of the advice is ignored by the person I am trying to help.

But really, thinking that you are not only answering one person but also helping many others who will be reading you, helps staying positive. And if you don't feel like it, you can always ignore the thread and let some other monk help... while you help someone else.

 _  _ _  _  
(_|| | |(_|><
 _|   

Question is: When do you decide that the person is off by a little,and try to give him a hint (retaining the faulty code in his program,that you DO see, but not addressess the problem) and when do you rewrite the code ?

Only rewrite the code when you think you can learn something from doing so. Otherwise just point them in the right direction and allow them to discover the answer for themselves. Either way the other person has the opportunity to learn the same amount.

Consider the (fictitious ;) example of someone who posts code on this site. The code is absolutely horrible, no strict, no warnings, flawed param parsing, doesn't check open calls, and so on. Do you rewrite the code for them? or do you point them to related resources on good coding practices? The only reason I would rewrite the code is that I think I could learn something by doing so. Even so, it could be argued that by posting the code I'd be doing them a disservice, so definately don't spend too much time writing code for them if you won't learn anything from the process.

I started out in the world of perl a little over a year ago. I knew nothing. However, I knew perl was a useful tool. Little by little I am getting much better at it. I often pull old code and work it into my new code: often improving on it.

This site has been an excellent resource and has helped me out of many jams. I know the people here know there stuff well and that is why I seek advise. I want to get better and do as time goes by. Help those who are willing to learn and want to learn. Be cautious of those who just want you to write all their code :)

Simon

Hi ChOas you might note that what I posted at 19:04 (an hour before caillte for what it is worth) indicated the bugs in your posted code.

Should I give you hints, or should I write your code?

This is completely your choice. Your hint (check the result of rename and print the error in $! was excellent and got a ++ Give a man a fish and he will eat today. Teach a man to fish and he shall eat forever. On the other hand your example code was broken and got a -- When I noted that it had quite a high reputation it also got a direct reply to you. I feel if you post code it should work properly otherwise it does no one any good

Trying to rename a file, and failing to do so (for any reason), should result in an error message, and should not be quietly dismissed.

You are of course correct. While throwing an exception with die is one way of dealing with errors it is usually not a good way in a CGI. I usually have a die_nice() function in my CGIs that looks something like:

sub die_nice {
    my $real_error = shift;
    email($administrator, $real_error);
    log_error(scalar localtime, $real_error);
    tell_user('Sorry the system can not respond to your request due to
+ routine maintenance
              <br>Please try again later')  # yeah, right!
  exit;
}
[download]

One problem with a simple print is that without a valid header a CGI will fall over with a 500 internal server error.

You seem to have taken it a little to heart so may be amused to find that I have posed similar questions to yours at What's a fair thing? and So it's homework - so what? All the best and keep up the good work. ++ for this one BTW.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

Please don't write my code. Help me with the problems that I'm asking about with an explanation. If the problem is a bit complex, perhaps you could show me an example or give me a link. I'll only learn if I do it myself.

As a novice, I realize that I may be doing something else terribly wrong besides the problem I'm asking about. If I do this, please tell me what those mistakes are and give me some pointers to help me correct them. RTFM is a perfectly acceptable thing to be told, *if* you can point me to the relevant docs.

Don't write my code, but don't stop teaching me either.

Dave

++dthacker, for saying what I would have said had I been paying attention. :)

A few notes I'd like to chime in: Usually, with any question, there are three kinds of right answers. There's the right answer that shows how but not why, the right answer that shows why but not how, and the right answer that shows how and why.

That is, for question A, there is
• "This is what you want to do instead."
• "That's the wrong method you're using."
• "That causes this kind of problem. Here's how to avoid it."
It's easy to look at the three and guess which is the most informative; it's the last, which tells you how and why. I've found that often times one is left out of instruction to the detriment of the reader, who then is left to figure out "When do I use this?" or "But what does that look like in code?" with some other manual/tutorial/explanation.

From this beginner, please, if you see something I'm doing wrong, don't hesitate to correct me and explain it at the same time. I'm here to learn, and, hopefully, one day teach.

-----------------------
You are what you think.

I agree, in principle. Sometimes, however, the code given as an example in such a case as you describe is riddled with myriad incorrect assumptions, out-and-out coding errors, misused idioms and common mistakes and is so far from my own coding style that after addressing all the above, there's no longer any question to answer.

My own approach to situations like this is sometimes to simply write a completely new code snippet which accomplishes what I estimate was the original goal, without so much as the slightest resemblance to the original, along with an explanation to the effect of, "here's how I might try to do this."

And sometimes (here on Perl Monks, anyway), I leave it to those more adept than I.

dmm

If you GIVE a man a fish you feed him for a day
But, TEACH him to fish and you feed him for a lifetime

Hint or rewrite... Often I re-write a piece of code, assuming the user does have a little Perl knowledge, and knows where to find documentation. On the other hand, when it comes to using modules, I just list some modules that might be appropriate. I try to be helpful in my replies, but I'm not always. My replying style differs all the time, I struggle with the same problem.

IRL, I decide based on the question. If the question is "Why doesn't this work", I point out only why it doesn't. If the question is "Is there a better way?", I often re-write code.

U28geW91IGNhbiBhbGwgcm90MTMgY
W5kIHBhY2soKS4gQnV0IGRvIHlvdS
ByZWNvZ25pc2UgQmFzZTY0IHdoZW4
geW91IHNlZSBpdD8gIC0tIEp1ZXJk

I can vouch for this. I posted some dung-heap of code recently and Juerd simply rewrote my code in a completely diff't way than I had ever thought about my problem and in the process I had to do some research to figure out what it was he/she/it wrote and why it worked at all.

I _want_ to learn Perl, not just get the latest CGI thingy working so I am the person who will take the time to explore the new code. Not everyone is like me/us. This is neither good nor bad, simply different.
--
ellem@optonline.net
There's more than one way to do it, but only some of them actually work.

One thing you might consider is putting together a workshop (say about 3 hours) for your coworkers. Get management to sign-off on the idea so it is an official workshop.

Spend a good deal of up front time going over basic coding practice and style (consistent indentation, strict, warnings, checking return values) then move into more specific areas. Compile up a list of example code (or pseudo example code) from problems you've helped with in the past --- so the examples are targetted at the kind of things they are actually doing --- show the problem code (no names), and your version, and most importantly, why and how your version is an improvement.

You may even be able to coax management that a once a month afternoon programming workshop is a good idea. These wouldn't necessarily be be in a presentation format as the above, but more open discussion of current projects and troubleshooting code (but always be prepared with your own examples of code that needs improvement, kind of along the lines of MJD's 'red flags and repair' articles on perl.com --- you'll need these if no one brings any code of their own, or perhaps just to get the ball rolling). Such a monthly workshop gives both your coworkers and yourself a good chance to keep learning and improving, and can certainly improve productivity (that may help you sell it to management). If management won't bite, see if your coworkers are interested in informal (voluntary) version of the same. If they aren't interested in putting in some time and effort in self improvement, you needn't feel compelled to keep helping them now (imho).

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.

Time and time again I am stumped by the following problem: WHEN do I stop helping ? when is it enough, when do I get the feeling I`m taking over their code ?

...

Don't get me wrong here, I really try to explain the problem with their code, and the reason why I would do it differently. But these people aren`t coders, they`re application managers, writing little tools to make life a little easier on themselves.

As I see it, there are (at least) two ways of looking at your problem: the pedagogical ("How do I best teach these people?") and the business ("What's the best way to get the job done?"). (I'm an academic, basically, so I like the first one, but YMMV.) Which way you want to look at the problem is going to affect whether you step in and write someone else's code.

If you're trying to teach someone, it's probably best to get them to code as much as possible, and write code "for" them only to illustrate a new point, or to provide a framework for what they're doing. (For instance, in a machine learning course I took a couple of years ago, we were handed most of a neural networks package fait accompli. Our task for that assignment was to write the backpropagation code, not the framework.)

In a business context, things get more complicated. It might easily be worth your while to write a few little tools for these managers, especially if they're trivial (to you) scripts that you can toss off in ten minutes, but that take the managers hours to produce broken code. In that case, it's far better to take ten or fifteen minutes of your time than it is to take two or three hours of theirs, and get a better result.

On the other hand, teaching these managers the basics of good programming might be spectacularly worthwhile. One thing I've noticed about programmers (mostly myself) is that as we learn, we spend more time coming up with ways to get the computer to do our work for us. (Start with code to solve tedious problems, then code to write tedious code, and so on.) Getting consultants and managers to think in terms of automating tasks, and to push the boundaries on what they consider automatable, might be a huge win. In that case, you'd be better off taking a more pedagogical approach.

--
:wq

You should neither give hints or write code for them. You should enlighten.

It has been forgotten many a time here in the monastery, but programming is very hard for some people. Their brains aren't wired that way.

When you see the person is off by a little, just saying "RTFM" is insulting. The reason they are only off by a little in many cases is because they have already gone through a bunch of documentation and it did not make complete sense.

However, just writing the code for them is not a solution. They didn't understand it, so you either tell them to re-read it, or you solve it for them without explaining how.

Generally, it is not a lack of understanding of commands, but a lack of understanding loop logic or variable syntax. Newbies have a terrible time with regexes, and IMHO, the documentation is useless.

Why?? Is the regex documentation bad?? No. It perfectly lays out the technical aspects of using perl Regexes. But the conceptual knowledge of string processing is still beyond most people. (Most newbies have enough trouble with substr)

So, someone who does not grasp the concept of backtracking in regexes asks you a question, or posts one to the group. He's read the perlre manpage and did not understand it, he's done some searches, frustration sets in. He posts his question, and keeps checking for a reply.

Reply 1: RTFM.

Our frustrated user replies with what docs he's read, etc...

Reply 2: Read the section on Vacilating parsed farthings from Bora-Bora.

Hunh?? I thought it should be written like X, but that only generates syntax errors.

And on and on. Look through the monastery and see how many useful responses are included in top two or three responses to a question. (It's less than 40%)

The sad thing is that they're just point-whoring by trying to be at the top of the post and seem to have little time to do much more than be insulting.

Slashdot had "First Post", do we have RTFM?? If that's so, why doesn't Tim just add a script that automatically adds a reply to every post that says "RTFM" and save some of the others some trouble??

I understand that you folks don't come here to just teach people, but if you don't care to light a candle, stop spitting at the darkness. The people posting in the SOPW section are mostly newbies. Some just to Perl, some to programming in general.

"where I advised the person to add code to show why the rename was failing", gee, if he was so comfortable with that, no wonder he asked a group of irritable strangers for help instead. "Uppercase letters in the path. I think this is the best method: showing the user the problem" and explaining why it is a problem.

I personally have 2 programs with a function from Tilly in there. I don't know what it does, I don't know why. All I know is that my old copy_file routine failed on one project. Noone would explain why, so I just took the code that Tilly posted and ran with it. I don't like it, and if I come across this problem again, I won't know how to solve it. (I have since gone to the trouble to dissect it.)

BIG note to monks! You don't have to answer. If it's something that you're going to RTFM someone about, let a junior monk come along and help. I keep hearing "I'm so busy I don't have time to give a meaningful answer." Then make more time by giving fewer meaningless answers.

Besides, I always figure that the folks who "RTFM" all of the time probably don't really know the answer anyway. Perhaps it's enough to say that merlyn and others have never done that to me, and no one who keeps spewing RTFM at me has ever had the solution.

~Hammy
The"Anti-Monk"