Lori Nagel wrote:
>   
> I think it is very hard on newbies and
> drives people away from using free software. I remember as a newbie,
> reading things for hours, trying to look something up, not finding
> the information, not even knowing what to ask or how to ask it. I
> would read things, not understand them, and then ask questions. I
> remember going to some irc channels on freenode where I would get
> RTFM. The problem was I didn't really know enough about the subject
> matter to ask smart questions. It took me half a year just to figure
> out how to add the math library into the compiler so I could compile
> some basic C programs from one of the C programing books I have. I
> finally managed to learn it by finding a pdf copy of the Intro to GCC
> book. 
> So basically, it is a document that
> expects people to have more knowledge than they may actually have. I
> don't think it is necessarily bad to try to
> ask smarter questions. I think the problem is when it becomes an
> exercise in newbie bashing where the so called fine manual is 
> nowhere to be found. 
>
>
>
> ----- Original Message ----
> From: Bruce Dawson <j...@codemeta.com>
> To: Lori Nagel <jas...@yahoo.com>
> Cc: gnhlug-discuss@mail.gnhlug.org
> Sent: Fri, October 9, 2009 8:40:44 PM
> Subject: Re: How To Ask Questions The Smart Way
>
> OK. I'll bite.
>
> What aspects of that document do you not like?
>
> --Bruce
>
> Lori Nagel wrote:
>   
>> For no particular reason, I will say I do not think very highly of that 
>> document. 
>>
>>
>>
>>
>> ----- Original Message ----
>> From: Kevin D. Clark <kevin_d_cl...@comcast.net>
>> To: Greater NH Linux User Group <gnhlug-discuss@mail.gnhlug.org>
>> Sent: Fri, October 9, 2009 12:38:52 PM
>> Subject: How To Ask Questions The Smart Way
>>
>>
>> For no particular reason, I will mention that I think that this is a
>> really good document.
>>
>>   http://catb.org/~esr/faqs/smart-questions.html
>>
>> I hope that others enjoy it as well.
>>
>> Kind regards,
>>
>> --kevin
>>  
>>     
>
>
>       
> _______________________________________________
> gnhlug-discuss mailing list
> gnhlug-discuss@mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>
>   

Lori has hit it on the head.  The document reeks of "us and them". I 
taught programming for several years at a community college. I told my 
students that there were no stupid questions. I told them that if they 
asked me a question 5 times I'd answer them every time. I told them that 
I'd wonder about them around the third time they asked but never the 
less I'd answer them.

Working in the industry I found myself working with people at widely 
varying skill levels. My favorite people to work with were those who 
were both brilliant and who had a self deprecating sense of humor.  One 
engineer in particular, our kernel architect was incandescently 
brilliant. Of the 300+ engineers who worked with him, virtually all felt 
that they weren't qualified to carry his lunch bag into his office. 
Instead of being a pain in the ass to work with he was always cheerful 
and made you want to impress him that you had done your homework before 
"bothering" him with your (for him) trivial question. His attitude and 
style made people want to work with him. Other, otherwise bright 
engineers would crap on anyone who approached them with less than 
wonderful questions. Needless to say they didn't get nearly as much 
cooperation as they might have otherwise gotten.

In the engineering field you sometimes hear the term "ego-less 
programming". I have found that those ego-less programmers are quite 
often the best.

So ESR's document is reasonable in terms of explaining why and how 
someone should do their research in order to get better results but the 
tone is borderline nasty.

One other small note - on one compiler project that I worked on, newbies 
were looked on as another chance to get things right.  The newbie, not 
knowing all the ingrained habits of the seasoned developers wouldn't 
understand poorly written or incorrect documentation. They wouldn't 
configure their environment to avoid the build problems which inevitably 
creped  into  project resources. They usually improved the product 
because they didn't know what they were supposed to know...

-Alex


_______________________________________________
gnhlug-discuss mailing list
gnhlug-discuss@mail.gnhlug.org
http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/

Reply via email to