Also never be afraid to question people who answer quickly. We spend way too much effort training smart people to answer quickly rather than deeply, and there’s almost always a tradeoff between the two.
Unfortunately that's the kind of black-and-white advice that seldom applies in the real world. Would you want to see your surgeon asking stupid questions? The pilot of the flight you're on?
You wouldn't, because part of your psychological comfort depends on your perception that people like this -- people whose decisions really matter -- actually know what they're doing.
ETA: By "stupid questions", I don't mean "basic but obviously important questions". I mean questions that reveal that you don't know something that other people expect you to know, that signal to them (rightly or wrongly) that they may have overestimated you.
Is it? Because the original statement used the word "never" and didn't mention growth and change over time as qualifiers.
The more one attempts to qualify -- that is, restrict the scope of -- the advice, the more one tacitly admits the point I'm trying to make, which FTR is: This advice is not always good advice.
Asking "Did I mess up my left and right?" or "Is this the right patient?" feels like a stupid question to ask. I'd certainly rather they ask those questions before operating on me! But turns out it's very hard to get them to do that, so we do surgical site marking instead.
Ok but you didn’t bring up the phrase “stupid questions” so it’s less about how you define it, and more about a best effort interpretation of how it was originally meant.
The thing is that in many a case those basic questions have not all actually been asked and answered because everyone involved thought the same: it's stupidly simple, I better not ask for fear of being marked dumb.
I get the feeling that it's because of fear of being marked dumb by people like you actually.
But then it often turns out that one of those stupid questions has not been answered sufficiently or people were thinking of completely different answers to the question. So it was a good thing that someone brought it up.
And if the question did already get taken into account and people did have the same answer(s) in mind then if a senior person asked, it will probably just be taken as "this guy knows his stuff and is just dotting Is and crossing Ts" VS a junior "asking dumb questions that everyone should know the answer to, duh!"
> I get the feeling that it's because of fear of being marked dumb by people like you actually.
I make positive and negative judgements about people based on things they do, which is an imperfect heuristic but the best one available and much better than nothing. So do you.
The way I read your comment was that you categorically oppose asking "dumb questions" no matter what.
You don’t have a great mental model of how most people think
* What invariants does this complex transformation preserve? What guarantees does it make about the output? (Come on, we all have a general idea, SpicyLemonZest should read the code if he wants all the details.)
* What’s the latency impact of adding this step? (It can’t be big enough to matter, stop trying to block my project!)
* Why did the last release advance to production when it wasn’t passing tests? (How dare you, our team works so hard, it says right here in our release manual that those test failures count as passing.)
When I wrote my comment, I didn't have such questions in mind. I wish I'd written it to exclude such questions, because I think they're not central to the issue here, which is whether or not asking questions that have negative implications about one's own ability is always a good idea.
In practice, some of what it takes to do a given thing comes from thing-specific information (which is appropriate to ask questions about), and some comes from a background of experience in doing/studying other similar things (formally or informally). For complicated tasks it basically has to be this way, because there just isn't time to train a person up from scratch for each task -- a random person off the street could not perform surgery merely by first asking a sufficient number of questions about exactly how to do it. People find "stupid questions" alarming because they reveal holes in this important second category, and make people wonder what else important might be missing.
You could make the argument that it's better for society if everyone asks whatever "stupid" question comes to mind, because then incompetent people and charlatans will be quickly exposed and the harm they would do minimised. But it's not good for the charlatan!
I don't side with actual charlatans, of course, but most of the time I do side with people of imperfect competence, because that's most of us. Competence is improved by practice, and most tasks are low-stakes. If a person is already near the threshold of being perceived as unacceptably incompetent by others, and can discover the information they need via other means than by asking "stupid questions", that may well be the best way for everyone.
That's not to say that I advocate never asking stupid questions. In fact I would encourage people to lean more in that direction as a default setting -- they are the fastest way to get the necessary information. They just have a cost that it would be naive to ignore. It's a judgement call, is all I'm saying.
We have an expectation that "smart people" should be able to quickly fill in gaps in lightly-explained systems. Sometimes this is good: when you're teaching people a new concept it's great if they can grasp it quickly and approximately. When you're describing the design of a complex system, you absolutely do not want people to make incorrect assumptions about the parts you're skipping over.
The worst example I've seen was learning that the security of an industrial control platform came down to the fact that the management software wasn't installed by default. The designers had assumed that "knowledge of a software library" was a valid access control mechanism. As the cherry on top, another engineer chimed in that the software was actually installed on the system anyway, just in a different location. It took a pile of incredibly "stupid" questions to surface this knowledge.
Once you start asking stupid questions on the regular it's quite an interesting experience how often you can ask "stupid" questions to rooms full of senior engineers and sort of get back confused silence. In my experience there's a lot of really important but "stupid" questions that often just gets half-ignored because imagination and prioritization is hard.
StackExchange is a massive, global forum which has to react defensively in order to maintain its high-quality knowledgebase against spammers, scammers, and the same questions being posed 10^N times.
The context here is about knowledge dissemination in local teams, groups, or organizations. Completely separate category, levels of trust, motivations, incentives, etc.