melreams.com

I was listening to the Developer Tea podcast the other day and caught a re-air of an episode about how to handle questions that you don’t have good answers to. The very short version of their answer (which I totally agree with) is don’t say “I don’t know” and stop there, follow it up with “but I can find out.” And then, you know, actually find out and follow up with the person who asked the question :)

It’s been such a long time since I worried about that that I forgot it was still an issue for people. I’m not saying I feel great about it when I get asked a question I can’t immediately answer, but my perspective is that my job as a developer is much more about knowing how to figure stuff out than it is about knowing the answers off the top off my head. I’m not Google, and it’s not reasonable to expect me to be.

My theory (and readers, if you think I’m out to lunch here, I’d appreciate you letting me know in the comments) is that newer devs are more likely to freak out about not knowing the right answer because they’re used to having to produce an answer right away or lose marks on tests in school. One of many, many ways being a professional developer is different from school is that there’s no time limit and everything is open book.

Seriously, no reasonable person is going to react badly if you tell them you’re going to find the answer and get back to them. And if they do react badly, they’re a jerk and if that jerk is your boss, you should seriously consider finding a new job. Production applications are just too complicated for any one person to remember every detail of the back end, the front end, the database, the logging, the monitoring, the API, the deployment process, or whatever other pieces you deal with. It’s just not possible for a person to memorize every detail of a complex system and if you think it is you have no business managing developers.

Speaking of complexity, a completely reasonable answer to a question might be “Amy built that feature, she would know better than I would.” Just telling someone where to look or who to ask is really helpful, it’ll make it easier for them the next time they need an answer. Sometimes, say if your boss asks you a question, they might need you to do the legwork and go ask Amy for them, but that doesn’t mean it’s not helpful for the next time they have a question about that feature.

Unlike school, very few parts of professional development involve a time limit. Sure, if production is down you’re going to want to figure out why as quickly as possible, but even that is more about problem solving skills than it is about having stuff memorized. If my boss asks me a question, it’s far more useful to them to take five minutes to go look it up and make sure it’s right than it is to spit out an answer right then and there.

Basically none of professional development is closed book, either. That’s one of the reasons for my very limited interest in general knowledge questions in technical interviews (the other one is that a stressful, high stakes situation like an interview is going to give you false negatives because people go blank when they actually know the subject perfectly well). Not remembering the difference between a StringBuilder and StringBuffer is never going to matter in my career, that takes about 30 seconds to Google.

“That’s great,” you say, “but what if I do all my research and I still don’t know what the best option is?” That’s totally fine! Write down what you learned and share that with your boss/whoever asked you the question. I’ve had plenty of conversations with my boss where I showed them what I found and straight up told them “I don’t know what the best thing to do is, but here’s what I found.” As long as you’ve done something to help find the answer you’ve at least saved your boss the time it took to research it, that’s still helpful.

Not knowing the answer is just not an issue as a developer. The issue is if you don’t make an effort to find the answer, and making an effort is something anyone can do.