How To Ask Questions The Smart Way
Coleman Kane
ckane at colemankane.org
Sat Oct 10 14:16:12 EDT 2009
On Sat, 2009-10-10 at 09:04 -0400, Alex Hewitt wrote:
>
> 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
As far as RTFM goes, have any of you sat down and read some of the
manual pages that sometimes accompany certain families of free software?
Notorious are those from the FSF and the OpenBSD communities which can
reek of the same sort of elitist badgering, for instance FSF man pages'
tendency to very tersely direct the reader to the more painful to use
"info" pages, or OpenBSD's commitment to slam "other unixes"
implementation of tools or APIs.
Not exactly newbie-friendly, IMHO.
--
Coleman
More information about the gnhlug-discuss
mailing list