MSDN Forums: Asking Questions

---

The purpose of this article is to help people to get help in the most efficient way possible.
 

How an Answerer Uses This

Most people aren't realistically going to just stumble across this article or even search for it before posting their first question.  The main use envisaged is by people answering questions on forums directing people here. 

With that in mind note that the headings in a wiki page with a TOC are also links.  To obtain a direct link to one of the headings click one of the headings in the toc.
You will get something like:
http://social.technet.microsoft.com/wiki/contents/articles/29181.msdn-forums-asking-questions.aspx#One_Question
Copy out the address bar and paste.
When someone clicks on that link it will open this page at the One Question heading. 

Research First

People have been asking questions on forums for years now. 

There are also other forums such as CodeProject.

A lot of advice is already on the web available to anyone who can google it.  ( Other search engines are available ).

Google your question and you might be able to get an immediate answer without asking a question at all.

If you get replies which are basically a list of links then the chances are that the person posting that reply has (just) done a search.  Bear that in mind because if someone just googled then maybe they have no idea which link is going to work or is the best.

The search first advice is particularly true of definition questions.
What is the difference between an interface and an abstract class?
What is dependency injection? 
These and any number of similar ones have already been done to death by thread after thread.
Find and read them.
Or don't be too surprised if someone posts a link to let me google that for you

Correct Forum

Before you post a question at all, make sure you are about to post in the right place.  If this is related to a particular technology such as Windows Forms, Asp.Net, WPF, SQL Server etc then there are forums which are specific to these.
It's in your interest to post in such a technology specific forum.

People are likely to read posts on forums they are interested or knowledgeable about. There are going to be more people who know more about your subject reading your thread if you choose the "right" forum.

You maximise your chances of someone who specialises in that technology responding.

People are fallible. When you get a response there is no absolute guarantee a suggestion is ideal. Peer review is an important part of forum threads.

You want as many knowledgeable people to read responses as well as your question so they can spot any mistakes or suggest better technique.
It is very common for someone asking a question to assume the reader "just knows" about what they are doing.  If you at least ask a Windows Forms question in a Windows Forms forum then the reader can reasonably assume that GridView you're talking about is a WIndows Forms GridView rather than the asp.net control.

One Question

When it says “Ask a question” the “a” in the sentence means one.  That is literally one question.   If you're used to other discussion forums then the MSDN forums are different.  The expectations is you ask a question, someone answers it, you mark the answer and that's the thread done.  Think of a question as being a support ticket.
A support ticket which goes into a searchable knowledge base - searchable on that header you type.

You are raising a ticket for the problem described in the heading, with further supporting information in the post itself.  Code, description of symptoms, technical aspects sufficient for someone to understand what's going on, details of any error and stacktrace.  That's the sort of thing goes in the body of the post.

After you input the question and tab away, a list of suggested prior topics is presented.

Someone asks “how do you do xxx” and it is answered.  The person who asked that question marks a post as the answer.

Later on someone else asks “how do you do xxx” that thread ought to pop up and they can easily look at the post marked as the answer and find what to do without posting the same question again.

If you ask multiple questions in the one thread then this mechanism cannot work.
If you post "I got a problem" as your question then that isn't describing what your problem is and the mechanism cannot work.  

It is important to remember that your thread is not just for you. It's for the community and future searchers.

Some examples of what NOT to do with your ONE question:

• A list of numerous questions - unless these are VERY closely related and another reasonable person would think they form one question.
• Drip feeding pieces of explanation which are significant and will influence answers.
• That's great, but whilst you're here can you just.... 
• I've reconsidered and instead of this approach I asked about I want to do this entirely different thing instead....
• That's one aspect of this but here's another 3 aspects I just thought up and now need clarifying.

All these will frustrate people who are trying to help. They give their time and they will expect fair marking of their answers. It's very little reward really and recognition points aren't worth a bean but people will expect you to mark answers if their post seems to answer your question.
If you then make them answer another one then you just doubled their effort. You're likely to make people wonder where will it all end. How many more pieces of information or changes in direction are going to happen?

Make Your Question Attractive

Most of the people answering questions are not paid to do so.  They are not obliged to answer your question. That means if they decide they don’t like what they’re reading for whatever reason they will probably just move on.

That means you want to be:

• Polite
• Clear and Concise
• Ask a reasonably scoped question

The last one could perhaps do with more explanation.  Some people ask for 20 problems to be solved in one forum post, a core part of their system design to be delivered as code or some such.

These are big asks.

A question that requires a lot of work puts people off. It’s asking for too much. 

Enough Explanation

When you ask a question, if whoever reads it cannot understand what you mean then they have to either be very good at guessing or they won't answer the question.

It is very common for questions not to explain important aspects of the problem.  

Before you post, re-read what you have written. If you were someone else reading it and you knew nothing else about what you were doing then have you covered everything they will need to know?
EG
If the error seems to come out of the app startup but actually happens 2 hours later and only on Windows 7 machines then explain that.  Don't let people think it's a startup problem on all machines.  

