Learning To Ask High-Quality Questions

Questions are revealing. It’s the main reason people choose not to ask them in the first place. When you ask a question, you are revealing things about yourself you may not be comfortable sharing. Maybe you don’t know something or you need help. You worry the person being asked is going to judge or ridicule you in your vulnerable state.

If you struggle with asking questions to your colleagues, or you feel the questions you are asking aren’t getting you the outcomes you want, I suggest adopting a mindset of crafting high-quality questions. A high-quality question reveals your vulnerabilities, but also your strongest qualities. To better describe this, I’ll give some examples.

Let's say you run into a bug at work with a cryptic error message you have never seen before. Your first instinct is to reach out to your colleague Brian. Brian has more knowledge of the program than you. You write out your question and it looks like this:

"Hey Brain, I'm getting an error I don’t quite understand, would you be able to give me a hand solving it?”

Looking at that question, what have we revealed to Brian? We revealed we don’t know something and we need help to solve it. This is the standard format for asking for help, which I would consider average. There’s nothing wrong with asking an average question, but I believe we can do better.

Now, let's take a look at the same scenario and ask a high-quality question instead:

“Hey Brian, I'm getting an error message: X. I've tried A, B, and C to resolve it but none of them have worked. Would you be able to take a look and show me where I went wrong?”

Now again, what have we revealed to Brian? Firstly, we have still revealed we don’t know something and need help. However, we have revealed several strong qualities as well. If we look at the line: “I've tried A, B, and C to resolve it, but none of them have worked”. This shows we have taken the time to attempt a solution independently. Independent work toward finding a solution is a sign we care about solving the problem, and we have an instinct towards independence. Also, we value Brian's time and mental bandwidth by providing valuable context for solutions already attempted. The same goes for providing the actual error message in the question. The less guesswork Brian needs to do, the better. Finally, we have shown we are considerate by politely asking for assistance, instead of demanding it.

As a final example, let's take a look at a low-quality question. I’ll revisit this topic later, but it's also possible to reveal negative qualities about ourselves if we aren’t careful. The poor quality question is as follows:

“I need help, I have a bug.”

Given what we have learned in the previous example, what have we revealed to Brian? Like the previous two, we reveal we don’t know something and we need help. Conversely to the high-quality question, we have also revealed several negative qualities. Unlike the high-quality question, we have given Brian no reason to believe we care about finding a solution to the problem. Brian's assumption when seeing the question maybe you saw the error message and immediately asked for help without doing any work to solve it on your own. Also, we don’t have much regard for Brian’s time or attention. Brian has no context for what the bug is, so when he sees the request, his brain is going off in a million different directions wondering what bug you could be referencing. For Brian to help us, he needs to first ask us for the basics. If he can’t easily discern the issue from there, he’ll need to spend time looking for a solution. A solution to a problem we don’t care about solving. And if we don’t care about finding a solution, why should Brian? Finally, our tone suggests we regard Brian as someone who is summoned whenever we have a problem. Suffice it to say, making someone feel like they are our errand boy is not a winning strategy if we need their help.

Below is a summary of what we have revealed in each iteration of the question to Brian.

Hopefully, the data above give a compelling story for why crafting high-quality questions should be our goal when we need assistance from our colleagues.

You may disagree with how I have described Brian's response to the above example low-quality question. My description may seem more severe than you would ascribe to the Brian you have at your job. It’s true, Brian in my example has a very negative reaction to the poor quality question. This is intentional. When I craft high-quality questions in my work, I assume the person who will be receiving the question is in a bad mood. This assumption forces me to make extra sure I have done everything within reason to solve the problem on my own, construct a well-organized question, and always be polite. There’s no rule stating you need to follow this yourself, but I felt I should explain it in more detail.

There are still some important points to make about the composition of the high-quality question. Let's revisit the line from before: “I've tried A, B, and C to resolve it, but none of them have worked”. This is the most crucial part of the question. It’s crucial because it reveals positive attributes about us, but it also has the knock-on effect of improving our skills as a developer. For you to obtain solutions A, B, and C, you must first attempt to solve the question independently. Making an honest effort to solve problems independently before going for help has several benefits. First, independent problem-solving is a key attribute of high-performance developers. Second, and somewhat predictably, the more time you spend doing independent research, the better you’ll get at it. The better you get at research, the better you’ll become at finding solutions to your questions. The more effort you put into crafting high questions, the fewer questions you’ll end up asking.

Finally, crafting high-quality questions is beneficial to the rest of your team. It’s hard to overstate the cognitive work involved in answering poor-quality questions. The lack of context and the general sense the person asking the question did not give a fair effort at solving it themselves, makes the process of assistance arduous. I’ve seen senior developers go to great lengths to avoid developers who habitually ask poor-quality questions. I recommend always including independent research as a component of your high-quality questions. The traits it reveals to your colleagues are excellent, and it has a positive impact on your growth as a developer.

