A strange game. The only winning move is not to play. How about a nice game of chess?
Seth Godin wrote an interesting blog article about how to consider the, ahem, inexperienced.
From a software support perspective, the question is, how much should I expect my end-user to know? If someone asks me a basic question about DotImage, then I answer it without hesitation. But what if someone asks me a programming question? For example, how to create a for-loop? Or what is a static constructor (public shared for you VB.Net programmers)?
Generally, I just answer the question, but they do stack up with a nOOb. And at a rapid pace. As I put together a training manual and application, I am trying to keep things simple so a person can find what they are looking for in an instant. No complicated mathematical formulas, no high-level behavioral concepts. Click leads to code leads to action. Am I shorting my advanced users by doing this? Yes and no. No, because they would never have need of a document like this. Yes, because I can't get into the "really cool stuff".
Add to that, who ever admits they're not part of the elite?
Seth suggests telling someone "this might just not be for you". How do you say that to someone who has sought out your product, evaluated it, and purchased it? Or worse, they're using it because someone *else* evaluated it and purchased it, and they're stuck with it. His approach is good for someone with the luxury of being able to tell someone "no." It doesn't apply to someone who has already spent thousands of dollars.
Every support person has fantasized about telling the user to send back the computer, but that is definitely not an option.
From the other side, how would I like to be treated? Personally, I would appreciate someone giving me the basics, but I would not want to waste someone's time (trust me, I've asked my share of dumb questions).
I guess the real problem is not answering the simple questions, but having to answer lots of simple questions. It rather feels like I'm just giving away goldfish instead of fishing poles. And when it's a repeat offender, I wonder why they are programming -- maybe it's not our software that's not right for the person, but development in general.
I'm not writing this to dissuade people from asking me questions; on the contrary, I would rather someone ask me than do something wrong. But if I gently suggest to a person that he/she would be better off consulting a C# manual or MSDN, I hope they will not be offended.