Common things left out or which are misleading:

• Not mentioning technology involved – windows forms, wpf, asp.net, wcf or what?
• Asking on the wrong forum when there it is a technology specific question
• Wrongly named controls – DataGridView instead of DataGrid.
• No code – just a stack trace or error code
• No indication where an error is coming from in code posted.
• Top error rather than the innermost error.
• No question or explanation at all.

Yes, that's right. Some people post a question which doesn't actually have a question in there.
Technical problems in coding can be pretty frustrating and a fair number of posters are probably somewhat flustered or tired.  All that banging their head against the (virtual) brick wall of a problem means their judgement is a bit off.  They're too close to the issue.
Have a cup of coffee and think of something else.
Walking away and taking a break is often a good way of solving a coding problem anyhow but a cool head is definitely going to help you formulate a clear question.

Include Just Enough Code

You want enough to explain what the problem is but not so much that the reader can’t work out what is going on.  

This is sometime called the Goldilocks zone.  Like the story.  Not too much, not too little. Just Enough

A wall of code is a bad idea.

A one line explanation is a bad idea.

Both leave the reader thinking "What's that all about".  One because they have to wade through so much code to find something.  The other because only the person asking the question can possibly know what they actually mean.

Make it Easy to Replicate Your Issue

For some questions you need a fair bit of code in order to replicate the issue.  It's up to the poster to supply sufficient that someone else can reproduce their issue reasonably easily.  This will often require some work to extract the problem code out an application and into a simpler smaller version that anyone can run.
Some posters don't bother with that work and post thousands of lines out their project.
From the perspective of someone thinking of spending time answering the question this is can be off-putting.
It's not unusual to try this sort of code only to find there are other dependencies which mean it can't run anyway. This is a bad sign to an experienced forum reader. If you think about it you're asking for help but used minimal effort to post your code. From someone else's perspective if you look like you were lazy in constructing your post then that probably means they have to spend more time than you are prepared to yourself. 

Take your code.
Put the problem code in another solution.
Ensure you have no dependencies which would stop people working on this.
Sometimes you will find the problem yourself in doing this.

If this sounds like a lot of work and you couldn't really be bothered, bear in mind this is your problem you need solving.  If you couldn't be bothered putting the time in then is this obvious to someone who would answer your question?  
If you are expecting them to spend more time because you won't then you better hope they don't realise that.

As a last resort you can potentially upload a project to OneDrive and people can download it.  Don't be too surprised if there are few takers for this though.  You're asking someone else to work on a project they have never seen and given to them by someone they don't know. If a poster is spending a spare 10 minutes on a work PC then they may not be able to download your files due to company policy or they may just not have enough time to invest.

Assignments

We are not allowed to just do study assignments for posters. This is because assignments are an important part of the learning process and if you just get a cut and paste solution then all you learn is cut and paste. Which is not good.

A student runs the risk of being given a solution which involves advanced techniques they have not studied yet. Further devaluing the learning experience because when they read the solution they may not understand it. Also potentially missing out on practice of a particular technique which HAS been covered that a teacher wanted you to practice.

At the opposite end of the scale to the super clever advanced solution are ones that are not so great. If you don't really understand some code then it is difficult to decide which is good and which is bad. Peer review may well help you out there but some threads will have a dozen solutions to a problem suggested. Quality of code can be somewhat variable.

Helpful Development Techniques

If there is such a thing as an ideal problem it is probably the sort you can immediately solve yourself without having to wait for anyone else to read a forum post and reply.
There are any number of techniques which help in this area but two basic approaches are particularly key:

•  Debugging
•  Iterative Development

Debugging

Why is Debugging in this article at all?  That's because many posters clearly are not used to debugging and exploring issues.  An error pops up and they just post that.
Debugging is a key skill to developers and one any new developer should learn early. 

Any time you have a problem with code the first thing to do is take a look at the error you see.  An error "bubbles up" through the call stack before you see it and will be wrapped by another error as it goes up through each layer.  That means the top error you see is rarely the actual problem.  You need to open up the inner exception and then the inner exception of that... until you find one with a null inner exception. This last one is the "real" error.
You can do that in code using BaseException:

try
{
    // whatever method or process
}
catch( Exception ex )
{
    // Display the innermost exception.
    DebugWriteLine(  ex.GetBaseException( ).ToString( ) );
}

If that doesn't give you enough information to fix the issue straight off then you need to explore what's going on using debugging.
Place a debug break point in a likely piece of code before where things go wrong.
Use f5 to spin the application up in debug mode.
When the break point is hit you can check what variables actually have in them and find which don't match expectations.
When a break point is hit, that line hasn't been executed yet.
You can f10 or f11 tp step through your code and see where it branches.
Checking the value of simple variables can be done by hovering your mouse over them.  A tooltip appears with the value in them.
For more complicated variables like objects you are often best right clicking them and adding a quickwatch so you can explore all the properties easier.

