5 tips for software engineers on asking questions more effectively

The guiding principle here is that questions are not free.

• There’s the obvious cost of you having to ask the question, but the less appreciated detail here is that the recipient has to context switch and then come up with an answer.
• If you consistently ask “bad” questions, e.g. questions that anyone can easily find the answer to or are so vague that they are impossible to answer, you’re eroding your social capital. People will be less inclined to help you because they know you need a lot of handholding.

As an engineering manager, here are 5 pieces of advice on communication I’d give to every new-grad or entry-level software engineer.

1. Make sure you’re asking a question.

At the risk of stating the obvious, are you actually asking something with an answer? For example, saying “I don’t get how X works.” is not a question and you’re making it difficult for the recipient to be helpful.

A better-phrased question would be “I don’t understand how this feature works; I thought it did Y, but it’s actually doing Z. What am I missing?”

2. Provide enough context so there aren’t any clarifying questions required.

The person you’re asking the question is likely working on something else at the time. Don’t assume they know what you’re talking about. You want to reduce the cost of context switching as much as you can by easing the recipient into your question.

You also want to avoid the recipient having to ask you more followup questions — a question should be a well-packaged unit of information with a clear request.

How much context should you add? Think of it like an onion:

• The people you’re working on the project with are the inner-most layer. They don’t require much additional information since you’re working closely together already and have a lot of overlapping context.
• The people one-level above, e.g. your manager, are the next layer out. They may require a bit more context as they likely don’t have all the technical details as you do.
• For people beyond that, e.g. the head of your product or a skip-level manager, definitely add enough supporting information such that they have all the information they need to answer your question. Assume they know little about the project; it’s better to overshare than undershare.

3. Tell me what you’ve tried already.

For debugging questions, tell me what you’ve tried already.

For knowledge-based questions, tell me where you’ve looked already (e.g. “I Googled it / searched our internal docs / searched team-wide emails”).

A bad question: “Why’s my script not running?”

A better question: “I ran X command and I’m running into E error. I googled the error message and saw it was a package dependency issue, but I ran the recommended fix and it’s still not working. Any other ideas?”

4. Limit the domain of possible answers.

A yes/no question is way easier to answer than an open-ended one. When possible, try to limit the domain of possible answers.

For example, “I’m trying to fetch from a transactions table; is the table name X?” is better than “How do I get on transactions?”

If all you need is the table name, then just ask for that. Make it easy for the answerer to give you a definitive answer.

5. What should the medium be?

Would this message be best in the form of a chat message, email, or an in-person sync? Some general guidelines:

• Chat message: Simple yes/no questions or questions with a definitive answers. For example, “Can you link me to the document that you mentioned in the meeting?”
• Email: Questions that involve more context and often require more thought and time from the responder. For example, a new project proposal with why we want to do something and the data that supports that decision; the email concludes by asking the recipient whether to proceed with the project.
• In-person: Questions that involve a lot of context sharing with a high branching factor. These are involved discussions where an answer will likely prompt many followup questions, so to cut costs of context switching, it’s better to sit in a (virtual) room together and hash things out. If you feel like there are too many asynchronous replies back and forth, it might just be easier to chat in person.

Another axis to think on is whether the question requires an immediate answer. I operate with the soft guideline that chats should be responded to within the hour (unless I set a do-not-disturb block on my calendar) and emails within a business day.

Did you like this post? Anything you want to hear more of? Please leave a comment and thank you for reading!