develooper Front page | perl.beginners | Postings from August 2009

Re: Perl "expert"

Thread Previous | Thread Next
Steve Bertrand
August 20, 2009 16:06
Re: Perl "expert"
Message ID:
Shawn H. Corey wrote:
> Randal L. Schwartz wrote:
>> This is what makes me trustworthy here.  If you want this kind of
>> respect, do
>> the same: if you've actually *tested* a solution, say so.  If you haven't
>> tested it, ask yourself if you want your trustworthiness tested
>> instead. :)
>> And if not, say, "I *think*..."
> True but I don't think one simple statement is enough.  Back when I was
> just starting someone told me how to talk to the press:  you say one
> thing, you say only one thing, and you say it over and over; then they
> might get it right...but don't bet the farm on it.
> If you post untested code, clearly say so, both before and after it.
> Repeat what you're saying, over and over.

Does this fall in-line with what I've heard from military commanders
(over and over)?:

- tell them what they are about to hear
- tell them what they need to hear
- tell them what they just heard

> (And I'm not betting if anyone understand this. :)

I believe I get it.

This thread almost seems like a list charter being hammered out. _As a
newbie_, I'd like to ask:

Is it appropriate to reply with code that I know for fact works, but
rely on the senior members to help catch possible missed edge-cases and
optimization issues, and essentially turn my response into an implicit
code review? What 'label' would I pre-declare the code with in this
case, if any?

I like to read the posts, take a break from what I was doing at the time
to put some code together for practise, and then literally copy/paste
the working code verbatim from the SSH terminal directly into a new email.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About