Natually as huamns you will not be able to know every knowledge in the world. But what you can do is to hone that ability to acquire knowledge. One of the ways to go about that is to ask questions. Learning how to ask good questions as a software engineer generally has 2 parts to it:

1. the ability to have EQ and not be an asshole in your questioning
2. asking questions in the context of SE conversations.

The ability to ask the 5 types of question. The ability to ask questions

The book’s 5 sections

1. Why we don’t ask good questions (we are more interested in scoring points, we are afraid to ask, we don’t know how to do it well)
2. The Socratic attitude (show courage, become curious, embrace not-knowing)
3. Conditions for questioning (be a good listener, ask permission, slow down)
4. Questioning skills (question up and down, beware of using why, category errors)
5. Moving from questions to conversations (following through, opening yourself up)

1. What is a good question?

• A question is an invitation. An invitation to think, explain, sharpen, dig deeper, provide information, investigate, connect.
• A good question is clear and born of an open, curious attitude.
• A good question remains focused on the other person and their story.
• A good question gets someone thinking.
• A good question can lead to clarification, new insights or a new perspective.
• A good question doesn’t give advice, check hypotheses, impose a perspective, share an opinion, make a suggestion or leave the other person feeling judged or cornered.

2. 6 Reasons why we are bad at asking questions

1. Human nature

Talking about yourself feels so much nicer than asking questions.

We should avoid the “I have similar story” angle. We may intend to create a shared experience but it often irritates and alienates the person telling the original story

2. Fear of asking

Pointers to look out for
Does anyone need to know what my stance on an issue is?
Am i interrupting their story to tell my story?

3. Diff between ideas and opinions
   try to question ideas and not opinions. If you question opinion, the owner of the opinion can feel threaten. When something is an idea without an owner, we can boot it around, hurting noone and learning more.

4. Separate observing and interpreting

Must learn to suspend judgement where possible.
If a person is walking quickly, do you say that he is in a rush, but that he walks quickly.

If a person is eating quickly, do not say he don’t know how to chew his food, say he is eating quickly.

5. Empathy is a two-edged sword
   Cognitive empathy
   Emotional empathy
   non-empathic compassion (creating the desire to help) rather than empty.

• Feeling another person’s pain affects your ability to judge objectively.
• Compassion allows you to dig further and ask questions about the person rather than yourself, and that in-turn allows you to help.

6. Good conditions for questioning
   Listening begins with setting your intention for a conversation

• The I intention - what do i make of this conversation?
  • You engage with the situation by considering what you would have felt or done in a similar situation
    • this position triggers a fix or advice
• The You intention - What exactly do you mean?
  • Listening with this intention reminds you that there is a lot you don’t know about the other person’s experience or perception. You should try to understand the other person’s way of thinking. You never give advice or explain how you would have dealt with the situation. You questions focus on getting deeper into the topic
• The We intention - how are we doing?
  • This is a meta position, observing you and the other person as if from above, you are conscious of how you are feeling and how the other person is doing, is the convo going in circles, how is the body language.

If you adopt you intention, don’t be a detective. Don’t cross-examine. Asking for permission is a great way to ease into a conversation. Do you mind if i ask you a few questions about it?

7. How to improve your questioning skills

Technique: questioning up and down.
questioning up: abstract concepts and downloads facts and reality

This technique should allow a person to move downwards until they establish the facts, and the ‘critical moment’, a key point/statement/fact/attitude around which the entire conversation revolves. Then the questioner can repeat the data they have heard and move upward to establish the underlying beliefs.

Downward questions: towards facts, events, statements

• when did this happen?
• What exactly did he say?
• What happened from there?

Upward questions: towards concept, underlying beliefs

• Why is that?
• What do you mean by this?
• What does x have to do with y?

8. Beware the ‘why’ question
   The content of your question is just as important as the delivery of your question.

Take the time to understand how you deliver in itself delivers a message. It could be a message of respect, of admiration, or interrogation.

Why can feel like a direct assault. instead of why, ask,
Why are you voting for party X? => what is it about party X that caused you to vote for them
why do you hang out with Y? => what makes Y a good person to hang out with?

9. Six categories of questions to avoid

• Loser questions: implying the other party is a loser.
• But questions: But says i already have an opinion about this, but im not saying it directly.

“But don’t you think you should have intervened in the situation”, “but don’t you think this piece of work needs re-doing?” “But don’t you think Mark is a bore”. Even without a negative, it can totally change a question. “But why did you include John” differs from “why did you include John”?

• cocktail questions: you ask too many questions at a time

  “Why did you do that, and why then? Oh, and you added Mary, didn’t she work on this before? Did that end up well for her? What are you going to do next?”

• Vague questions: Unclear what the questioner is looking for.

  For example, “was the concert good?” may get a different answer from ten random participants. Instead of asking “Is that tower high”, ask “how high is that tower”, or instead of “was the meal tasty”, ask “how did the meal taste”?

• Unwarranted either/or question: giving only 2 options when there are more on offer.

  “Do you want to meet today or tomorrow?” (you may want next week or never!). “Are you a vegetarian or do you eat meat?” (you may be a vegan or pescatarian).

How to ask better questions as software engineer?

1. Research before hand
   Try to find a solution yourself first. Figuring it out yourself could save others the time to point you to the first answer on the first page of google.

TImeboxing your research. Nothing more than 1 hour is good and sufficient time to research about questions. In that focused 1 hr, you can have insights on the basis of your questions, challenge some of your assumptions and gathered sufficient general knowledge.

If you can actually find your answer within a few minutes of research, you are probably overly reliant on others and depriving yourself of the opportunity to develop your searching skill.

2. Give context
   What are you trying to ask?

Good example:

• “My deploy failed. Can you help?”
• “My deploy on service X failed with Y error message in the logs. The most recent change I made was Z. Can you help take a look? You can view the logs at [link] and you can view the pull request for my change at [link].”

Giving more context to your questions and perhaps your previous attempts at the problem can help save the other party alot of time and effort. It makes helping you easier.

3. List out what you have tried so far

listing out along with your initial question can help to reduce the unnecesary back and forth on approaches you have already attempted. Perhaps after listing out all your attempts, the other party realized that they needed to get you connected with other people already. That saves the conversation from starting entirely. (assuming the person is doing so in good faith)

4. Write down the answer
   Be intentional to write down your question and answer somewhere so you don’t have to ask others the same question again. If so, perhaps you are not too respectful of other people’s time.

Cultivating a culture of knowldege sharing and public documentation helps people to onbaord quickly, reduce interruption and creates the rate of entering into flow state.

TLDR

Good software engineers learns how to communicate verbally and on paper. You learn how to find out an answer, structure your question, understand a new topic at hand, transfer and share knowledge asynchronously.

Beyond just good coding ability, if you want to work on something big, you need a team; and work in a team.

Reference

• How to know everything?
• The art of asking questions