The granddaddy of the " how to ask" documents is probably this one at


It is not always going to be politically correct, or even polite! An example - ".../you/ are one of the idiots we are talking about..." in the disclaimer.

Please do not let that deter anyone from seriously reading the relevant parts. The document is from a kind of "hacker" community who are very willing to share. One should probably look at just what "hacker" means - I think that includes all of us on these lists.

Just the table of contents is a helpful list of suggestions.

And here are a couple quotes from the intro that mirrors Buck's thoughts -

"Despite this, hackers have a reputation for meeting simple questions with what looks like hostility or arrogance. It sometimes looks like we're reflexively rude to newbies and the ignorant. But this isn't really true."

"We're (largely) volunteers. We take time out of busy lives to answer questions, and at times we're overwhelmed with them. So we filter ruthlessly. In particular, we throw away questions from people who appear to be losers in order to spend our question-answering time more efficiently, on winners."

Take time to read the thing to see what the technical term "loser" really means!

The language & attitude may seem stronger, at times, than we like to see on these lists. Nonetheless, it is well worth a good read - even if just the TOC, as I suggest above.

I know i can always ask better questions - I've tried to do just that in recent posts here. And have received replies of clarification and the like. That is all helpful, and I think those on these lists for their willingness to take their limited time to participate.


On 7/8/2014 2:31 PM, Buck Calabro wrote:
...and really enjoy all the information that is passed between users, however I have been reluctant to post anything in fear of being blasted.
That makes me sad. The purpose of this list is to share knowledge.
There are practical limitations as to how much knowledge can be shared
via email; we can't really /teach/ someone from the ground up. The time
investment would be enormous on both sides. Much etiquette on 'How to
ask questions' springs from that fact.

It's something of a paradox that the hardest question to answer is the
easiest to ask. An example: 'What is the best way to read a record?'
Read? CL? Rexx? RPG/36, RPG III, RPG/400, ILE RPG? Cobol, Fortran, C,
SQL? Java via JDBC, Excel via ODBC, Crystal Reports? Best? Fastest to
execute once, fewest lines of code, easiest to maintain, fastest to
execute for a million rows?

The easiest question for me to answer involves enough code and sample
data that I can recreate the situation on my machine. That's usually
the hardest thing for the asker to do, because it means he has to
extract out the bits that aren't working, set up a dummy table and then
cut and paste the lot into a question (although code.midrange.com can
help with that; post your code there, then paste the link here).

So help us to help you. If you have a question, show your code and
sample data that makes it fail. It sounds weird, but the more specific
your question, the faster you'll get an answer. I've been on this list
since the BBS days, and honestly can't recall complaints that an asker
gave too much detail in her question. The list is far more likely to
complain that it takes forever to tease out every last morsel of
information needed to understand the problem.

I've taken too much of your time as it is. I hope this helps to
encourage you to ask - or answer - some questions. The community draws
its strength from those who actively participate.

This thread ...


Return to Archive home page | Return to MIDRANGE.COM home page