Table of contents
Disclaimer
This is based on my experience. I’m not prohibiting anyone from asking questions but encouraging you all to be well prepared before asking questions, especially in the programming world. The clearer you describe your problem, the easier the solution will be provided.
Introduction
When I was a laboratory assistant in my college, I often received so many questions from my juniors. During the class session, when they were doing their laboratory module, there were some parts that they didn’t understand and asked me or my laboratory assistant partner. I actually didn’t have any problem when they ask, it means they are thinking and trying to solve the problem that has given in the module.
But there’s something that bothers me much. Some of them asked questions that actually can be solved if they tried and follow the guide from the laboratory module. Even if the answer does not exist in the module, they can google it and figure out how to solve it. Not only that, sometimes I have to deal with some questions which are not clear enough, so I often waste my time just to figure out what is the root cause or its meaning.
That experience occurs until 2020, the last year of my laboratory assistant This is actually a bad habit. So I think I need to tell you this, so hopefully, we can reduce this kind of habit in the future. Here are some tips from me to be well prepared before asking something.
Breakdown Your Question
Before asking, you should know what you’re asking for. I have an exhausting experience regarding this when I was a laboratory assistant. In Almost every session that I taught, so many students or juniors asked unclear questions so I even need more time just to understand what their questions mean.
Most of them just asked, Kak (in Indonesia we called an older person with the term 'Kak'), I can't run the program on my computer here. It causes me to waste around 5-10 minutes standing near his/her computer to figure out what is the root cause of the issue until I finally answer the question🤣.
Remember that when you break down your question before asking it will help want people who want to answer the question without wasting more time. At least, figure out what’s the possible root cause of the problem and describe it clearly when asking. When the root cause has been figured out, it will be easier to be solved together.
For example, I have some trainees who break down their questions before asking. They had some issues when they want to fetch data using Angular HTTP. They show a quick demo to me which shows the syntax of the codes and the web UI. They even explain it step by step. In around a minute, I figured out that the code snippets is wrong and caused web breaks. This case is effective if you’re in an offline class session😂.
Re-check Before Asking
I often receive redundant questions when I was a laboratory assistant. When I solved a student's technical issue, then the other student asked the exact same question and it happened almost every session that I held😅. I have to re-explain the solution for each student. This is very ineffective.
In another case, when I was trying to solve a student's technical issue in a class session, I just googled it and found a suitable solution for the case. Sometimes, I figured out that they skip some steps from the laboratory module or the official docs.
Based on that experience, here are two criteria that have to be fulfilled before asking the technical question (assumed you have breakdown the question before asking):
- Has anyone asked this question and has been answered before?
- Do your own research or trial & error before asking
If the question has been asked before, you can access a forum like Stack Overflow and if the question has been answered you also can find the solution for your problem. Or if you’re in an offline class session, make sure that if the question has been asked and answered before, you can ask your friend who asked and receive the answer.
If you’re asking a very technical question related to coding, please try it by yourself first before asking. Figure out what’s wrong with your code through self-debugging. Or, do your own googling, who knows you can find the answer through the internet.
When you have done those things above and cannot find a suitable solution, then come to ask. Don’t forget to describe the problem clearly so it can help anyone who wants to answer to figure out what’s the problem and the suitable solution. This method can reduce the redundant questions or questions that even doesn’t need to be asked because it has already been documented or are available through “googling”.
Recap The Answer
When you finally got the answer, don’t forget to recap it. For example, if you finally figure out how to fetch the data from the API with Axios, take note of that. If you have a personal blog, write articles about it and publish them so everyone who has a similar problem like you before can also be helped. I usually called it giving back.
Not only about giving back, you even can read again what you’ve written before if you’re facing a similar issue. It will reduce the exhausting “trial & error” because you have experienced a similar issue before and just re-implement the solution.
Closing
Again, I’m not prohibiting anyone to ask. I just want to tell you guys to be prepared before asking. The more detailed the description of the problem, the easier it is to be solved.
Finding the root cause of a problem means 50% of the solution