Please, Ask Stupid Questions
Last week I read about Jeff Atwood having some database problems on his new site. Being a popular blogger, he soon had hundreds of comments, most of them telling him how elementary his problem was and how disappointed people were that someone of his skill and reputation did not know how to solve such a trivial task as avoiding database deadlocks. Luckily, one person was wise enough to provide a different view (quoting an earlier comment):
“It’s always a little disturbing to see a well-known coder ask a dumb question, but come on, database locks?”
Wrong. Dead wrong and incredibly dangerous. And egotistical. If I were interviewing you I would immediately flip the bozo bit and thank you for your time.
It’s impossible to know everything. The hallmark of a good programmer is not what they know but their ability to learn what they don’t. If you do not promote an environment where any question can be asked, no matter how naive and trivial, problems become intractable because people are too afraid to ask for help. Just because someone has been in the industry for a while doesn’t mean they know everything.
Chris on August 25, 2008 12:09 PM
As children, we ask “stupid” questions all the time, and (hopefully) nobody gets their head bitten off for doing so. We might laugh and smile, but after all, we expect children to ask about everything, as this is how they learn. But does this method of learning stop being valid once we grow up? I hope not.
I remember once sitting on a public city bus observing a small child asking her father if the buses were on teams. The father, somewhat baffled by the question, did not seem to know what to answer. After a pause of silence, his expression of surprise transformed to a smile, followed by a short “no”, while trying to hide his laughter. The question may have appeared silly to the father, but considering we were on a red bus and a yellow one had just passed us, it made perfect sense to me. Assuming the child was familiar with the tradition of sports teams wearing different colors, it seemed logical that she would infer this also to be valid for buses. The analogy of sports teams might seem strange applied to public transportation, but even though both the yellow and red buses were operated by the same company at the time, the green ones were not.
In my opinion, there are no stupid questions, only stupid answers. Never bite someone’s head off for asking a “stupid” question—it can be very destructive. In these situations I think it is best to follow the good advice of Marge Simpson’s mother. If you don’t have anything nice to say, don’t say anything at all. Belittling someone by lecturing them on how trivial their question is, or how what they are asking about is something they should already know, does not really help anyone. If you don’t want to or don’t have the time to help someone, tell them so, but don’t ridicule them for asking.
Also, if asked about something you think the person should be capable of finding out themselves, you don’t have to give a direct answer. Often I find it better to provide the person with some reference material or relevant search keywords. That way they can do their own research, and hopefully gain a better understanding of the subject than a quick explanation or a direct answer to their question would have given them. When people do make an effort to conduct their own research, you should also be more willing to answer specific questions that may come up while they are studying the topic.
Often, asking a “stupid” question can reveal holes or misconceptions in your mental representation of a problem or knowledge domain that would otherwise go undetected. I much prefer someone to be honest about their uncertainties, and ask a stupid question, than pretending to understand something they don’t. In many cases you may not even be aware of your own lack of understanding until you do ask that “stupid” question, which is what makes asking them so important in the first place.
That being said, there is a huge difference between asking about something because you are unsure if you understand it correctly, or something is unclear to you, and asking because you are simply too lazy to look up the answer yourself or think through the problem properly. Personally, I ask stupid questions all the time, although these days most of them can be answered by Google or Wikipedia. However, if you do indeed make an effort to find and answer and you are not successful, please, don’t be afraid of asking someone.
"Tell me I’m wrong, but please don’t appeal to a straw man argument of being mean to people when they legitimately should know better."
I see your point, and I do understand your reaction. I didnt mean to hang you out in any way. I mostly quoted Chris for the comment about the importance of an open (work) environment, where any question can be asked without fear of being ridiculed.
I agree that we should have certain expectations to senior developers, but I also think that those expectations vary from person to person, depending on their own experience and background. For example, I learned assembly language when I was fourteen, but I dont expect other programmers to know assembly. Even though I think those that do have an advantage in many situations, I also know many skilled developers who never needed to learn assembly and thus never did. Similarly, I have never implemented a transactional database engine, and there are probably many concepts involved in doing so that I am not aware of or dont understand.
Personally, I am not surprised to learn that even experienced developers have trouble understanding transactions, database locks and parallelism. The topic may seem trivial to you, but I know many who consider the subject of parallelism inherently complex.
Anyway, my point here is not whether someone should know the theory behind database locks and implementation of transactions or not. Even if someone should know what they are asking about, I still think its important that they do ask.
You dont need to have implemented a transactional database engine, but you DO need to have kind-of-generally heard and read a few articles about CRUD and ACID after a relatively short time working with databases. Thats the core of my concern.
If the guys building software that we all know and love dont know about this stuff, thats a symptom of a really huge problem with education somewhere along the line. This material is covered in any undergrad class that mentions parallelism or concurrency - hardware should do it a bit, databases should do it a bit, multiprocessing should do it a bit, etc. If every industrial-strength coder out there isnt learning it, then maybe someone needs to take a look at why that is.
I agree, by the by, that questions are fine to ask. Better to know than not. But years of maintenance coding has taught me to seek the root of the problem whenever possible.