6 proven ways to ask better questions

6 practical tips to enhance your questioning skills within a team setting.

Great software is built by great teams.

Something I love about software is that a single person can build a great product.

But solopreneurship only takes you so far. To a product in a niche solving a very specific need.

The big software products everyone uses are built by teams of engineers.

The good thing about working in a team is that you can ask questions when you are blocked.

The bad thing is that most questions are bad.

Here are 6 ways to improve your questions

#1 There’s a clear call to action

Most times people ask things they don’t know what they need to ask for.

That’s fine when you are learning. But it’s easy to avoid once you have more experience and you know what support you need to ask for.

To ask a good question, be clear on what you expect from the answer. Most commonly it’s getting information or getting the other person to do something.

#2 It starts with the call to action

Start with that piece.

Most people may see the message and decide if they should act on it or process it later. If they know they can solve it fast, or they know it’s important because it’s blocking you, then they’ll more likely take action faster.

I need some help from someone experienced with <technology>

I’m not excited to go and answer that question even if I’m an expert in that technology. I don’t know what’s the problem, I’m going to just go and tag along for a while with that person. And I don’t know how long it will take me.

A fair counter-argument is you may need to provide some context. That doesn’t mean writing 3 paragraphs of preamble.

What I like to do is add some tags before my question so people know what I’m asking for

[Potato Endpoint][Integration Tests] Should we mock the database in the integration test? <Context>

#3 Answer the second question

When people read your message, most likely some questions will pop up in their mind.

You don’t want to engage in chatty messages. Especially with messaging, you’ll spend a lot of time as you are both asynchronously chatting.

You want to frontload as much information as possible to reduce roundtrips.

Re-read the entire text you plan to send and put yourself in the other person’s shoes.

#4 Show you did your research

People may point you to the documentation you already read to get more context. Or they may assume you already had read the wiki page where things are explained.

Instead of leaving this up to interpretation, show in your message what you have done and why it hasn’t worked.

This allows someone with experience to spot gaps in your process and point to the right source to solve your blocker.

#5 Choose the right venue.

Prefer public forums over private conversations.

Private chats are not scalable. A public forum alleviates the workload since multiple people can answer. They also allow for knowledge sharing and for other people to find them later when they are doing their research.

And avoid pinging @here in those public channels. You don’t want to bother an entire team to look at your question.

#6 Follow up the question with the solution

You may have gotten the answer in that same public forum. Or it may have been your research, an in-person conversation…

Whatever it was, make sure to go back to your question and write what solved your problem.

This is a lifesaver for the people who come back to it in the future.

🎯 Conclusion

Asking a good question is a way to clarify your own thinking.

I have found the answer to more problems when I decided to start drafting the question than working by myself.

Use the process of asking a question as a debugging mechanism.

Your goal isn’t to avoid asking the question. Your goal is to ask the best question possible

🗞️ Other articles people like

My strategy to deliver more results

🔱 3+1 strategies to track your achievements

An engineer’s guide to unlimited motivation in a corporate job

😎 My strategy to become a TOP 1% engineer

👏 Weekly applause

• IC Promo "Champions" by

  The Developing Dev
  . Concise article highlighting that a promotion won’t happen with you working isolated. Work with other people and ask them to pay attention to your work so they can provide their input in a future promotion

• Seniority by

  The Polymathic Engineer
  . Value is not provided only by lines of code committed. The more senior, the more things you could be doing, but you have the same hours. In some situations is knowledge sharing so a team of 8 can work. In others is writing the first piece of code so others can follow the patterns you set.

• How to set priorities? by

  Tech World With Milan Newsletter
  . A solid compilation of productivity and prioritization techniques. I liked the combination of techniques, such as acknowledging your energy levels and working depending on those levels. Do the most important task on each bucket, rather than trying to do a hard and complex task for 16 hours a day.