The importance of being willing to ask stupid questions

Last week I spent a day interviewing candidates for a programmer position. One of the candidates discussed things that he looked for in an organisation. Two things in particular struck me: He wanted to work in an organisation that, if he was making good progress, didn’t slow him down and that, if he asked a stupid question, didn’t call him stupid. The first question revealed the candidates lack of experience (not a problem in this case btw) but the second one is very important to a career in software engineering.

Is is very important to ask stupid questions. The amount that a developer is expected to know is huge. They must understand their own field of software development, which is rapidly expanding, the domain of their client and be able to think about both at the tiniest level of detail and the highest abstraction. It is inevitable that things fall through the gaps along the way, and often the only way to pick those things up is to ask stupid questions. If you are afraid to ask stupid questions you’re going to proceed much more slowly then you could otherwise. Of course, most people don’t like asking questions that they suspect might be stupid, but developers should consider this as part of their role.

One consequence of this attitude is that a software team, when it takes on a new member, must expect a whole series of questions from that newcomer about their domain, design decisions and working practice. They must allow for this in their planning and encourage this from that person. However, everyone has limits about being pestered about things that seem stupid, and my stated limit is that if someone asks me to show or explain to them the same thing three times I will be cross. Twice is ok (expected sometimes), three is not. I hope this encourages people to actively examine their level of understanding at whatever level of abstraction and document the processes they encounter (or, even better, review the documentation that exists).

Oh, and why did the first question suggest a lack of experience? Well, because we’re not actually paid by an organisation to write software (although generally of course, this is what we get a kick out of the most) – we’re paid to solve their technical problems in a sustainable manner. And generally this involves prioritising partial solutions. Thus if an organisation doesn’t understand why you wish to pursue a particular line of work, and you cannot justify that line of work in terms of a problem they have, then it’s legitimate for them to prioritise another piece of work for you. Sorry, but that’s just the way it is. You have the option to continue rich seams of development in your own time (I would say this was one of the primary motivations for open source software), or find an organisation that is more aligned with your own personal enthusiasms – this may mean starting your own.