|Think about Loose Coupling|
Should I write your code ?by ChOas (Curate)
|on Mar 16, 2002 at 12:39 UTC||Need Help??|
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.
print "profeth still\n" if /bird|devil/;