Getting better at asking questions (as a developer)
Feb 21, 2025
Recently, I officially started my career as a developer, and I almost immediately realized: I don't know how to ask questions.
To be honest, when I was working with something easier than programming, I thought that I was incredibly efficient doing so. But once I got into an experienced team, full of technologies I cannot yet fully grasp, and people who know much more than I do, I faced reality: I'm still too slow and ask a lot of questions in the wrong way.
But that's okay. I'm here to improve and learn as I go. And that's precisely why I'm attempting to improve even in the things most people take for granted, like knowing how to ask questions.
The FAQ "How To Ask Questions The Smart Way" was published by Eric S. Raymond in 2004, and it's undoubtedly useful even today. I decided to start improving this skill by equipping myself with the lessons he describes and also annotating the main points I found useful here in this note.
Getting Excuses Out of the Way
One of the things said in the introduction that stood out to me:
"Despite this, hackers have a reputation for meeting simple questions with what looks like hostility or arrogance. It sometimes looks like we're reflexively rude to newbies and the ignorant. But this isn't really true."
The best hackers I've met are like this. And I agree with the FAQ:
"What we are, unapologetically, is hostile to people who seem to be unwilling to think or to do their own homework before asking questions."
Admittedly, I have some excuses for not asking better questions:
• I don't know how to solve most problems. 90% of them are always something new to me, which takes time for adaptation. • I can read the manual, the code, the documentation, and still not be able to fix the problem because I needed to know something only a specific person or team knows. • I have a very strict deadline to fix each problem, so if I try to check absolutely everything before asking something, it can take longer than expected by my peers, and I can be perceived as lazy.
But for these excuses, I also have some answers after reading the FAQ.
• Just keep going. Eventually, you'll learn most common problems that happen on a daily basis and also how to deal with new problems more effectively. • If you read the manual, the code, the docs, etc., together with the first answer, eventually you'll be able to identify when something is off. And when it happens again, you can always add that information to a new doc. • Having realistic deadlines for your level of knowledge of the project is something that needs to be discussed with your leader and peers to establish a more flexible environment for improvement.
It's really easy to think that you need to solve a problem quickly as a junior. But in reality, most problems can be more complex than you think, and it makes sense for you to need to reflect on them.
Before Asking a Question
Like Raymond described, before asking a question:
1. Try to find an answer by searching the archives of the forum or mailing list you plan to post to (in my case, Slack channels!). 2. Try to find an answer by searching the Web. 3. Try to find an answer by reading the manual (or documentation). 4. Try to find an answer by reading a FAQ. 5. Try to find an answer by inspection or experimentation (this also helps you understand more about the intricacies of the language/framework/codebase you're working in practice if you're a junior developer). 6. Try to find an answer by asking a skilled friend. 7. If you're a programmer, try to find an answer by reading the source code.
Showing You're Not Lazy
"When you ask your question, display the fact that you have done these things first; this will help establish that you're not being a lazy sponge and wasting people's time. Better yet, display what you have learned from doing these things."
This is absolutely true, and almost everything that I actually learned was from doing this. Raymond also brought to light the act of making clear that you want help in developing the solution rather than waiting for the exact procedure to do so. Changing this simple behavior helped me not only receive more friendly responses but also changed my mindset on solving problems.
There's no need to hurry. You just need to be pointed in the right direction.
Write Well
Another point made by the author was the correlation between sloppy writing and sloppy thinking/coding. And to be honest, I 100% agree with this. To me, the expression of one's thoughts reflects directly their thinking process—both in speaking and writing.
That's why it can be beneficial to try writing better if you're a junior. If you try to describe your questions really well, you'll be able to identify obscure areas in your knowledge. If you don't know how to properly describe something you did in your code, for example, this is a signal that you need to come back and try to understand it again.
Describe Your Research
"Describe the research you did to try and understand the problem before you asked the question."
Almost every time I describe the research I did, I remember that I need to check another place as well—usually where I'll find the answer. It's okay to forget things if you're a beginner but not okay to forget even where to look. That's why it's important to write down the steps and use them as a checklist.
Also, if you have a peer you've asked questions before, it is a good idea to anticipate and answer any questions they may ask directly in your question.
Volume Is Not Precision
This is an extremely common case in my daily job. When I receive a ticket, it's often filled with excessive information. But a huge volume of data is often more detrimental than beneficial for help requests.
Describe The Problem's Symptoms, Not Your Guesses
"It's not useful to tell hackers what you think is causing your problem. (If your diagnostic theories were such hot stuff, would you be consulting others for help?)"
Ouch. This hurts if you've done it before. I was used to trying to provide my diagnosis when asking a question because I felt like it would show that I'm actively trying to understand. But if you think about it, there's really no need for that; it can only serve to show that you have no idea what you're talking about.
It's best to be succinct and display only facts.
Identify Gaps by Describing the Order of Steps
If you're trying to diagnose a problem, maybe you're forgetting to take a step or doing something in the wrong order. It's always good to describe what you did in chronological order because of this. The more experienced developer will be able to identify the gap in most cases.
If You Want to Learn How to Do Something, Describe the Goal, Not the Steps
"Often, people who need technical help have a high-level goal in mind and get stuck on what they think is one particular path toward the goal. They come for help with the step but don't realize that the path is wrong. It can take substantial effort to get past this."
A lot of times in the past, I tried to reach a result thinking there was only one path to it. Usually, there are more. So describing the goal may help you identify that you're on the wrong path before wasting too much time.
The Main Takeaway from This
I believe that the most valuable lesson I got from my recent workdays and this FAQ as well is learning the difference between demanding an answer and asking in this manner:
“Please help me figure out what additional diagnostics I can run to achieve enlightenment.”
Just thinking this way made me change my whole philosophy on problems. Even if I don't want to solve them at the moment, this helped me build resilience against being stuck.
This is it for now. Maybe I'll add more to this note in the future.
Thanks for reading, and check out the original faq by Raymond to see his complete perspective on the topic.