How to be great at asking coding questions

Print this out and read it now. Then post it on your wall. Each time you have a question, read this again until it becomes second nature.

The Situation

Most people are absolutely terrible at asking questions, but the good thing is that you can follow a few simple steps to be great at it.

Whether you’re part of a team, on StackOverFlow, or a student at Watch and Code, asking good questions is essential. People that ask good questions are more effective because they get better answers more quickly and more often. They’re also taken more seriously and get more respect, which matters if you care about your career.

Good questions save time. Bad questions waste time. Bad questions create unnecessary back-and-forth conversations, which create frustration and conflict. People that ask bad questions get frustrated because they can’t get help, and people that are trying to help get frustrated because answering bad questions is so damn frustrating.

Bad question askers usually don’t get far in their careers. That’s because working with them is pure frustration. If you were a manager and had to fire someone, you’d immediately think of people that ask bad questions. The only thing that saves most bad question askers is that everyone around them is bad too, and so in relative terms, they look alright.

The Process

1. Understand the code to the best of your ability.

• Yes really, actually do this. Do not rush this step. Most people give up way too easily here.
• Go through line-by-line and figure out what each line does. Take notes, think about things that might be confusing. Let them sink in.
• Use a debugger to help you. If you don’t know what this means, watch this video:

• Google with RESTRAINT. If you treat this as a scavenger hunt, you’ll rob yourself of opportunities to practice problem-solving, which is what programming is all about.

2. Clearly describe the problem.

• Explain the context. For example, if you’re a student at Watch and Code, provide the URL for the associated lesson and explain what you’re trying to do. If you have a question about a video, provide the timestamp too so that someone trying to help can reference the exact place where you got stuck.
• Explain the exact steps you took to produce the problem. For example, did you click three buttons in a specific order? Did it work fine in Chrome but not in Safari? Explain every little step.
• Explain what you expect to see.
• Explain what you actually see. For example, if there’s an error message, share the entire error and the line of code that caused it. If there’s a weird user interface problem, take a screenshot.

3. Provide the code that illustrates the problem.

• If you are working on a large project, isolate just the part that is broken and share that.
• When you share code, make sure that the code doesn’t change by the time someone looks at it. That means you should create a separate copy of your code just for your question. If you change the code by the time someone looks at it, your question is not just a bad question, it is inaccurate, which is worse than bad. That’s because everything might have changed, but there’s no way the person answering will know about it. Do not punish people that want to help you.

4. Make sure the code you’re sharing can reproduce the problem.

• Take the code you shared, and make sure it behaves exactly like you described. If you share broken code that doesn’t replicate the problem, it will be impossible to help you.

5. Format your code consistently.

• It doesn’t matter what style you use, just make sure that you’re consistent. This makes your code easier to read. It will also help you with the next step.

6. Check yourself for typos.

• Nobody wants to look for your typos. If you can’t find your own typos, you need to learn how (just keep reading).
• For example, if you’re stuck on a lesson in a tutorial, go back to a point where your code worked and redo the lessons from there, making sure that your code continues to work each step of the way. If you get to a point where your code doesn’t work, redo the lesson and double-check for typos.
• If you’re on a specific lesson and the code is provided, check the provided code and see if it works. If the provided code works but yours doesn’t, then you have a typo. Now that you are sure that you have a typo, it’s your job to find it. Go back methodically and figure out where you messed up. Do not waste someone else’s time and ask them to do something that you should do yourself.

7. Explain what you did to troubleshoot the problem.

• Come up with a list of hypotheses about what the problem might be and then test them methodically. For each hypothesis, explain what you did to test it.
• During this process you might figure out the problem yourself. This is very common.

8. Explain what you think the problem might be.

• Based on your tests in the previous step, provide your best guess on what you think the problem might be.

9. Proofread your question.

• Read through your question and make sure you’ve provided everything that someone would need to answer it.
• Edit for clarity. If you think something might be confusing, fix it. If there’s a typo, fix it. If you have typos in your question, people will assume that you have typos in your code. And like I said before, other people are not your personal typo hunters.

10. Send updates and remember this will not be your last question.

• If you’ve figured out the answer before anyone can respond, then tell people so they don’t waste time looking for an answer you’ve already found.
• When you get an answer back, take time to digest it carefully and fully understand what the person is saying. Keep in mind they might not actually be right. So you need to verify that their solution works.
• Thank each person that helped you and remember that they didn’t have to answer your question, but for some reason they wanted to.

The Mindset

The process described in this article is great for structuring and formatting questions. But if you don’t bring the right mindset, it doesn’t matter how neatly you format them. To understand the thinking that should happen before you even start writing, watch this video.