- Articles
- "How to Ask Questions": Itemized thread/
Apr 5, 2011
"How to Ask Questions": Itemized thread/rehash
Score: 3.9/5 (20 votes)
I'm sure all of us are familiar with the famous "How to ask question the smart way" guide.
I don't necessarily want to reinvent the wheel here, but I have some beefs with the guide that inspired me to make this thread.
Specifically:
- The original guide is too big. It's like a 10 page thing. Often when I want to draw people's attention to it, I just want to draw their attention to a specific paragraph, which isn't very convenient.
- I don't agree with all of it. Specifically the amount of research he expects people to do.
- It's too broad and doesn't cover some really specific things that I see often on these particular boards.
So the goal of this thread is to address those issues and allow the userbase here to contribute some of their own tips.
The idea is simple, but in order to keep it useful I would like to introduce some "rules" for posting new tips:
- 1 item per post. That way individual items can be linked instead of having to link to one massive article. This way when these tips are "broken", we can link the user to the direct post rather than directing them to a general guide.
- Put a one-line summary of the tip in bold (and possibly in caps -- just make it noticable) at the top so that when the person clicks on the link, it's immediately clear what they did wrong.
- Try to keep each item short. People aren't going to read a whole page. In order for this to be effective we need to avoid the tl;dr.
That's about all I can think of for now. I'll start off with a few that get my goat. More are welcome.
Lots of people here don't read every thread. We filter them based on what the topic says. If your topic accurately describes your problem, it's more likely to get a response.
"Using vector, program crashes on exit."
Compiler errors often tell you exactly what's wrong with the code. They take experience to fully understand, but the regulars here all have that experience and know how to read them.
- Show us the line of code that is causing the compiler error
- Don't paraphrase/reword the error. Chances are you're leaving out/changing some critical information that we need.
Don't post a chunk of code and say "This code doesn't work." Be specific about why it doesn't work.
- Do you get errors when you try to compile? If yes, tell us what and where the errors are.
- Does the program not do what you want when you run it? If yes, tell us what you want it to do, and what it actually does.
We can't solve a problem when we don't know what the problem is.
I don't necessarily want to reinvent the wheel here, but I have some beefs with the guide that inspired me to make this thread.
Specifically:
- The original guide is too big. It's like a 10 page thing. Often when I want to draw people's attention to it, I just want to draw their attention to a specific paragraph, which isn't very convenient.
- I don't agree with all of it. Specifically the amount of research he expects people to do.
- It's too broad and doesn't cover some really specific things that I see often on these particular boards.
So the goal of this thread is to address those issues and allow the userbase here to contribute some of their own tips.
The idea is simple, but in order to keep it useful I would like to introduce some "rules" for posting new tips:
- 1 item per post. That way individual items can be linked instead of having to link to one massive article. This way when these tips are "broken", we can link the user to the direct post rather than directing them to a general guide.
- Put a one-line summary of the tip in bold (and possibly in caps -- just make it noticable) at the top so that when the person clicks on the link, it's immediately clear what they did wrong.
- Try to keep each item short. People aren't going to read a whole page. In order for this to be effective we need to avoid the tl;dr.
That's about all I can think of for now. I'll start off with a few that get my goat. More are welcome.
THREAD TOPICS ARE FOR SUMMARIZING YOUR QUESTION
Lots of people here don't read every thread. We filter them based on what the topic says. If your topic accurately describes your problem, it's more likely to get a response.
Examples of bad thread topics:
"A quick question": doesn't describe anything
"How do I...": Incomplete sentence. Finish the sentence and maybe it would be a good topic.
"Getting compiler errors" Better, but still not very descriptive
Examples of good thread topics:
"Numbers printed to the screen aren't showing up right""Using vector, program crashes on exit."
TELL US WHAT COMPILER ERROR YOU'RE GETTING
Compiler errors often tell you exactly what's wrong with the code. They take experience to fully understand, but the regulars here all have that experience and know how to read them.
Do's:
- Copy paste the error as the compiler tells it to you- Show us the line of code that is causing the compiler error
Don'ts
- Don't tell us you're getting error C2203. We don't know what that is.- Don't paraphrase/reword the error. Chances are you're leaving out/changing some critical information that we need.
TELL US WHAT THE PROBLEM IS
Don't post a chunk of code and say "This code doesn't work." Be specific about why it doesn't work.
- Do you get errors when you try to compile? If yes, tell us what and where the errors are.
- Does the program not do what you want when you run it? If yes, tell us what you want it to do, and what it actually does.
We can't solve a problem when we don't know what the problem is.