XYZ Questions

[chromatic]

Looking at sentantae's answer on this SoPW, I wonder if we should consider answering both the direct question and the PSI::ESP generated questions as to what the seekers actually want to do.

Granted, some of the requests are esoteric (think some of vroom's early questions about Pig Latin), but others may be from posters who would benefit from general programming wisdom.

Where do you draw the line? Do you give as much information as possible (I'm usually guilty of this) and hope it sticks, or do you just answer the question and hope for enlightenment somewhere along the line? (Now that I've excluded the middle, let's talk.)

[btrott]

If a request seems a bit odd/off, or it seems that the poster's not really sure what they're asking about, or something doesn't seem to make sense... I generally try to make a guess as to what the *actual* question is. As you (chromatic) said, I often push a whole bunch of possible approaches at the poster, hoping that one might lead to a solution, or at least a better understanding of possible approaches.

[setantae]

Hmm, good question.
If the OP really doesn't seem sure of what they are trying to achieve, then I'd rather get a clarification of their goals, as posting unrelated code can, and often does, further confuse matters.
On the other hand, if the OP knows what they want to do, but aren't sure how to start/finish, then that's a whole different thing.
I do like to see some code in a question, not because I'm overly bothered about people trying to get a free ride, but because it helps show where they are coming from.
As is perhaps evidenced by the small amount of actual hard code that I post, I'm quite partial to encouragement of getting people to try it for themselves, although I'm also wary of leading people down the "What do you mean there's a module for it?! I've been trying to get this to work for x hours!" path.

A good approach may be to refer people to a relevant Q&A or catacombed code..?..thing? where the "guess" resides.

[e-mail]|setantae|www.setantae.uklinux.net

[little_mistress]

This is a tough one. I know it can be dificult to answer a question over the net. Especially a newbie question, but that is the nature of the beast of asychronis communication. It's just a little bit slower.
Personally, many of the questions that I see being posted are questions that i once asked. The criteria that i look for is this, mainly:

• Do they know where they are starting from?
• Do they know the outcome they need?
• What method are they useing to get there?

Chances are if only part three is missing the only need to learn perl, if parts two or one are missing they dont know what they are trying to accomplish, or they are actually a capable programmer and are just frustrated, or they need to learn to how to program. I think any one of these questions problems can be addressed in this forum, useing perl of course.

Be that as it may, I think we will find that the ones who answer questions here are bound to fall into differnet groups:


• those who love to teach teachers
• those who love to tech
• those who love to hack

surely does that not bring together the "ends" with a good solid "middle"?

[setantae]

There was some decent code here..don't suppose you can put it back?
Don't let a negative vote get you down.

gods note: this note was originally a direct reply to 6705, which has been not just nuked, but deleted without a trace. It has therefore been re-parented so as not be orphaned. The title was also modified to put it in thread, as the title it had was blank. (Just the RE: part)

[little_mistress]

nope its gone into the great bit bucket in the sky

[turnstep]

I think part of the challenge (indeed, maybe most of it) is trying to figure out exactly what the person is asking. Usually they know exactly what they want, but end up expressing it really, really badly. :) Some questions are so vague that all you can do is throw a bunch of clues and hope that some stick! :)

I like going beyond the question itself to see exactly what they are trying to accomplish. In other words, the question may be about some esoteric (or common) perl nuance, but I also like to try and give them some insite on code design, user interface, the cost (CPU, speed, readability) of what they want, alternative ways to do it, etc.

There is some risk as coming across as patronizing, or even insulting the person: after all, if they are asking about a regex, and you point out that the whole block around it is ill-written...

This might sound harsh, but I tend to assume that those who cannot carefully craft their question, cannot carefully craft their code. </alliteration>

[neshura]

That seems like a terribly unfair assumption. There are many people who can craft good useful code who can't write worth a damn. You shouldn't penalize them for it, especially considering how many developers speak English as a second language.

Second, people may be withholding their code precisely because they fear being laughed at. It's hard to be a newbie! So if you offer a helpful answer that is bracketed by criticism, it is tremendously discouraging. I'd like to suggest to you that if you (or others) do choose to offer unsolicited advice on other parts of their code, that you do so with x-treme™ kindliness.

However, I must also say that I find your writeups generally chock full of information I can use! It is much appreciated.

e-mail neshura

[turnstep]

I'll respond to your second point first, about withholding the code: you are responding to someone else's comment. I have not problem with people withholding their code. Sure, it might make things easier, but whether they do or not is really up to them. Some questions do not even need example code. If I need some, I will ask.

As to the first point,

That seems like a terribly unfair assumption. There are many people who can craft good useful code who can't write worth a damn. You shouldn't penalize them for it, especially considering how many developers speak English as a second language.

I don't think I am penalizing them, I am just going on the assumption that coding takes attention to detail, and writing a question does as well. There are differnces between bad questions, good questions, and questions written by people with English as a second language:
• What are all command line options? Why do some of them not work for me?
• Why does "perl -v" not show the current version when I type it at the command line? "perl -V" seems to work fine....
• "perl -v" shows me errors, "perl -V" work fine?

I'm naturally going to assume the latter two people are slightly better at writing code, and at a more advanced level, than the first one.

In general, it's better to err on the side of assuming the questioner does not know very much, for these reasons:

• It's better to explain something that they already know and risk a little "I knew that!" than to talk over their heads.
• Other people reading your answer may not be as knowledgable as the original questioner and may learn something from your response.