As I take a holiday from my regularly scheduled meet up it occurs to me that we may be lacking a good guide for how to ask a question. Or in reality I know we are as I get asked questions incorrectly all the times. So first some basic rules for any question: 1. There is such thing as a stupid question. Despite what your fifth grade teacher told you there are stupid questions. Stupid questions usually stem from asking a question that you don't understand yourself. Perhaps you are asking the question at the wrong time. Like "how do I get a job as a programmer?" This is sometimes a very good question. If you are just out of college or a boot camp, or are at the end of teaching yourself with a portfolio. If however, you did one code academy course or none, this is a ridiculous question because the answer is you don't. What you should be asking is what is my next step, or even don't ask a question and just move to the next step and come get me when you hit a brick wall. This is similar to the question "How do I quit my job and get a job as a programmer within 3 months? Here you are asking the second part so far ahead of where you should. I don't even know if you should be a programmer. This is a "slow your roll error". Another of these is "how much will I get paid when I become a programmer?". You are also likely in it for the wrong reasons if that is what you care about. Another stupid question is the amorphous "Are you my yoda?" Sort of question. These usually take the form of "what _______ should I learn?" This tells me 2 things about you. First, you don't know how to use the Internet, because all over the internet that question has been answered with "it really doesn't matter" and you want me to plan your life, and I don't need that kind of pressure. If you really want to ask this think it through and add a "to do _______" to the end. Let's look at an example "what database should I learn" is a stupid question, "what database should I learn to build a website like Airbnb" is a good question. The difference? I can extrapolate from the second meaningful functionality and goals and can direct you. The first I could pick one out of a hat I suppose. But it basically translates to "What one thing can I learn and not have to learn anything else". Simple answer, programming doesn't work like that eventually and not very far in your career you will know several at a year I know 4 storage systems reasonably well and 2 more tolerably well, and I know enough at at least 1 more that I could use it if I needed to. I think you get the point of what I'm saying here. Ask a stupid question get a stupid answer. So avoid it. It also makes me answer all your questions less well because you don't seem serious. 2. Assume the person you are asking is smarter than you. This may or may not be true. I don't care. But in asking a question you are asking a favor. So be respectful. Even if the person you are asking knows nothing, treat them with the deference of someone who knows more. Don't be an ass. 3. The person you are asking's time is worth more than yours. The person you are asking does not have a question. They have things to do, they are likely being productive. They are granting you a great favor by giving you their time. Respect that. Don't pepper them with tons of stupid questions. Don't try to monopolize their time. Respect their time by coming to them will a fully formed answerable question that they can speak to and move forward. Don't ask them every question you have ever had. And don't ask them a question that you haven't fully looked at yourself. See 5 in development specific. Now specific to development: 1. Have a good understanding of the problem, at least as good as possible for you. To get an effective answer for a question it is best to be able to say "this is the problem I have, this is what I have tried, and this is what I think might be happening". Now depending on knowledge you might not have all of that but have as much as you can. "Something is wrong" is not a question it's an annoyance. But "these items line up on this screen but if screen size changes they shift, I tried to float them but it doesn't seem to be working correctly" is a pretty good question. The answerer knows where to look for the problem and what you thought should have solved it. 2. Know the bounds or your question. Know when you question is answered. Asking a question does not give you a monopoly on that person. If you ask about aligning text you don't also get a fix for some console error for free. You may but appreciate that something extra has happened. A question is not all fixes. It is a specific answer for a discrete problem. If you don't have a discrete question see #1 in the previous section. 3. Accept that getting a different error message is an answer to your question. This is specific to development. If you are getting an error on line 10 and you ask for help which results in an error on line 14 it is not the answerer's job to fix that error. You should bounce off and try to fix it yourself and come back with a new question if you don't get that error it's how you learn. 4. The person you are asking does not need to know your language/framework/package to be smarter than you or correct, but you should know it in case there are recommendations based on the package. I answer questions a lot about angular, node, and rails. While I know rails I don't know rails helpers, and I don't know angular or node. So it's important to accept if you ask me questions about those I will try to help and give general insight, but I will not give the node fix. Don't ask someone for the best practice node answer if they are not a node programmer that's not their job. If you are programming in node best practice is your job, their job is working out the bugs. 5. The correct order of operations is fiddle with it, documentation, Google, then another person. If you can find the answer yourself don't use another person as the Internet. You should have googled, etc first. If you don't understand the answer it is valid to ask for clarification, but if you ask me before you even bother to find the answer yourself that makes you lazy in my book. And lazy people make bad programmers, so I'm not so inclined to help.