In this way you might be able to work out what's going on and fix your problem yourself.
If all else fails you will at least be able to tell which line of your code produces the error.

Iterative Development

Iterative or Incremental development is a way of breaking down any piece of development into small chunks.  You write the smallest piece of code which will deliver some workable result and try that, fix it and repeat.  This window or whatever you are working on starts out incredibly simple and you add functionality piece by piece until you get the end result you want.
Each piece of code, test, fix is an iteration and you will do many to write something complicated.
By breaking the problem down then each piece you tackle is much simpler or at least focussed on one very specific bit.
When something goes wrong in your code you know the problem must have been caused by that small bit of code you just wrote or changed.
This last point makes it far easier to understand, trace and fix any issue.

You will "waste" a little time in mocking pieces of code or data, on making a small piece of code "work" without all the other bits it will eventually depend on. You know these mocks or stubs will be throw away. This will initially feel wrong and wasteful. Don't look at it that way. By writing these you're making your job of writing a working solution easier.  You will write more code but 99% of the time you will get a more reliable working result in a shorter time. You will also spend a lot less time tearing your hair out screaming "Why doesn't this work??!!!!" at the monitor.
We've all been there and will visit that dark place from time to time.
Reduce the time you spend there by reducing the amount of code which could possibly have caused the problem.  

Marking Answers

Marking answers, upvoting posts, thanking people and telling them the outcome is in your own interests.  This all takes time and some people just don't bother.  When you think about it this is pretty rude.  If you ask a question someone may take some time putting together an answer.  Even if that is "Yes" and it took them 30 seconds to decide and post that answer to you it is polite to recognise their effort.  Most answers ( from experience ) take longer to formulate and 15 minutes is probably more likely.  Maybe 30 minutes if there is coding involved.
You're getting time and expertise for free - it costs you nothing to be nice.

A thread with an answer marked is also immediately noticeable as such from the front page of the forum. 
This is a good thing for the community. A LOT of people browse or search forum threads. They can immediately see that you think a post answers your question and focus on that.
People looking to spend their time helping others can also immediately see a thread has been answered so they don't waste their time solving something is already solved. 

Be Fair

Everyone hopefully understand immediately that people will want to be dealt with fairly.  If someone spends their time answering your question then it is reasonable for you to take the time to mark their answer / upvote their posts.
If you find a solution which is different to some other posted then it will be helpful if you post that.
If your solution is as valid as another one someone has posted then it is an idea to mark both your post and theirs as the answer.  This lets someone reading the thread know that they could go with either approach,
Be aware it is considered bad form to mark your own post as the answer - this is particularly true if the solution you come up with is the same or similar to one that another poster has suggested.

Recognition Points

In an ideal world all experts would set aside some proportion of their time just to help the new developers of this world. In reality people are busy and have their own set of priorities.
Realising this, Microsoft encourage people to post answers with incentive schemes.
The most obvious is the recognition points you will see associated with anyone's profile.
When you upvote  someone's post or mark it as an answer they get points.
You don't get anything directly from having these points, no money or anything concrete.
People like recognition though and they want those points.

Plagiarism

Some people get a bit carried away with the recognition points thing.  Sometimes you see people who basically copy someone else's response.  Maybe they alter it slightly but you can see this is essentially the same answer as has already been given.
This is a bad thing.
In theory, the higher someone's recognition points then the more reliable their answer ought to be.  They earned those points by giving a bunch of answers so they have proven their expertise in a measurable way.
Unless of course they got those points by copying other people's solutions.  If their expertise is cut and paste then that devalues the points system. 
If you discourage people who can come up with original solutions by encouraging those that copy them you ( or someone else ) could well be out of luck with the next question. 
Don't encourage people who copy answers. 
If you see it happening, the right thing to do is to report such posts.

Fallibility

In theory someone with a high recognition point score ought to give the most reliable answers.  Everyone can have a bad day though.  It's all too easy to misunderstand a question, overlook a subtlety or just not know some part of a technology too well.  You can occasionally see people with high recognition point scores post on subjects they don't know so much about. 

For whatever reason an answer may not be ideal.  Nobody is perfect.  This is where you want the peer review to come in. Hopefully someone else will notice and offer better advice.
This is also a strong reason for being careful to post to the "correct" optimal forum. The more peer review the better.

It's a Small Pool

Most of the answers posted on any forum come from a small set of regulars.  When you come back with more questions in a forum then the chances are that the same people who posted on early threads will be posting again on your new thread.
These people will probably notice and recall behaviour they consider "bad".
If you repeatedly ask vague questions or turn each thread into a never ending series of "But what about this other aspect" then you may get less responses in future.

Post good questions.
Do the right thing by people who spend their time trying to help you.
They'll pick your question to answer instead of that vague one.