Never be afraid to ask stupid questions. As someone who spent years doing penetration testing, I can assure you that when stupid questions don’t have an obvious answer, someone isn’t thinking properly.
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.
Surgeons mark where on the body they're operating. This didn't used to be a standard practice.
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.
I've been struggling to explain the principle behind the "stupid questions" and your example illustrates the point perfectly. Thank you. I'll be shamelessly stealing this point from now on :)
> 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.
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.
I think the person who initially did bring up the phrase must have meant it the way I did, because if they didn't -- if in fact all they meant by it was "basic but obviously important questions" -- then there would be no reason for them to bring it up at all, since 100% of people already agree that you should never be afraid to ask basic but obviously important questions.
I don't think that's true. A lot of people are afraid to ask basic questions that everyone would think are important because they'd feel stupid asking them.
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!"
All I'm actually arguing for is exercising judgement in deciding whether to ask something that might be considered "a stupid question", rather than following black-and-white advice to always ask it anyway. All I'm arguing is that there exists a question that is too stupid to to be worth the reputational damage of asking.
> 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.
I’ve had multiple times in my career when people got mad at me for asking basic but obviously important questions. Things like:
* 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.)
These are good counterexamples to my "100% of people" claim as they illustrate something I hadn't taken into account in my answer: That a basic but obviously important question could have negative implications about other people. I agree that it's certainly not always the case that those people are OK with such questions.
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.
And this is why it's very important, in the case of a junior engineer, to use your "I'm just starting here" privilege to ask those stupid questions. Or you can be a very senior engineer who has an established reputation, and can get away with asking what sound like "stupid" questions just because people assume you know what you're doing.
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.
I absolutely would want someone who's becoming a surgeon or pilot to ask the "stupid questions." This discussion is about growth and change over time as a person.
> This discussion is about growth and change over time as a person.
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.
Mostly I agree, but I think this statement carries with it an oversimplification of the world.
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.
> I can assure you that when stupid questions don’t have an obvious answer, someone isn’t thinking properly.
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.
I love and struggle with the second point. It's taken me half my career to realize that people would very much prefer the complete and right answer slowly or later than the '90% sure' answer right now. Being quick doesn't make you look smart
I disagree. Asking stupid questions, even if in good faith, can be mean being banned from communities or losing participation privileges. Such as mathoverflow or stackexhcange.
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.
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.