How to ask questions

Communication, it all comes back to plain old communication.  So many questions I receive assume way too much.  So, I thought I’d write about what needs to be said when you ask questions in any sort of forum.  And what needs to be provided.  That is — what you can do to make it easier and faster to

• Get an answer. The questions with more left unsaid than said go ignored.
• Get people interested in answering your question . It is almost like you are making a sale here!  “Hey, look at my question, I’m obviously interested in helping you give me an answer so pay attention to me”.
• Not get frustrated.  Miscommunication leads to frustration, 100% of the time.

Remember, the internet seems speedy, and it is, but it is very much like a satellite connection.  I have virtually unlimited download bandwidth at home, but it is accompanied by extremely high latencies (turn around time)!  Forums are just like that.  If you don’t supply the needed information up front, you won’t get anything back other than requests for more information!  And then the issue of “context” creeps into play.  We’ll get into all of this in a moment.  So, here is what you need to do (in my opinion).

Provide the Setup data in a useful format

When asking a question on a forum, don’t do this:

ops$tkyte@ORA9IR2> desc orders_temp
 Name                    Null? Type
 ----------------------- ----- ---------- 
 ORDD_ORDER_NUMBER             NUMBER
 ORDD_GROSS_DOLLAR_EXT         NUMBER
 ORDD_PRD_KEY                  NUMBER
 ORDD_CAME_FROM_PRD_KEY        NUMBER
 ORDD_MASTER_RECORD            VARCHAR2(1)
 ORDD_PREPACK                  VARCHAR2(1)

 
ops$tkyte@ORA9IR2> select * from orders_temp;
 
ORDD_OR ORDD_GRO ORDD_PRD_KEY PRD_K O O
------- -------- ------------ ----- - -
7490000    84.24        58709       M Y
…
 206338 -3359.79              54582 N N

8 rows selected.

Because now someone interested in answering your question will have to turn that into a CREATE TABLE and INSERTS.  You need to take the time to do that.  (Cursed NULLS in there make it especially hard).  And if you have DATES in your data — by all means, to_date them with a DATE FORMAT!!!  Not everyone agrees with you on the default date mask!  And trying to figure out if that number of mmddyyyy or ddmmyyyy can drive you nuts.

create table orders_temp (
ordd_order_number number,
ordd_gross_dollar_ext number,
ordd_prd_key number,
ordd_came_from_prd_key number,
ordd_master_record varchar2(1),
ordd_prepack       varchar2(1))
/

INSERT INTO orders_temp
(ORDD_ … PREPACK)
VALUES
(7490000,84.24,58709,NULL,'M','Y')
/
That is how you need to pose this question  — the create table and the insert intos. And make sure it runs, really — don’t just type it in, actually RUN IT on your system.  Nothing more frustrating than a test case that needs debugging before the debugging of the actual problem can happen!

Provide everything you need

Remember, the person asking the question doesn’t have your comprehensive library of utility functions and everything.  In fact, they likely have nothing you have!  Make it self contained, make it stand alone.  The people reading your questions are not compilers!  If you post 50 lines of code and say ‘it fails’ — but we cannot actually run it on our systems, you will be out of luck.  This leads into the next concept, that of less is more.

Less is More

Really, this is 100% true.  Make the example small enough to fit on the back of a cocktail napkin.  Ask someone to debug 500 lines of your code and you’ll get no takers.  Trim the example down and two things will happen.  First, you’ll probably find your mistake yourself, I usually do!  Yes, it is true, if you pare the example way down, you many times will diagnose your own issues.  Before the internet and forums, this was called “debugging”.  First, we wrote really small routines (easy to digest) and second when something wasn’t working — we had to make it small to understand and be read by others.  When I first started developing, I had a 80x24 screen — 80 characters wide, 24 lines long.  The really senior people had 80x32 screens (and they thought they were really hot because of that).  Things had to be concise.  Second, once you do make it small and still don’t see the issue, the odds that someone will actually be interested enough to take a look go way up. 

But Be verbose

