This one’s a quickie.
There are stupid questions – you know, things that with a tiny bit of work, you could get the answer to yourself. (The origin, no doubt, of the site Let Me Google That For You). Or questions such as… if I stick a fork in this light socket, will I get electrocuted? (Answer: yes).
No-one wants to look stupid. In fact, people will take great pains to avoid looking stupid. This is a really bad idea though – because it can get in the way of real progress. There are plenty of questions which could be answered twice as fast if you just let your ego go, and spoke up instead. This is the basis of putting together an egoless team – something practiced at Surreal, and at X-Ray Kid; the idea is to reduce that barrier, by encouraging people to talk and ask questions. If you get stuck? Go talk to someone! People get stuck all the time – there’s no excuse for sitting there and being stuck when you could fix the problem in five minutes instead of three days by going and talking to a peer – no matter how silly or stupid it makes you feel.
In fact, you’ll feel less stupid when you realize that you could have spent hours on it, and instead you found out the answer much quicker.
Now, there’s another kind of question which is very similar to the “stupid” question, but subtly different.
That’s the naive question.
Naive questions are great. You should ask them all the time. A lot of people get stuck thinking about the nitty-gritty details of a problem. While a naive question looks silly at first (and a good percentage of the time they are silly in reality), about 1 in 5 times, that question will make people stop, and suddenly reassess their assumptions.
It’s like a laser-guided can-opener that lets you jump straight into the middle of a problem. Worst case? Your assumptions get overturned. Best case? All of a sudden you’ve laid bare a fundamental issue.
It’s hard to figure out which is which – a stupid question or a naive question – so err on the side of asking anyway. It’s worth it, and allows you to perform miracles.
(In short, naive questions challenge assumptions and allow you to build models of systems. Do it often, do it early).
Simon Cooke is an occasional video game developer, ex-freelance journalist, screenwriter, film-maker, musician, and software engineer in Seattle, WA.
The views posted on this blog are his and his alone, and have no relation to anything he's working on, his employer, or anything else and are not an official statement of any kind by them (and barely even one by him most of the time).