Personally, I figured out a long while back that if I can't summarize the problem in one or (at most) two sentences, I probably don't really understand it.

I often ask people asking for help in EFnet's #perlhelp to describe the problem in 12 words. This makes answering questions much easier, if only because when shortening their question they often realise they already know the answer :)

12 words is a rather small limit, but this is necessary to force them to abstract it and leave all external factors that have nothing to do with the problem out. It also helps people learn jargon.

So far, most questions that couldn't be summarized in 12 words or less turned out to be composed of multiple related questions or to be about some very awkward program design.

Yes, I do think even questions should be refactored when possible.

(And it can of course be 13, 14, 15 words. But if you say 15, you get 20, and that is too many.)

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

A typical scenario for me:

I'll first go over a problem mentally and do some simple debugging. If that reveals nothing, and if I have any inkling of an idea what my problem is related to, I'll try `perldoc'. If that fails to give me anything or if I feel I need a better explanation, I'll do a 'Super Search' here. If I can't find anything useful here, I'll Google for it; usually doing a 'group:comp.lang.perl.misc' search on Google Groups first, and then a general web search thereafter. Finally, if I still can't find anything, I'll post a question here. Many times, just getting my question/problem out of my head and onto something in front of me will reveal the answer.

I'm a musician, and not a programmer, by trade. I program in my spare time because I enjoy it, so I don't have the luxury of asking a co-worker, and none of my friends are programmers. This leaves me with only documentation and the internet for assistance.

Call me old fashion but I hit my Perl books first which more often than not resolve the issue. If not, they usually show me how to better put together the question. Then I Super Search my question. Rarely do I need to post a code question

coreolyn

What I tend to do, is sit back and listen to some jazz, and think about the problem from an "outside perspective", like "how would an advanced space alien view the problem" ? :-)

It usually comes down to building a "mental blackbox", which processes information. Then I define what information is available as input, and what is the desired output. At that point, the question is formulated.

Then it just becomes a question of the "mechanics of the internal blackbox functioning".

Then I start slapping together snippets, setting up feedback loops, and whatever is needed to process some typical sample input to give the desired output. Then I start testing for the "edge cases" of "possible, but not probable input"; and make code modifications to handle them.

When I'm done, I have a big heap of spaghetti code. :-) But I understand it :-)

Then I like to sit back for awhile and let the spaghetti cool. As it cools, I seem to get "serindipidous inputs" from "the world in general" as to ways of improving the blackbox functioning. This is a great source of mystery to me. Sometimes I'll be listening to the radio, and a "word" will just "pop out" at me, triggering a new insight into how to make a code improvement. Sometimes, it will be in the "Newest Nodes" right here, where someone will ask a question, which immediately translates in my mind into a code improvement.

It could just be my "sub-concious genius" trying to get a message thru to the "concious-dummy at the controls", but too often it is hard to believe it's coincidence, and I often "look over my shoulders for cameras".

Well thats my "zen-psychic" method of problem solving. I know that the modern school system discourages this way of thinking, but in some weird way, it makes the programming FUN.

One thing I think is important is that the posters should try to avoid wasting people's time, not in posting a "trivial" question, but in posting a less thought through question, especially not "here's a mess I have, figure out both the question and answer for me." This is not to say there are no vague questions, one can usually tell the difference.

At work, when I have a question, I usually just yell across the cubicles, instead of researching first, because I find that people who do know actually know more than just the answer itself. I'd like to do the same thing here, but am aware of the value of people's time. So it's a balance.

When I first got here I read the Tutorials, esp. the stuff under "Welcome to the Monastery", of which 3 meantion questions in they're titles.

1. Search Google for a related example
2. Search Google for keywords that might be similar
3. Search here for a tutorial or example
4. Search perl books
5. Consider posting code here for help

Frankly, I hesitate to post problems or new topics here. There seems to be a strong reaction to posts deemed "trivial" or a waste of time. That makes me wonder if any question I'm considering is actually "trivial" and not worthy of posting.