Why Your “Bad Questions” Are Good (and Necessary)

Like many people, I have a certain fear of being That Person – you know, the one asking a ton of annoying or obvious “bad questions”. Julia Evans’ awesome comic/blog post on asking good questions is one I return to over and over.

At the same time, though, there’s a lot of value to asking some not-so-great questions when building software. Open-ended questions and questions that seem to be confirming the obvious can help interrogate assumptions and make sure we build the right thing, as well as building the thing right.

So today, I want to talk about a few different types of “bad” questions, and make the case for just asking the question regardless of its objective goodness.

Did you mean X? (the nitpicky question)

Let’s say I have a story for an admin user login with the following acceptance criteria:

•  when I visit /sign_in
•  and I enter my email and password
•  I am logged in and redirected to /

…but when building the login for regular users last week, we discussed admins having a separate home page at /admin.

This feels like a nitpicky question. The AC writer probably meant /admin, after all. Taking a minute to make sure I’m on the same page, though, clarifies the issue for the whole team.

Odds are good, though, that someone on the team will have the same question at some point.

The ticket will probably fail QA, for one thing, since QA uses the AC to determine what the expected behavior should be. Plus, another engineer working a related ticket may make the opposite assumption and end up with a lot of conflicts. Clarifying the issue now prevents a snowball effect of problems later.

Sorry to interrupt… (the badly timed question)

“We’re all set, I just need someone with admin access to add this integration to the repo.”

“Ask Jim – he’s the only admin on that, as far as I know.”

In this hypothetical situation, there’s only one person with admin access, which isn’t something that happens terribly often at Revelry. But if it does come about, I can’t worry too much about finding the best possible time and context to ask at a time when I won’t be interrupting Jim – I owe it to my team and the project to spend as little time blocked as I can.

This is where Revelry’s Core Value of Earn and dispense trust comes into play. I trust that if Jim needs interruption-free time, he’ll mute notifications or otherwise take steps to preserve his concentration and get back to me when he can. Jim in turn trusts me to judge whether I could ask my question in a public channel rather than asking him specifically.

Why are we doing it like that? (the inconvenient question)

While planning database relations: “So families have many children, and each child has one mother…”

“Why only one mother?”

This is a bit of a silly example, but you get the idea. On the one hand, my coworker knows what they’re doing, and maybe they’ve already thought about how this database could handle complex or unconventional family relationships.

On the other hand, maybe they haven’t, and by questioning the assumption that children or families have one (and only one) mother, I’ve kept the product from excluding a lot of people and saved the team from having to spend a lot of time fixing this problem later.

The sprint commitment is in danger and I’ve been stuck on this mystery error for three hours but I think I’m really close question

I’ve probably progressed well into the profanity stage of debugging at this point, and I don’t have a specific question so much as an error message, a stack trace, and a pile of discarded theories. Besides, I know I can solve it in another half hour.

Asking for help feels like a “bad question” because it can seem like I’m shifting the responsibility for the problem to someone else. The thing about these roadblocks, though, is that at some point when I’ve been staring at a problem for hours, what I really need to solve it is a change in perspective.

Sometimes I can get that from taking a break and distracting myself a bit so I can look at the problem in a new way, and sometimes I need to get an actual other perspective, which entails running the problem by another person. They might be able to point out something that I’ve missed.

You may have noticed a common theme running through this piece – when in doubt, ask the question.

Best case scenario: you learn something and help the team improve. Worst case scenario: you won’t get an answer, in which case you’ve just learned something about how not to ask a question. Either way, you can move forward the wiser for the experience.

Asking dumb questions is the first step to asking smart ones. [h/t Curtis!]