Python - The Right Way to Ask Questions that Get Answers

Published on Nov. 6, 2017, 9:21 a.m.

Starting off in any endeavor -- especially as it relates to technology, you're going to need to ask questions so that you can get answers and learn. Sure, you can't avoid reading the manual or googling but often (especially in the beginning), you'll need to ask questions so that you understand subjects better.

No doubt, you've probably already found that question asking in IRC, forums or mail lists to seem to be a dead-end street or you've found that you feel like you're prying teeth to get an answer out of someone who seems(?) to be willing to help you. Or you seem to getting a lot of RTFM! or the humiliating LMGTFY answers?

If this is the case, have you ever considered that you aren't getting good results because maybe you're asking questions the wrong way? If so, it's not entirely your fault. Very few people outside of engineering or coding have a knack for finding answers on their own. If they do, it's pretty rare.

Also, most things in this world -- including medical sciences -- are not nearly as complex as learning how to code, analyzing code or coming up with an architecture plan to get your app out into the world. So, you better believe that asking great questions can make a difference in your learning.

Generally speaking, there are two types of questions:

  • How do I ... ?
  • How do I solve this problem ... ?

A HowTo question is usually very straight forward. For example, a question like "How do I handle whitespace in Python?" has a fairly set answer. Oh that's easy. Set your editor to tab with spaces and make sure that your indents are always consistent. 4 spaces per indent is ideal. Then, indent the first line inside loops (for, while) and class and function definitions. Very straight forward.

HowTo questions for the most part are easily solvable. However, solving real problems when things don't go well can be very difficult. There are a lot of rock stars who can show you how to do some neat stuff but when things go bad, you'll often notice that those rock stars are nowhere to be seen. Making messes is pretty fun and just anybody can create anything but solving actual problems is where the real work is. If you can master the "fixing" part, you will be far more valuable than those who can't do it.

I believe where someone learns the most is in asking the right question for a particular problem. At my job (doing technical support work) a new person will often say, I have this problem on a particular case. Would you please look at the case and let me what I can do to fix the problem. That is a very bad question and even if someone is nice enough to give you answer, you likely won't learn from it. At worst, other engineers will ignore your questions. To make sure your question isn't ignored, there is a certain format I feel should be adered to.

First off, your help needs to know what the problem is from a very basic standpoint. This should go without saying.

Also, if there is a problem, we need to be able to reproduce it reliably. If you can do that, then your help can very likely reproduce it on his own and he will be able to see the problem first-hand.

If you cannot reproduce an error reliably, then you may not have a solvable problem or it's possible there's no real problem at all. However, keep in mind it is always ok to say an issue happens intermittently (meaning sporadicly and mostly without a pattern) if that is truly the case.

If you are getting an intermittent issue, you need to find some kind of pattern where this problem is occuring so that we can make this a reproducible problem. In a case like this, here are some things to think about:

  • Does this happen at particular times?
  • Does this happen with a particular frequency?
  • Does this happen after performing a particular set of other steps that may seem unrelated?
  • Am I or another user doing something that may seem unrelated when this problem occurs?

Once we can make this reproducible we're on our way to finding a solution.

We also need to be able to express what it is we are trying to do or accomplish when we run into our issue. One of the biggest problems I have experienced in helping developers, testers and users at almost any skill levels is that many of them lack the ability to articulate what they are trying to ultimately achieve. It is very important to be able to communicate what is expected when an error is reproduced.

To give our helper some context or at least present a goal so that the problem can be considered solved, it helps to describe what we're observing when it occurs. For example, "The Internet is broken" is not a good description. We would need a lot more detail. For example, "Skype appears to be working and I can get to my Gmail inbox but for some reason I can't access Slack" is a much better description of observation than saying "the Internet is broken".

So, in a nutshell, here are some steps you can use to formulate a good question to solve a problem:

  1. Write a one-sentence title of the issue. Doesn't have to be great. It really can just be a knee-jerk announcement of the problem.

  2. Create steps to reproduce the problem. Use as much detail as seems practical and don't get upset when someone who is helping you asks for more detail.

  3. Describe what you are expecting. Really think this one out and be prepared when an alternative way of doing things is suggested. Don't be afraid to let someone really help you. When you're learning you have to put your ego down for a bit.

  4. Describe what you're observing in lieu of what's expected. This would include error messages. There should also be some kind of symptom within the user interface or in the running process of a script.

  5. Write a good summary of the problem. This should be easy to do once you have steps to reproduce, expected and observed. These three together almost form the summary with little additional effort from here.

  6. Refine your one-sentence title. Make your title from step 0 get to the heart of the issue in one sentence. It should now be a coherent statement as opposed to being an almost untelligible panic!

Let's use an example:

You're writing some Python code. You try to run it and you get some indentation errors from the Python interpreter.

0. Panic! Python says my indentation is bad.

1. Steps to reproduce the problem:

. Type this code into your editor:

def my_func(num):
    print('this is my function')
     result = num * 2
    return result

if __name__ == '__main__':

. Save the file as

. Run at the command line:

# python

2. Expectation: this should run and print the number 10.

3. Observation: I get this error instead:

$ python 
  File "", line 3
    result = num * 2
IndentationError: unexpected indent

4. Summary of the issue and question: When I run a Python script, I get a strange error (IndentationError) for some reason. What do I need to change in my code to make this error go away?

5. Better one-sentence title: IndentationError when running my Python script.

Now, out of all this, we can generate a very good question:

IndentationError when running my Python script.

When I put this code into a file and run it, I get a strange error (IndentationError) for some reason.

Here are my steps to reproduce it: see link

(Ideally, the steps, if showing code, should be in a pastebin page like

1. Type this code into your editor:

def my_func(num):
    print('this is my function')
     result = num * 2
    return result

if __name__ == '__main__':

2. Save the file as

3. Run at the command line:

# python

I am expecting that it should print out the number 10 but I am seeing this error exactly instead:

File "", line 3
    result = num * 2
IndentationError: unexpected indent

What do I need to change in my code to make this error go away and print out 10?

This is a very simple error when it comes to Python but I wanted to show that you can apply this template to most any technical problem you will ever encounter. For anyone who is offering to help you, this will make it very simple for them to read through, understand your issue and offer some solutions.

When you formulate a good question it has been my experience that about 50% of the time your brain will be prompted to some avenue you can try that will eventually lead to resolving the problem.

The other half of my time writing questions like this almost always leads me to get help from someone else very quickly. With the right question, they will understand my problem more quickly. Also, if they are senior to me, they have likely seen the pattern before and they will push me in the right direction to find an elegant soution. And that is what getting help is all about. Give it a try, I think you'll like the results.

If this blog is helpful, please consider helping me pay it backward with a coffee.

Buy Me a Coffee at