Whether you are emailing someone you don’t know, or messaging your colleague, certain common features set apart great questions from the lousy ones. In many cases, it is not the actual question, but the method of asking that can potentially make the interaction less pleasant and less productive for everyone involved.
Asking the same question over a phone call or a meeting would also benefit from some of these considerations, but factors such as personal history and “catching up” would become relevant in those contexts.
In this article, we present 7 simple tips that illustrate the subtle art of asking questions via text-based media like Slack channels, emails, personal messages, and so on.
Table of Contents
Google is your friend
This is a no-brainer, but frequently overlooked.
Just put the exact question you have into Google. Or ChatGPT, Bard etc. If your company or organization has an internal knowledge base, search that too.
If the information you need is already a few keystrokes away, it is almost always guaranteed people will not like being interrupted in their work for answering it. Especially if the other person is a programmer, as evidenced by personal anecdotes like the following:
I studied physics in college and did enough research to publish and present a paper. When I was doing physics, I remember there being some moments where I was on the cusp of some great realization that helped me solve a problem, and I didn’t want to be interrupted at that point. But most of the time it wasn’t like that.
My work was always written down and I could deal with an interruption and come back to it with only slight irritation.
When I started programming, literally the most interesting thing I noticed was how many things I had to keep in my mind at the same time in order to do anything with the code. It felt mostly like a new skill to me.
It felt like trying to carry too many clothes without a laundry basket. Things kept falling and I had to pick them up again and again.
https://dev.to/_bigblind/are-interruptions-really-worse-for-programmers-than-for-other-knowledge-workers-2ij9#comment-38ll
Don’t “ask to ask”, just ask
In discussion groups like Discord or Reddit, newcomers often ask things like this:
Hi, does anyone here know JavaScript?
This is a very slow and inefficient way of asking questions for following reasons:
- JavaScript (or any other tech) is a complex, multi-faceted thing. No single person knows it all. So if your question does not identify the nature of the problem, it requires more back-and-forth messages to identify whether a given person
- People have their own reasons to help you, or ignore you. A problem may well be within their technical abilities but explaining to a newcomer what the issue is, and how to fix it, is a time commitment they may not be able or willing to make.
This pattern of interaction is apparently so common that single-page website has been created just to explain this concept: https://dontasktoask.com/
So, instead of the above, consider framing the question in a pattern like the one given below:
I have been trying to achieve [describe goal] with JavaScript. I am using [tool/framework/component] for this. There is a problem with [describe problem briefly, including error messages if applicable]. I have searched online and found [list of possible and remedies].
However I still have not managed to solve this, can anyone help?
Ask one question at a time
Considering the full question is easier than dealing with small fragments. However, dealing with multiple unrelated issues can be distracting and cognitively challenging.
Suppose you are trying to bake a chocolate cake, and you have never baked one before. It is natural to have questions about several things, depending on the level of detail of the recipe. Now, should you choose to ask a baking expert, you may want to break down the problems or questions into parts, such as:
- Do I add the after stirring the eggs or before?
- Should the chocolate powder be in a certain proportion to the sugar?
- If I want to make the cake slightly dry, would the baking time need to be adjusted?
In each case, the answer depends on several other factors. However asking all the questions at once might make it seem that you are way over your head, and any potential mentor would not be thrilled at that!
Consider the context and workflow
People check their emails on their mobile phones, but may not have time to download and read an attachment.
Emails marked “urgent” better be actually urgent, or else the term loses meaning and in future it will not evoke the same sense of urgency that may in fact be necessary! We have an article on email etiquette if you are interested in exploring further.
When asking a question over Slack or similar, people would find it vastly easier to have each question in its own thread. And it’s best to create separate channels for long term projects which woIuld require several threads to continue discussing.
When shooting a DM (direct message) to a coworker or a random acquaintance, it’s important to consider the cultural context and mindset of the recipient when they see your message. People may not be eager to answer work-related questions when they are in a party, or scrolling Facebook for funny cat memes, and so on.
Provide sufficient detail
This is a variant of the “Don’t ask to ask, just ask” advice, but it is for one-to-one communication between two people who are familiar with each other.
Let’s take an example. Say you are facing some problem with “software A”, and you know that your colleague has used software A.
A bad way to ask the question would be:
Hey, can you help me with a problem involving software A?
After reading this, your colleague’s honest initial reaction may be to respond with one of these options:
- “Of course, how may I help you?”
- “Sorry. I have a lot on my place, so don’t have time to help you right now.”
- “Urghh. You didn’t even specify what exactly is the problem, how do I even respond to this??”
Options 1 and 2 are not the situations where this advice applies. In the real world, most situations would elicit response 3, and that is precisely where our advice is applicable.
Even under the best circumstances, your colleague is probably busy doing other things. So the best policy would be to give them information about the nature and scope of the problem, to estimate the time/effort required to solve it.
To that end, consider the following way of asking the same question:
“Hey, I am having issue XYZ with software A.
I tried steps ABC and read the docs, but could not find a solution. I think it may be related to concept bblah.
Could you please help?”
The three paragraphs details will obviously vary depending on the culture of the workplace, your prior familiarity with the colleague and so on. But the key thing is to include all three components, i.e. describe the issue, specify the things you have already tried, and outline any topics or concepts that you think may be relevant.
Conclusions
The advice in this article really boils down to putting yourself in the other person’s shoes and asking yourself, if I was the one answering it, what would make this easier and quicker? Then follow that.
Keeping your questions short, isolated and showing prior effort towards solving it goes a long way in making people more likely to answer.
However, if you are asking open ended questions to strangers, such as asking for personal experience of attending a university or working with a specific PI, you may want to approach it differently.
Happy asking!