In your explanation of what is wrong.  If you say “I did this and it didn’t work, why”, you’ll probably just get a response along the lines of “my car won’t start, why?” – IF you get a response at all.  Remember, from where we are sitting — your monitor is very far away from us and crystal balls only work in movies.  You are very close to the problem, it has probably been consuming your attention for hours if not days.  To the people looking at your question however, it is a brand new thing.  They don’t have your insights and wealth of knowledge surrounding the problem.

Provide the Goal

Don’t post your code, your (failed) attempt and say “how can I do this”.  I get those all of the time.  The question goes along the lines of — I’m trying to get a report that looks like this [example here…] from data that looks like this [output of selects here].  I’m using this query [select ….] but it isn’t working.  Help!

There is a lot wrong with that.  First — make sure to provide the SCRIPT to create the table and data.  Second, when you show the outputs — explain “why they are the way they are”.  Don’t expect the person on the other end to be able to deduce it.  Remember, as just stated, you have been consumed by this problem for a while.  We have not.  What is obvious to you is “way out there” to us.  The assumptions you make, we don’t see them.  Understanding the model (the data model — primary, foreign, nullable, etc) and understanding the desired output is key.  Looking at your attempt that doesn’t work — only confuses us mostly!  It is hard to figure out what you might have been thinking as you wrote it — what assumptions about the SQL or PLSQL language for example you made that were wrong (and we don’t share).  That makes it impossible for us to read your failed attempt and figure out what is was meant to do.

And remember, if you cannot phrase your requirements, state your problem, in text – then you have not thought it through yet; you do not know what it is you have to accomplish!  So, if you say “it is really hard to explain”, that means you don’t understand the problem yourself — time to go back to the drawing board and think about it.  You need to be able to document what this thing is doing.

Context

I’m saying this for the third time.  You have been consumed by this problem for hours, days or weeks.  We have not.  When you followup in a threaded discussion, make sure to keep SOME of the context.  For example, on asktom when I get a question that needs more information — the system sends the person asking the question an email with a link back to the site.  The email says “use this link, I need more detail about <whatever>”.  Well, about one in ten people don’t just add additional information — they replace what WAS there with the new information.  Now I have to send them another email asking for the old material back!  I have no idea what the question was.  (that just made me think, maybe the email should say that and now it does, I just updated the template)

This is especially true in an email trail.  I get lots of email as I’m sure we all do.  When I get an email like “I tried what you said, but it did not work.”  — the only thing I can do is reply with “huh?”.  Leave some context, some bread crumbs in there. 

Less is More

This is not a cut and paste mistake, it is here twice.  People who have read my stuff before will understand this analogy — What bind variables are to application development, Less is More is to providing an example to be looked at. 

Make the example 500 lines long — chances are very slim anyone will look at it.  Make it 10 lines long and everyone will.  Do you really need a table with 300 columns to reproduce the issue?  Or would 5 columns do it.  Do these columns need to have insanely long mangled names (you have to love column names from SAP, they are the best).  Or could short — yet meaningful names be used?

Oh and make sure the example output matches the test case, nothing more frustrating then debugging a debugging session! 

Don’t Assume

Don’t assume the person on the other end of the network connection thinks, feels, defaults things, does things — the way you do.  They probably don’t.  State your assumptions.  Examples should be small.  Explanations big.

And don’t get bent out of shape if the person on the other end asks “WHY”.  Why means “you didn’t provide enough information” many times.  Other times Why means “I’ve been doing this stuff for a while, are you really sure you want to make this mistake”.  Don’t get upset of the person trying to help gives you a piece of advice you think was insulting.  It probably wasn’t.  They don’t know you, you don’t know them.  They have no idea how experienced you are (or aren’t).  They don’t know what you tried (or haven’t tried).  Their suggestion might have been obvious to you (and hence ‘insulting’), but not so obvious to them.  Don’t get offended, until both people know who they are talking to — no assumptions about level of knowledge can be made.  And remember, we all overlook the obvious sometimes – I do, you do, we all do – so sometimes stating the obvious is the solution.  So, don’t be insulted.