Crafting high-quality questions helps you avoid the unintended consequences of asking poor-quality questions. Based on the previous example's poor-quality question, it would be a shame if you DO care about finding a solution, you DO have respect for Brian’s time and attention, and you DON’T think of him as an errand boy for your personal debugging use. All too often, people put forward versions of themselves they aren’t happy with. Having a mindset of crafting high-quality questions can save you from accidentally putting your worst foot forward.

Not every scenario calls for a high-quality question. There are instances where no amount of independent research will yield an answer, or the amount of research needed is beyond the means of what is realistic. For example, if you are getting an error regarding a lack of permissions when trying to access a protected resource like a GitHub repo, or a new section in a cloud service provider, no amount of independent research is going to get you the results you're looking for. There may also be times when you are presented with an error so baffling and cryptic, that any research you try to do just leads to more confusion. In either of these scenarios, I recommend going straight to whoever can help.

Another area where crafting high-quality questions may not be appropriate is when you are experiencing a very tight deadline and everyone is scrambling to get a project over the finish line. An example may be the final days before your company releases an MVP to the market. Most rules end up going out the window in those periods of crunch time. If you can craft high-quality questions, do it, but don’t do it if it's going to slow down the rest of your team.

The strategy of crafting high-quality questions is best practiced in a text-based environment. Meaning group messaging platforms or via email. Although it works best in those environments, you can still ask in person with some tweaks. If an in-person dialog is the best or only way to get assistance, the best course of action is to still ask for help politely, but make sure you have all the relevant context ready when the other person is ready to see it. You probably don’t want to rattle off a full error message and all of your solution attempts in a verbal exchange. The person you're asking will be overwhelmed and may forget most of what you said. My tactic has always been to ask for help, bring the person to my desk, and then show all my work. In the verbal arena, bring the horse to water.

At this point, I hope you are feeling excited to start crafting your high-quality questions. Before we get to the how I should clarify crafting high-quality questions does not guarantee an answer. Nor does asking a low-quality question guarantee a non-answer. When crafting high-quality questions, it's important to focus more on the process than the outcome. You have no control over if a colleague can answer your question. All you have control over is how you decide to respond to issues when they arise. Crafting high-quality questions is about the journey, not the destination.

Now that we have covered why it's important to craft high-quality questions, it's time to go over how you can go about doing it. There are no hard and fast rules about how to craft them. I’ll be sharing techniques and recommendations that have worked for me over the years.

Before you craft any questions, start by identifying what positive attributes you want to reveal in your questions. I’ve already made a case for including your efforts at an independent solution, but other characteristics may need more consideration. For example, if you are a developer in Japan, being polite and respectful may be the most important component of your question. Conversely, if you're working at a cash-strapped startup in the West, concise questions that get straight to the point may be more appropriate. Whatever your situation, Give some thought to what traits you want to reveal.

Once you have an idea of the traits you want to show, it's time to come up with metrics for your independent research. An independent research metric is the amount of effort you plan on giving to finding a solution on your own. The metric I use most often is to make at most three attempts at solving a problem before I go for help. Your metric can be whatever you want. It could be one attempt or five. It doesn’t even need to be based on the number of attempts. You could have a time-based metric like trying to solve a problem for at most thirty minutes before you go for help. You could also do a combination, three attempts or thirty minutes, whichever comes first. Once you have a metric, you must stick to it. The main goal of the metric is to keep you honest and constant when doing independent problem-solving. It’s also to keep you from spending too much time trying to solve something on your own. It’s not always advantageous for you to spend days trying to solve a problem. Receiving guidance from a more experienced colleague after thirty minutes of independent research can be just as beneficial to you. I recommend experimenting with different metrics to see what works best for you.

With your desired traits and a research metric, the final step is combining everything in a question template. I suggest using this technique when you first start. As you get more comfortable with the process, you’ll be able to write high-quality questions from scratch. A question template is exactly what might think, it's a pre-formatted question with places for dynamic values. I’ll use the high question from before as an example.

Hey {name}, I’m getting an error message: {error_message}. I’ve tried {…solutions} to resolve it, but none of them have worked. Would you be able to take a look and let me know where I went wrong?

The template above has three places for input. The name of the recipient, the error you have encountered, and the attempts you have made at solving the issue on your own. Having a template will help by forcing you to get the values for each variable. Make sure your section matches the research metric you picked earlier. Your template can follow any structure. It’s a good idea to have a few when you get started. Experiment with what feels right and get results.