Please ask me any question, regardless of how dumb you think it will make you look, after you've spent at least 5 minutes trying to answer it yourself.<p>Bonus Points if you summarize your quick research efforts.<p>Extra Bonus Points if this leads to more questions.<p>(Caveat emptor: _many_ engineers are decidedly antisocial, but if you show that you did prior research before asking, you're showing to them that you value their time as much as your own, and there's a better chance that they will be receptive to collaboration.)
I ask "stupid" questions all the time, and I haven't been a new software developer for decades.<p>Don't like it? Think I'm stupid? Go ahead. It's a free country. Think what you like. Whatever creams your twinkie.<p>I'd say an important attached property of this "rule," is "Don't treat <i>any</i> question as 'stupid.'"<p>That way, we don't become what is known in the vernacular as "assholes."
Just as important: ask "stupid" questions if you're a Lead or a Principal or whatever. First, you don't know everything, no one does. Second, it makes it easier for the Junior devs to ask their questions.
A couple jobs ago we had a dedicated "dumb-questions" slack channel that only junior-mid devs were invited to; no managers, so there won't be any fear of judgement. Often the juniors would end up answering each other's questions. Another reason it worked well was that, being a group channel, you didn't have to worry about bothering a specific person who might be busy.
The article is right but its ambitions are too low. Everyone needs to ask helpful questions in the right way and at the right time. This is simple but not easy.<p>I'm a staff-level engineer at a well-known tech company. One of the most important things I do is ask simple/"dumb" questions of other very smart but more junior engineers.<p>I try to ask questions they haven't considered or explained well. I ask questions that poke at the assumptions and basic tenets of the problem. I ask honest, non-leading questions to which I genuinely want to know the answer. Other kinds of feedback are not appropriate questions.<p>My Kubernetes and other SRE-style knowledge is limited, so I ask dumb questions there. Sometimes the response is "uhm this is a basic concept" but every time I've done that other engs in the room tell me they were afraid of asking the very same questions. (And tbh many times the answers point to a lack of understanding of fundamentals.)<p>So the key is to be genuinely curious and optimistic, try to guide others to ask and answer similar questions on their own and present them at the right level of detail in their presentation/documentation. And to encourage all engineers regardless of seniority to do the same.<p>A key point is doing this at the right times. During a 10-person meeting with directors is not the right time to ask questions that could send things back to the drawing-board. Such meetings are ceremony.<p>If there are big questions about feasibility etc at a 10-person director-level meeting, you need to go into backroom fire-fighting mode to figure out how to save the project and let everyone save face. In the moment is almost never the right time.<p>If there are tech problems or questions, ask the small group of people who did the thinking, and ask them in a low-stakes setting. All questions must be asked in good-faith to gain any level of respect and overall progress for everyone involved.<p>Questions are NOT an opportunity to show off, to politick, or to start lots of little fires that everyone must put out before proceeding.<p>This is half the art of questions at senior and staff levels: when to ask them, to whom to ask them, and how to help guide the action based on the answer even if you disagree with the conclusions.
As a young female software developer, I was told to ask <i>less</i> questions. This led to situations where I'd be stuck hours on end due to things like backend/config changes that no one told me about and I wouldn't have known. So just a tip that this advice doesn't necessarily hold if you're a minority software developer. Later I was told that I was a good dev but my confidence wasn't good enough. Hmm, wonder what could have contributed to that? :/
Co-opting an idea from Daniel Dennett: try to always have a junior developer around so when senior engineers are talking past each other and no one’s pride will allow them to ask the basic questions that could clear things up, there’s someone there to do it.
I'm going to take the contrarian perspective from this. People absolutely will judge you for stupid questions and you need to be careful about asking them. Dip your toe in the water and see what happens.<p>Actually, that's good advice for all of these types of articles (and it seems like we've had a bull run on 'ask dumb questions'). Organizations are fucked up. Bosses/People are assholes. The wildebeast that goes first in the river takes the biggest risk of being eaten. Watch and learn before taking the leap.
Here is what i do at every new job where by definition i am the "new" software developer. Note that the below activities are not necessarily sequential;<p>* Ask for any and all user manual, design and code documentation however incomplete. This could be docs/pdfs/wikis etc. Spend a few days/week on going through this and taking notes.<p>* Ask a Senior/Knowledgeable developer who has a good idea of the entire System/Codebase for a few hours of his time for a couple of days. Take him to lunch and segue into a "brain dump" of the System. Again take notes. In particular; spend a few hours going over the layout of the codebase and writing down an overview of each component.<p>* Don't ask questions while doing the above. Your aim is to get an idea of the "lay of the land" as far as the logical/functional and physical design of the system is concerned. Absorb the information and try to form a model/image of the system in your mind.<p>* Sit with QA or another developer to learn to run and use the system as a end user. I always find this difficult since one needs to have an idea of what the system does before one can understand how to use it.<p>* Now you have <i>some</i> internal view i.e. logical/functional design and physical codebase layout which you can attempt to map to end user functionality. Start diving into the code, fixing bugs, adding small features to gain understanding and confidence.<p>* You can now start asking any and all questions and revising your understanding of the system and its code.
One of the things that becomes obvious as I gain experience, is that I actually think I know less.<p>As I gain experience the number of things that I could know something about seems to increase at an exponential rate, but my knowledge still only increases at the same rate... So as time goes on, the level of knowledge of all things decreases.<p>So, I ask stupid questions all the time, because I know that something may be related to what we are working on, but I don't have the knowledge to be able to ask smart questions. At this point, any question can help you get to how the subject area can help.<p>Don't worry about looking stupid asking questions. Anybody in this game who claims they know everything lying, there is just too much to know.
I see these articles all the time and I don’t really get it. Are people walking around just terrified of looking stupid? When did that become a cultural value? Where is that being taught and reinforced?<p>I just don’t get the need for this article. Asking questions is foundational. It would be like seeing a flurry of “Don’t be afraid that drinking water at work will make you look dehydrated” articles. Or “Just drink coffee from time to time.” Or “Use the restroom when needed.” It’s just weird to me that people need to be told this, and it makes me suspect there is an underlying failure of culture or education at play.<p>Would anyone who has had this experience be willing to share insight?
I have found that asking "stupid questions" in the form of "I don't understand X, can you explain it to me?" is very valuable, as it forces people to agree on a common interpretation of an issue. In fact, most technical discussions are more about gaining a common understanding of an issue than about a solution. Once everyone has the same understanding of a given problem, the solution space becomes much clearer.
Just in case, recently in HN: <a href="https://danluu.com/look-stupid/" rel="nofollow">https://danluu.com/look-stupid/</a>
Knowing some procedural bash and being a certified Associate python programmer at python institute, I still don't recognize OOP patterns unless explicitly stated. I just got hired in a golang centric org.<p>How can I train / learn recognizing and employing OOP patterns or industry standards so I don't have to bother colleagues with my ignorance? (No CS background, education in the humanities.)
Just ask questions, period. Something seem strange about the stack you just inherited? Ask why. Sometimes simply raising the question can be a catalyst for change.