This article is translated from https://redd.one/blog/how-to-ask-questions
As a software engineer, you often need to implement real-world functionality and fix tricky bugs. Sometimes you may feel like you lack knowledge or are unsure how to fully tackle a task. This is completely normal, even the most experienced engineers occasionally encounter difficulties, and no one truly knows everything, despite how smart they may appear. Seeking help (and offering help) is an essential part of programming, just like writing code or conducting code reviews. However, asking questions itself is an art that requires some time to learn how to get more results with less effort.
Asking is Learning#
I know the feeling of fear or embarrassment when it comes to asking questions, worrying that your colleagues might think less of your intelligence or technical skills, frown upon you for asking what they consider obvious questions, or even bully you, expecting you to already know the answer by now. If you feel that the environment you're in doesn't encourage asking questions, then you might be in a poor environment and need to leave as soon as possible. Those who look down upon curiosity, experimentation, and asking questions are rarely intelligent people because they hinder themselves and others from gaining knowledge. Knowledge comes from learning, and learning comes from asking. Make sure you move forward with those who understand this.
However, if you feel shy or lacking confidence when seeking help, I have a little tip for you: don't see your question as a sign of not knowing something, but see it as a sign of wanting to learn more. In my opinion, asking questions is the most effective way to learn in any field. Through this process, you can make progress in the art of asking and are more likely to remember the answers because we tend to remember the solutions to problems we have personally experienced.
💡 Don't deprive yourself of the best way to learn: asking questions.
The Art of Asking#
The skill of asking the right question is incredibly difficult to master. However, you won't get better at asking questions unless you practice and pay attention to the details that bring you closer to the answer. This topic deserves a thick book to explore, but for now, let's discuss one of the most common issues in asking questions: specificity.
The specificity of a question can be both a double-edged sword, either bringing you closer to the answer or pushing you further away. Let's see why.
Irrelevant Specificity#
Here's an example of a question:
How to maintain Google authentication tokens when refreshing a page in React?
While this might be a valid question, it includes too many details that are not useful in answering the question. For example, don't tie the authentication process to Google, but consider asking a question about general authentication persistence. Because the situation is roughly the same for Google, Amazon, or any other provider in this regard. Don't limit the answer to the React ecosystem, but try to remove the framework from the question to understand persistence in JavaScript. This way, the answer you get is more likely to be reusable by other frameworks and libraries, making it more valuable. Lastly, when it comes to persistence, the importance of maintaining authentication tokens, unique IDs, or any type of information is minimal. Even the "authentication" part in the question can be replaced with "how to maintain data," any data.
While the context you're in may be important, often letting go of it helps you find a clue that will eventually lead you to the right answer.
💡 Asking is investigating: you find clues that guide you to ask more specific questions and eventually find the answer.
When you need to turn a red ball into a blue sharp cube, don't expect to immediately find the solution to this task. Learn first how to turn a ball into a cube, then learn how to make any cube blue, and finally learn how to make a blue object sharp. Any programming task can be broken down into a series of smaller tasks, and in the long run, studying these tasks will be a more valuable process. In the middle of this process, you may realize that you don't even need to make the cube sharp.
I strongly recommend removing the background from the question because it gives you a better chance of finding the answer. It also helps you understand that there's rarely a single direct answer to a question. Starting from a macro perspective and gradually narrowing down to specific details as you discover them. You'll be surprised by how much you learn through this approach.
Relevant Specificity#
Providing technical details, including library names, browser versions, or specific option names, can help narrow down the investigation and bring you closer to the answer. However, when providing this information, there's one important thing: you must know what is relevant.
Take a look at this question:
POST request in Axios fails in componentDidMount.
Assessing the usefulness of these technical details is entirely impossible because they can be both relevant and irrelevant depending on the specific use case. Knowing what to include and what to omit when asking is your responsibility. Honestly, this is one of the challenges in asking the right question and is one of the skills acquired over time and practice.
💡 When including technical details, you must know what is relevant and what is not.
Unfortunately, mentioning irrelevant details can derail your investigation. Fortunately, if the person you're asking is familiar with the topic, they can help you filter out these details based on relevance.
Over time, as you keep asking questions, you'll start to notice that certain technical details become very important to you, while others gradually become less important. On this point, I have no other clever advice, just encouragement to keep asking!
The 15-Minute Rule#
Be careful not to develop a habit of handing over your problems to others when asking questions. While seeking help is the right thing to do in desperate situations, we all dislike struggling. Therefore, when the long-awaited help finally arrives, we naturally feel satisfied and joyful. To make this help last longer, try to learn to assess the situation before asking. This can prevent unnecessary questions and give you a sense of accomplishment in solving the problem independently.
💡 Ultimately, the quality of the answer you expect is proportional to the time you're willing to spend looking for it.
In my career, adopting the "15-minute rule" has been very helpful to me. Whenever I find myself stuck, I dedicate 15 minutes of focused time to try to solve the current problem on my own. By the end of the time, I check if the question I intended to ask is still relevant. If it's no longer relevant, I spend another 15 minutes dealing with the next problem that arises. Only when my efforts prove fruitless do I turn to colleagues or other developers for help.
This rule is useful because it adds value to your questions. In the process of trying to solve the problem, you usually learn one or two things, even if you don't find the answer. The knowledge you gain and the methods you've tried may help your future "advisors," the people who help you solve the problem, to address your question more accurately. At the same time, your effort in solving the problem lays the foundation for receiving understanding and sympathetic responses from others.
Patience#
Software engineering can be stressful: losing revenue due to a problem, managers being angry about missed deadlines—we've all been there. Stress doesn't really solve these situations or find the answer to the problem.
Remember that explaining a problem and asking the right question are equally difficult. Taking the time to help someone who is trying to find the most suitable way to convey the answer to you can be challenging. In this process, patience and kindness are crucial.
Helping Others#
No matter how inexperienced you think you are, there's always someone who is one step behind you. That person is walking a similar path as you, but they may not have fully grasped certain concepts or patterns that you have already mastered. The next time you see someone struggling with a topic that seems very clear to you, please help them.
💡 Offering help is as valuable as seeking help.
Selflessness is not the only reason to help others. The best way to confirm if you truly understand a problem is perhaps by explaining it. Because each of us thinks and remembers things differently, conveying your thoughts to someone who needs help can be challenging at first. Sometimes, it requires you to verify the knowledge you've acquired to avoid giving incorrect or incomplete answers. This may help you discover blind spots in your own knowledge!
Drawing Conclusions#
Getting the answer is certainly satisfying, but try to keep it in mind. The question is not a burning stove throwing answers one after another, as asking is about learning. Extracting valuable information from the answer may require revisiting the original question and drawing conclusions. What was the cause of the problem? What was the solution? Did the solution directly or indirectly affect the cause? Is there any additional knowledge that can help in solving this problem?
Learning itself is a skill because each of us learns, remembers, and explains things differently. Since that's the case, why not improve another skill while already having the answer? Try to find the learning method that suits you best, whether it's drawing diagrams, writing short documents, or bookmarking useful links. This treasure trove is a good place to start using the 15-minute rule the next time a problem arises!