DEV Community

Cover image for Asking the right question, in the right way and in the right place
Dan Newton
Dan Newton

Posted on • Originally published at on

Asking the right question, in the right way and in the right place

Is this the right place to post this? That probably isn’t the right question to be asking when I am writing this on my personal blog. Although this is not the sort of question lead me to write this post, I was hoping it would start the post in the right mood and perhaps even muster a chuckle from you. It did right? Another silly question. Of course it did, it was a great joke 😎.

Ok, I’ll get back to what I actually want to write about and be a bit more serious.

Asking the right questions and knowing where to ask them is something that has been on my mind for a quite while now. This mainly arises from the amount of tangential/borderline irrelevant or badly written question I see but still try to answer in a slack channel I spend a lot of time in. This makes it much harder to help the developers asking questions and possibly leaves them waiting for answers that will never come.

Now, rather than just continuing on this post complaining about how people ask the wrong questions in the wrong places. I am going to switch it around and instead focus on the person asking the question. The main reason for this is during my first attempt to write this post I realised just how whiney it sounded but also how hard it is to explain the problem I was facing. I am sure that the people who sit in a similar position to me have felt the frustrations I have and that there is no point actually walking through them point by point.

Instead, providing some assistance in how to ask the right questions will be a far better use of my time, as well as yours.

This post will focus on asking questions online, for example in Slack or Stack Overflow. Although I am sure the advice provided here will help in real life interactions, there are quite a few differences when compared to online interactions.

Understand the problem

I think this is the root cause of most questions that don’t get answered. Not understanding the problem you are facing leaves you possibly asking the wrong question, in the wrong way and in the wrong place. The exact opposite of the title of this post. It can be a hard issue to fix and, in my opinion, is heavily tied to experience.

Why is experience important here? Well. Knowing the boundaries of different technologies, frameworks or languages requires time and practice to fully grasp. I am facing this problem myself right now. Recently I have been spending time rebuilding my blog using Gatsby (a static site generator) that uses React under the hood. Trying to determine where Gatsby ends and React starts has required a bit of effort but I think I’m getting there.

Now, why do I mention this? The first questions I googled were not very helpful. Eventually, after playing around with the code a bit more and a few more Google searches I started to understand what is handled by Gatsby, React and Javascript itself. But, that being said, I have a few years being a Software Engineer under my belt so figuring these sort of things out has become easier. I’m not saying I can pick up anything and understand it, but it is massively easier than it was when I started out, maybe there is even a large difference between last year and now even.

What I’m trying to say in a convoluted way, is, that it gets easier. But, to do so, you need to look a bit closer at the technologies, frameworks or languages you spend time with. Eventually, you will see similarities in things you have never touched before to experiences you have already had. Not only will this help you achieve better results independently. For the times that you still need help, and I’m sure you will (I sure do), you can better formulate a question filled with relevant information. Allowing anyone kind enough to answer it to have a smoother experience as well as provide you with a clearer and more precise solution.

Spend time on it

Spending time trying to solve a problem yourself before asking a question is very important. It is heavily tied to understanding the problem as a lot of information is revealed as you work through it yourself. Therefore, when you do come to ask for help, the amount of useful information you can provide will greatly increase. Routes you followed that were dead ends, bugs that popped up and performance factors are just some examples of insights you can fill your question with. Now, when someone attempts to assist you, they will have a more detailed picture allowing their suggestions and advice to be better based on facts and experience, rather than taking a stab in the dark.

Furthermore, by actually spending a bit more time trying to fix it yourself. Well, you might fix it. There have been so many times that I have helped other developers by simply sending them the first Stack Overflow post I found on Google. If a bit more time was spent on these problems and possibly with some better Google searches, there is a good chance they could be solved without any assistance. This is something developers of all levels can do.

On the other hand, if you really can’t figure it out. It’s ok. From my perspective, I just want to know that you’ve tried and aren’t just trying to get me to do your work for you. Give me what you have found out. Let me know what didn’t work. I’m sure others feel the same way. We want to help you because we can and to raise you up, but we don’t want to be taken advantage of and do everything for you.

Provide the right about of detail

When I help people with questions they raise, one of my most common replies is “can you provide the stack trace”. This is a typical situation of useful information not being provided that is crucial to resolving an issue. For example, if you are asking for help in a Slack channel, please, please, please, do not just type the words “please help me, my code isn’t working”. Instead, add a short description of what you are trying to achieve, what you have done and what is going wrong. The description of what is going wrong can be a literal description, but more often than not, providing a stack trace or some log lines that you believe are important will go a long way in increasing the clarity of the question. More detail can always be provided at a later point when someone comes to aid you.

I think this is super important. Especially in Slack channels and the same most likely applies to Stack Overflow. Since it allows us to answer questions simply by browsing and responding to ones that catch our eyes. A stack trace or good description is much more likely to attract our attention. It is entirely possible that the question can be answered solely from the information provided.

Although, be careful of adding too much information. The advice from the previous two sections should help with this. Providing too much information is also harmful to the answerer. It becomes harder to extract what is useful from the question when there is a large wall of text with information of varying relevance. This why I am highlighting the previous sections as a cure for this illness. Understanding the problem and spending time trying to fix it yourself will provide you with the insight to filter out any noise and include the most relevant information, making it easier for us to answer your question.


When asking a question, try to properly understand where the problem you are facing lies. Spending time attempting to resolve it yourself will greatly help with this. Once you have done this, providing the right amount of details becomes far easier. You will have gained a superior insight into the precise location of the problem, as well as an improved understanding of the possible routes to get there. Working on these will not only allow us (the answerers) to have an easier time providing solutions and increase the chances of us attempting to help you but also improve the quality of the solution you receive. This leaves you with three parties that benefit from your effort; you, us, and anyone facing a similar issue that happens to see your question.

TLDR - Read the first three headings

If you have any advice on asking questions, please share in the comments to help us all improve!

Top comments (0)