Even though I am now retired, I am still a member of the Institute of Electrical and Electronic Engineers (IEEE) and subscribe to their Career Alert newsletter. The latest issue features a short article from Rahul Pandey, founder of Taro, a platform for helping software engineers manage their careers. The article is about asking better questions to get the help you need in order to do your job better.
While the article is geared towards software engineers, I think it also has some good advice for radio amateurs asking for help with their stations or their projects.
The #1 rule about asking questions
As engineers, continuous learning is a fundamental part of the job. A huge part of learning comes from trying something, getting stuck, and then asking a question to your teammates.
Here’s what is often overlooked in that process: The quality of your question determines the quality of the answer. So it’s worth thinking about how you can level up your question-asking skills.
The guiding principle when it comes to asking a question is simple: Make it easy for others to help you. Let’s break down what that means.
Include the necessary information. In the software engineering world, for instance, asking something like “Can you explain why the app is crashing?” puts an enormous burden on the question recipient to collect more info before they can help you. They’ll need to know:
- What action caused the app to crash?
- Does the issue reproduce?
- What do the logs reveal?
It’s usually not hard to anticipate what follow-up questions you may receive after you ask a question. Include those details in your question!
Show your work. One of the most common replies to a question is “What have you tried?” This is critical information to include in order to (1) improve the chances that the recipient can help you and (2) prove that you did the necessary homework.
Common details to include are: prior team discussions, code snippets, and relevant data. But be careful not to overdo it. Including too much code in your question will overwhelm anyone who’s trying to help you. You should spend time identifying the snippet that captures the essence of your issue. Remember, the golden rule is to make it easy for others to help you, which requires your judgment on the right level of backstory to include.
Explain your goal. The backstory is deceptively important in any question, especially for technical topics. For example, you may think it’s obvious why you’re trying to add a parameter to a function, but it’s probably not clear to your teammates. An error I’ve seen frequently is that the question is asked at the wrong “altitude”—the asker made some incorrect assumptions that led them to ask the wrong question.
To get the best answers, include a brief explanation of your goals at the beginning of your question to set the context.
Address the right audience: A personal pet peeve of mine from when I worked at Facebook was when an engineer would ping me individually with a generic question that others could have benefited from. Instead of messaging me directly, I wish they had posted in a group forum. By posting to a broader audience, others could have learned from the answer, and there may have been fruitful follow-up discussions. Moreover, asking the group will lead to faster resolution; it removes a single person (me) as the bottleneck.
The question of the 1:1 vs. group forum is just one element to consider. Is your question best handled verbally or in writing? Could your question be answered by a junior colleague, or do you need feedback from your team lead or manager?
By considering the above criteria, the quality of your questions will improve significantly, leading to more effective interactions and learning.
Leave a Reply