There's some marginally useful content buried in that, but wrapped in a pervasive and unpleasant position of "the person you're asking is way more important than you, lowly questioner", and many excuses attempting to justify elitism.
I had never seen Julia Evans' writing on the topic but have read ESR's many times. It looks like Evans' guide is mostly geared towards being considerate of the other person and ESR's is mostly geared towards collecting the appropriate information beforehand and phrasing the question the right way. Both are extremely important for effective question asking.
Regarding the "lowly questioner" dynamic, look at it this way: if you're asking someone a question about their software, you're seeking to extract time from someone in order to extract value from something that they created. Be humble.
> It looks like Evans' guide is mostly geared towards being considerate of the other person and ESR's is mostly geared towards collecting the appropriate information beforehand and phrasing the question the right way.
> "the person you're asking is way more important than you, lowly questioner"
I don't think it's saying that. It's just saying "the person you're asking owes you nothing, is probably very busy at best, and may be a self-important jerk at worst, this is probably the most effective way to ask them for help."
It also, in multiple places, seems to say "but they're not really a self-important jerk, they're just defensive of their time". And in general, it defends elitism and excuses unpleasant behavior.
(There's nothing wrong with being defensive of your time. There's something very wrong with being a jerk about it.)
I'd written a reply to someone commenting on the description of "elitism", but that comment was deleted. So, instead, here's a partial list of issues (both elitist and otherwise), and reasons to not link to or advocate that particular document.
Quoting directly from the document:
> you are one of the idiots we are talking about
> leave us alone and everybody will be happier
> What we are, unapologetically, is hostile to
> We call people like this “losers” (and for historical reasons we sometimes spell it “lusers”).
> J. Random Hacker is quite likely to reply with a uselessly literal answer while thinking “Stupid question...”, and hoping the experience of getting what you asked for rather than what you needed will teach you a lesson.
> Stupid:
> we can't be bothered
> will make you come off like a giggly teenage girl, which is not generally a good idea unless you are more interested in sex than answers
The entire section entitled "RTFM and STFW: How To Tell You've Seriously Screwed Up", especially things like:
> You shouldn't be offended by this; by hacker standards, your respondent is showing you a rough kind of respect simply by not ignoring you. You should instead be thankful for this grandmotherly kindness.
> The same place I'd find it, fool
> J. Random Hacker's response to this is likely to be “Right. Do you need burping and diapering, too?”
> While muttering RTFM is sometimes justified
(no, it isn't)
- Terms like "ruthless" used as praise.
- Numerous attempts to praise lack of basic decency and excuse bad behavior in the community.
- A pervasive "us" and "you" approach to othering the lowly petitioner, despite claiming to want to welcome them.
The above is a partial list of reasons why not to recommend that particular document, and why to seek out and recommend better ones. I've seen people recommend this particular document while simultaneously attempting to excuse it; better would be to write it off as a hopeless bit of elitist historical interest, recommend better documents that already exist, and update any such documents to include any useful information that they might lack.
I can handle a bit of rough and tumble no-nonsense language, personally. I'd like to think most folks attempting to build/repair/maintain systems built by other people can too. Disregarding this document because it's not hand-holding enough would be, IMHO, throwing the baby out with the bath-water.
This is an inaccurate and dismissive description. This document is actively hostile, and revels in its hostility. It's propagating a perspective that it's acceptable to deride and denigrate newbies, that it's acceptable to be hostile and toxic and unwelcoming, and so on. It gleefully celebrates, or at the very least excuses, people who throw around "RTFM" and "STFU noob" and "UTSL". Propagating this document encourages people to think such behavior is a good idea.
We can, and should, build better hacker communities, and this document has no place in those.
> personally. I'd like to think most folks attempting to build/repair/maintain systems built by other people can too.
You might like to think that, but that assumption excludes many people from the community, in a self-perpetuating vicious cycle (where "vicious" is a particularly appropriate word). It creates communities that exclude people who are not like you. And even those who can should not have to. I can cope with such people, but it's painful and draining, so I spend more time in communities where such hostility is not accepted.
You might find if you spend time in such communities that you may enjoy them more as well. Or perhaps not, but either way don't make things worse for others.
The right response to such hostility is "we don't do that here".
Check your privilege. While you may have the luxury, political cachet, or just plain old luck at your job to pooh-pooh whatever open source libraries, applications, or frameworks that don't meet your arbitrary definition of saccharine civility, the rest of us out in the real working world have far more pedestrian concerns.
The ideals you've posited sound pleasant initially, but they bear little resemblance to being able to do real work in the messy, impatient, human-infested world others live in. Would it be nice to eschew the linux kernel, or the openbsd community, because a large fraction of those folks meet the ESR 'busy hacker with attitude' definition? Sure. Would it be career-killing to say "Linus/Theo were curt with me, _how wude_, let me agonize over it on my Tumblr and waste dev cycles finding another kernel/crypto library/whatever"? Absolutely.
ESR's guide is pragmatic, and far more effective at solving the real problem in front of the questioner, than the "pout and shun" methodology you've espoused.
I am well aware that several critical projects have incredibly awful and hostile communities. I'm also aware that a subset of people in those communities actually attempt to claim that their hostility is a feature. That's a bug, and useful to warn people about, and to attempt to fix, and to not copy in any new community. It's not a thing to revel in, excuse, and encourage, lest we end up with more.
You seem to be reading more into that statement than I've actually said. You're also attempting to ascribe a ridiculously patronizing tone that is of course easy to argue against, having been artificially constructed for that purpose rather than representing any actual position I've stated. I didn't say "don't use Linux because LKML is awful"; that would indeed be counterproductive. I'm saying "make new communities more friendly and welcoming than LKML, and don't encourage or excuse being awful to others".
Are you actually attempting to claim the document has no issues at all? Or are you simply trying to claim that despite its issues the document also contains useful information? I'm not arguing against the latter, simply stating that that's a good reason to create and propagate new documents that don't have those issues. If you're trying to claim the former, you've done nothing to actually support that position or reply to the detailed list of such issues.
I re-read it every few years, and if we all spent the time to ask smart questions in every sphere of our lives, we'd all be better off. It's hard to do though, because it demands we expect more of ourselves. Sometimes it's easy to just post a question to the ether than to do the hard work of investigation/research needed to ask a smart one.
He is indeed the master. Much of his advice is timeless. I find myself going back to things every so often. Especially the Eric Conspiracy, which most certainly does not exist.
ESR did it better, imho :-)