Learning to ask what you think are stupid questions is not easy.
Asking "stupid" questions requires a lot of confidence.
We have been conditioned to not admit weakness and ignorance; deconstructing the ingrained feelings of shame is not an easy task.

Over time, I realized that questions people think are stupid usually fall into three categories.

1. Questions about random tidbits of knowledge

Some people feel bad about asking questions like:

• what's the method that does X in language Y?
• what's the command to run the unit tests?
• how do I install postgresql on ubuntu?

Well, no one is able to recall every random fact about computers.

Knowing how to do something is transient: it goes in and out of working memory;
if an answer can't be found with 10 minutes of searching, it makes sense to ask someone else.
If you encounter a question the first time, you might not know what to search for anyway.

Of course, If you find yourself asking people the same question repeatedly, it might be time to write a documentation page or put some post-its on your screen.

A question is only stupid if you:

• don't put in an appropriate amount of effort before asking
• don't try to learn from the response

2. Questions that require mental chunks

There are questions where the answer is kind of obvious, but only if you have acquired the right mental representations.
This takes practice, effort and experience.

Once you have these mental representations, it is easy to forget the hard work that was required to acquire them.
All that remains is a sharp "uh, obvious" feeling.

When asking questions that rely on built-up insight, you will often not be aware of the concepts you are lacking; thus, miss how valid and valuable your question actually is.
Googling will not serve you well – the knowledge you are missing is not just a 3-step instruction list, but requires deep learning.

I will try to illustrate this with an example from web development.

Imagine someone starting out as a frontend developer, asking "how do i make the title text red?".
That's an extremely not stupid question.
While one could go "duh just use color: red; in your CSS", this presupposes knowing:

• what HTML is
• what CSS is
• what a CSS rule is
• what a CSS selector is
• an understanding of how these rules get applied when loading a page

People who come up with these concepts on their own usually end up writing a PhD thesis.

Answering these questions well requires a tremendous amount of pedagogical sensibility.
You need to recognize where the person asking the question is at, and get them started on the right path forward.
This can be both unblocking them in the immediate, while giving them pointers about the concepts to look up and study in their learning time.

Asking these questions in a public setting is a mixed bag, as people might not recognize what is going on.
However, these questions are great when pairing (pair programming).
If anything is unclear while you are pairing, and you feel the person you are pairing with is a good partner, ask every single stupid question that comes to your mind.
That is what pairing is all about.

3. Questions with no good answer

There are many questions that just have no clear-cut answer at all.
If you were to ask an expert in the field, they'd probably pause for a few seconds and go "it depends".
For example, a question like "where should i save the user state in my react app?" not only elicits many strong responses, but the community consensus changes every couple of years.
Anybody with a hard and fast answer doesn't have a full understanding of the depth ot the topic.

Every answer is going to make a series of tradeoffs.
Choosing the "right" answer often transcends the technical, and goes into a more general "software engineering / architecture"; it often involves team politics as well.

"Stupid" questions like 3. are questions you should never shy away from asking in an supportive setting (pairing again is a perfect opportunity).
Either a compromise has been reached, and learning about said compromise is extremely important to be able to navigate the project well.
Or a compromise hasn't been reached, and that often points to a bigger issue at play.

Over time, you will slowly get a sense of which questions fall into that category.

Asking stupid questions confidently, keeping a beginner's mind, is a skill to be practiced and strengthened.
The best way I know of to develop this muscle is to continuously learn new things. It is the essence of learning at the edge of your capabilities – being "stupid" and asking the questions to become less "stupid".

Asking stupid questions also requires a safe environment; you need to feel supported and know that showing vulnerability is not going to harm you. This is sadly especially true in a professional setting, and even more so if you are part of a section of the population that is routinely discriminated against. I have written a bit more about this in Imposter syndrome is about systemic discrimination, and it is a topic I plan to write more about in the future.

(first published at the scapegoat dev - asking stupid questions