Hey guys, I have a question, which I now really have to ask you...
This has been bothering me for a long time,
but since this node
I feel compelled to get your opinion.

In my current day to day job I do Network security/management,
and since there are not many coders at the company I work for, I help people out who are struggling with their code.

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 ?

Like in the link mentioned above, I have given advice to people
that did not reflect my own coding style; Just pointing
them
in the right direction (as mentioned in that artice,where I
advised the person to add code to show why the rename was failing)
While I KNOW they take a whole wrong aproach.

Yes, I admit, sometimes I DO take over, and I code it in
my own style,
pointing out what I`m doing (and smiling back at the blank staring faces),
but is this right ?, wouldn`t it be better to help people a bit further,
let them make their mistakes, and help at the next problem that is
encountered, or do it right straight away, and KNOW that the only
thing they will do next time is copy my code, and continue on their
merry little way, not knowing what they`re actually doing, and why
they would have done it wrong.

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.

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 ?

In the thread I mentioned there were other people giving a NEW solution,
but non used the "rename or print 'yadayadayada'" method.
Whereas caillte first mentions the new problem: Uppercase letters in the path.
I think this is the best method: showing the user the problem

BECAUSE of the "or print" the poster (in my opinion) should have enough
information to solve the problem him/her self (in this case he/she didn`t/couldn`t).
But still just adding something simple would help him/her in the future:

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.

I know I keep referring to that exact node, but I hope you guys can
see the real problem I have:

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

One last thing, I can`t keep myself from saying this :)

If what tachyon replied to my post was meant for me (which I think),
and not as an indication to the first poster, he was completely right,
it was very wrong code, but (except from the "or print" and skipping
the . && ..) It wasn`t my code.

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.

Very well said, ChOas.
I saw such node yesterday, and I realized what was happening. You quoted the code that was given in the request, just fixing the most obvious thing but retaining the design faults, for which you got the blame.
I fully understand your feelings.
I always have the same doubts when answering questions. Either I point out the flaw, without code (missing this, double that, etc) or I recode using my style. At least, if I get the blame, I am blamed for something I have done.

Sometimes, though, the code given is just too much and I can't recode everything. In these cases, I list my assumptions ("provided that you are reading from STDIN and using strict and your data is not bigger than ...") and provide an "untested" snippet.
As for taking over the script, as you ask, I try not to do it, unless the problem is very clearly defined and no side effects are in sight. Modifying other people scripts can lead to cargo cult problems1. If the user misunderstands what you've done, he/she will get into trouble and then once again you will be blamed.
If I can't give a clear solution, because the original code has more problems than the author is asking me to fix, then my usual choice is to provide a sample script. Something that works, that runs smoothly, gives results and addresses the main problem only. Therefore, you can't cut-and-paste into your script if you don't undestand it. In this context I am free of using my code style, giving some explanations when I feel that something could be difficult to get.
My purpose in writing an answer to a SOPW request is to give something useful, avoiding to get the user in more trouble than she/he was in before asking.
Thanks for this interesting insight!

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 :)

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:

OK! You've heard from the masters, please listen to the pleas of a novice.

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.

++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.

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.

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).

Unless you preface broken code with This Code Is Broken you shouldn't post it.

No one is helped by fixing one thing and leaving others broken (as was the case with your situation.) If you are going to take the time to help, help all the way. Or isolate the specific problem you are addressing and post the new working code.

That's what I (currently) think.
--
ellem@optonline.net
There's more than one way to do it, but only some of them actually work.

He who knows not and knows not he knows not is a fool. Shun him.
He who knows not and knows he knows not is blind. Lead him.
He who knows and knows not that he knows is asleep. Awake him.
He who knows and knows that he knows is wise. Follow him.

When I respond to anyone here, or anywhere else for that matter, I do so to benifit myself as much as them. I have found after 10+ years of coding and working on systems, that I no longer think like a newbie. I just can't. Is this a problem.. well.. yes it is, because I write code and programs for newbies. I would have to guess that 80% of my code is used by people who lack a greater understanding of what it takes to write code or even write a document in Word(TM).

This place keeps my mind fresh with the newbies(ie.. "oh yeah I remember when stuff like that use to baffle me as well") and also learn some new ways of doing things.

So, how and when to respond? The question still is answered by what do I need from their problem. Can I explain the solution without using code at all? There's a challege for me most of the time.

One thing I don't do, and this is just my person feelings on the matter. I don't "lead" people to the understanding. They don't get it, and they are frustrated as it is, most of the time, so I just lay it out for them. Besides, I start to feel like that wise knight in Monty Python and the Holy Grail "And what else floats in water?" I just give it to them and work on my delivery skills. I have found that if I can explain something clearly, My life is often much nicer.

There are those who don't get it and won't get it, and I'm not responcible for that, but I am responcible, or at least I feel responcible to be as clear and effective as I can.

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.

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.

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.

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.