How long should it take to write an SF question?

Question

Apparently, I have form for not asking all that many questions on SF. Re-reading that meta question, I was struck by sysadmin1138's observation that

My 'virtual question' count is a lot higher than my actual question count for this very reason. I get about 2/3rds the way through writing up a good SF question when I find the answer on my own.

which mirrors my own experience, and certainly finds echoes in many of the other comments on, and answers to, that meta question. So it seems to me there are at least two different ways to write an SF question.

I can bang out a five-line precis of the problem, and hit "post your question". I may or may not have done some research beforehand, but if I have I fail to mention it. If the site suggests an obvious duplicate, I may spend two minutes checking it out, but I don't waste more time than that on searching for previous questions that might fit. From deciding to ask, to posting the question, takes about five minutes.

Or I can carefully summarise the salient features of my problem, then show research I've done, what I learned from it, and how it didn't help. I can show other SF questions I found that I thought were relevant, which answers I tried, and how my results differed.

Clearly, the second question is more likely to produce an epiphany, and even if it doesn't, it's easier to answer. The problem is that there's a Dunning-Kruger effect operating: those who don't know how to write good questions don't know that they're not doing it. It occurred to me that the time taken to write a question may be a partial proxy indicator of whether due diligence has been done.

My question here is: how long, in your opinion, does it take to write a good question? Between deciding to ask a question on SF, and posting that question, how long should I expect to spend writing the synopsis of my problem, possibly including diagrams, and the summary of my research? I know I'm to some extent asking the length of a piece of string, but even then, few strings are 0.3mm or 1.6km, so some answer is possible.

Answer 1

It takes me a long time, much of it lost in:

• Scrubbing the company-specific details out.
• Formatting it for legibility.
• Figuring out the show my work parts, and how to summarize it effectively.
• Deciding what the last sentence ending in a ? will be.

Which I did recently over on SO. As mentioned before, often I'll get to bullet-point 3, when I'm renavigating certain failed-before-now avenues to be sure I did them, when I'll find a nuance I missed that actually fixes it. Coincidentally, back when I was dealing with hardware and support contracts, I often went through the same procedure before committing to being on the phone for 90 minutes. Especially if I had to talk my way past the Tier 1 script-reader first.

It's not uncommon for me to take half an hour to type something up. That's not all typing time, that's futzing with markdown along with checking my notes and unavoidably looking at my question in a new light. It's that last part, explaining it to an audience looking for an excuse to flag it, that gets me my answer most often.

Answer 2

You may not ask many questions, but you write a lot of answers.

I would expect that you can write a question that is well received with a similar amount of effort as compared to what a good answer takes. (As long as you don't count all the frustrating time you spent on researching your problem before you admitted defeat and decided on asking for help here.)

Sometimes that will only be 5 minutes.
Another time your problem may need a lot of polishing and detail to phrase it as a good question. But if you need many hours to write it, who will read it to conclusion and actually answer?

Quoted from: How do I ask a good question on Server Fault?

"Good questions are clear, concise, and complete."

They do not need to be long.

The highest voted questions of the last two weeks is this one. To me it looks like one that was written up in less than 10 minutes, but regardless it still hints at more than sufficient prior analyses to already have found the root of the actual performance problem and followed by a valid request for guidance on how to address that.