Front page | perl.beginners |
Postings from August 2009
Re: Perl "expert"
From: Steve Bertrand
August 20, 2009 16:06
Re: Perl "expert"
Message ID: 4A8DD6F6.email@example.com
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.