Asking questions the right way

Table of Contents

In the software development realm, asking questions isn't just a right—it's a downright necessity. Let's cut the crap and dive straight in: if you're not asking questions, you're doing a disservice to your career as a developer.

Remember those early days, navigating the linux forums, throwing in a question, and getting smacked with a response so arrogant it could only be rivaled by a peacock in full strut? Yeah, that was us learning the ropes, the hard way. It was a brutal initiation into the art of question-asking, a skill as vital as coding itself. Can’t say I want to go back to those times. That’s why I want to talk about asking questions, so you don’t have to learn like I did.

Here's the kicker: asking questions isn't just about dodging the next error message or figuring out why your python script is dragging its feet like a toddler refusing to leave a toy store. It's about carving out the path of success for your project, ensuring everyone is marching to the same beat, and expanding your understanding of the domain you're knee-deep in.

Let's not just ask questions, let's ask the right ones, and let's do it without beating around the bush. Because in this game, a well-placed question can be the difference between a project that soars and one that’s ten times over budget. Let's get to it.

Before the Question

Alright, it's time to delve deeper into the anatomy of questions you ought to be throwing around in your daily grind. Essentially, we're looking at a two-sided approach here: tackling technical issues and navigating project management, which yes, involves dealing with people and their quirks.

First up, the technical questions. These are your bread and butter as an engineer. They're the questions that help you untangle code complexities, optimize processes, and essentially, just be a badass at what you do. These questions are your tools to chisel away at a problem until you reveal the elegant solution hidden beneath and get the AHA! moment.

Now, onto the project management questions, or as I like to call them, the "people questions". These are equally vital, if not more so. They're the questions that help you navigate the dynamics of a project, ensuring that everyone is rowing in the same direction. These questions help you gauge the pulse of your team, understand their concerns, and align their efforts towards a common goal. It’s about fostering collaboration through transparency — the more questions you ask, the clearer the destination gets.

Do Your Research

First things first, before you shoot any technical question — get intimate with Google or any search engine of your preference e.g. DuckDuckGo. I mean, really get in there. Dive deep into the ocean of information available at your fingertips. You don't want to be the one caught asking questions that scream "I didn't bother to look this up", do you?

Learn the search syntax that helps you isolate terms and look for exact matches of the issue that you’re looking solutions for — these are your life safers. For example, if you get an exception — look for an exact match of the error code, there’s always at least one person on the internet before you, who had a similar issue before and decided to share it. (We’ll talk about sharing later)

🏄 If your issue is not just an exception — start by understanding the core of your problem. Break it down into parts, and then start your hunt for information.

For example — your Hackintosh not booting is a complicated issue that should be broken down into multiple sub-searches. You’re going to start with general reasons why the PC can not boot, then dive into the boot loader, then dive into drivers, then into kexts, and so on — and each step will take you closer to a solution (might take you days though, from experience).

Look for similar problems or discussions online, delve into specialized forums, blogs, or library documentation — I can’t tell you how many times I’ve found my answer not on on StackOverflow but on some obscure highly specialized blog with a single post about the exact issue that I was having. Bless these kind of people.

The goal here is, hopefully, to solve your issue without asking, or to grasp the finer details of your problem, to understand the underlying concepts and find a light that illuminates a path to a potential solution.

So, gear up, do your homework, and come prepared with a question that reflects your effort and genuine curiosity. It not only saves time but also paves the way for a more enriched and insightful conversation. Remember, a well-researched question is the first step towards a meaningful answer.

Avoiding the XY Problem

Before asking any question, check if you’re not leaning into a common bias where you’re so focused on the solution that you think you need, that you ignore all the rest.

It’s called the XY problem — a scenario where you get so fixated on your perceived solution (X) to a problem that you overlook or bypass the actual issue (Y) at hand. This can lead to you asking the wrong questions and answers that don't really get to the heart of the matter.

To avoid falling into this trap, start by taking a step back to analyze the core issue you're facing. Ignore the solution. Assume you know nothing. It's essential to separate the problem from your initial approach to solving it. Be open to the possibility that your initial approach might not be the best or even the correct one.

Next, when formulating your question — don’t emphasize your perceived solution you have in mind, focus on articulating the problem. Remember, the goal is to solve the problem in the most efficient manner, not to get attached to a particular solution.

Asking the stupid questions

There's no such thing as a "stupid" question in the world of software development. There, I said it. Yes, there might be questions where you feel that the person did not put much effort into solving it on his own before coming to you, but there are no stupid question. Whether you're a junior developer or a seasoned staff-level engineer at Google — asking questions, even those that seem "dumb", is not just okay, it's necessary.

No one knows everything, and if senior developers show “vulnerability” of admitting stuff they don’t know, they pave the way for junior devs to feel comfortable asking questions. It's a win-win.

Ditch the fear of looking dumb. If you've spent a solid 15 minutes trying to figure something out on your own, you've earned the right to ask that question of your peers. And hey, if your question leads to more questions, that's even better — that means there’s even more stuff you will learn today.

Now, let's address the elephant in the room: the antisocial tendencies of many engineers. Yes, some engineers might prefer to keep to themselves, but showing that you've done your homework before approaching them can break down those barriers. It signals that you respect their time as much as your own.

There’s this concept of Slack channel where any question is allowed. Regardless of how dumb you think it is — it’s allowed. It’s basically a safe space where junior to mid-level devs can ask anything without fear of judgment, often finding answers among themselves. It works because it removes the pressure of bothering a potentially busy individual, fostering a community around not being afraid of asking questions in this channel.

So, let's redefine the narrative: there are no "stupid" questions, only opportunities to drive forward with genuine curiosity and a desire to learn. Let's encourage engineers at all levels to embrace this mindset. It's simple, but not easy, yet it's what propels us forward in the ever-evolving world of tech.

Identifying the Right Responder

Alright, now that you’ve done your homework, and for sure haven’t found the answer on the internet it’s time to understand the context of who should you ask the question. I’d like to point out, that the nature of your question dictates the ideal respondent and the channel of communication.

Here are some hypothetical scenarios that showcase that different questions require different medium and tone of voice as well as different levels of formality:

1. Code Issues - You’ve got a bug in your own codebase. Reach out to a colleague on Slack who works on the same codebase or consult the person next to you who’s works on the same team as you. If you know that the bug relates to some library, go to GitHub issues to ask the question there. You can look at it as informal query to fellow software engineers who might know the answer immediately or point you in the right direction.
2. Third-Party API Issues - You’ve got a bug in external codebase that causes a bug in your own. In case an external API is acting up — e.g serving weird data, your best bet is to check if they updated their documentation or to contact a representative from the company directly, preferably through email or phone, depending on how big the issue is. This is a formal scenario where you’re going to need to follow a process defined by your company in resolving this issue. (Highly likely there’s a key person that needs to be contacted in such events, and that person is defined in some document about this project)
3. Sudden Spike in Story Points - Noticed a sudden increase in story points in the sprint? Or the deadline suddenly moved? Address this in your team's Slack channel since it affects everyone involved, not just you. This is a semi-formal scenario where you’re trying to bring transparency to the project by discussing the issues openly with the team.

But as you see, different questions - different respondents - different ways to ask the question.

🏄 Choose your communication platform wisely — the medium through which you ask the question is as important as the question itself. If you send a message to someone in Slack, that you know is rarely there — then don’t wonder if it takes them weeks to reply. Know when to keep it casual and when to get all formal and serious.

Here are some rules of thumb that I try to follow (not saying you should do, but you can see how I approach these issues)

So imagine two situations where I don’t know something — either technical or from the management perspective.

Let’s focus on the first technical scenario first:

1. I will see if I can find an answer to my question via Google in the first 30 minutes.
2. If that didn’t work, and I don’t know where to go next, I’ll try to understand who are the key people in the company who’ve had experience with this, sorted by their experience AND their availability (I don’t want to stress people who are already stressed out).
3. I try to understand if the issue is complex enough that it will require a meeting or a simple message exchange will be enough.
4. I ask myself “how much time will I win if I ask them vs diving deep and trying to solve it myself”.
5. If I’m saving half a days work with a 15 min discussion — that’s a definitive yes.
6. When is the best time to ask the question, I don’t want to interrupt the person, but I also understand the urgency of my issue.

For the second scenario — when I have questions about the project that is not related to code:

1. First thing — check if the answer is in the internal knowledgebase or internal emails or Slack project channel.
2. How pressing is my issue? Is it a blocker for the team? Is it a nice-to-know or cant-work-without-it?
3. Figure out who’s the decision maker for this issue.
4. Write down what I know and formulate a question.
5. Ask the person if my assumptions are correct or if there are new developments? Is the information that I have accurate?
6. Is this information important to just me or does it impact everyone on the team?
7. Proceed to sharing the information with the team in a structured way if necessary.

I get that it’s a bit rudimentary, but it works. All project related questions must be asked in good-faith to show a certain level of respect to your peers and overall progress for everyone involved. So now that we know what to ask and who to ask, it’s about time we start asking.

Asking the question

Don't Just Say Hello

In the digital world, time is of the essence. Ditch the "hello" and other unnecessary preliminaries that serve as mere fillers. This is one of those things that annoys me a lot: when a person writes “Hello”, and that’s it, waiting for response. I would prefer people get straight to the point in the initial message, so I can understand if I’m the right person for it or should point in a different direction. It not only saves time but also signals that you respect the other person's time and are serious about finding a solution.

Don’t call someone out of the blue

Avoid making unscheduled calls to someone, as it demands their immediate and undivided attention, potentially disrupting their current flow. Also, just because someone responds to a chat doesn't necessarily mean they are available for a more in-depth voice or video conversation.

Instead of the abrupt approach or simply asking, "do you have time for a call?" — which is slightly better but still not ideal — consider framing your request more thoughtfully. For instance:

"Hey Name, hope you’re doing great, are you available for a quick X-minute discussion about XYZ in about Y minutes (alternatively at XX:00)?”

This approach is beneficial for several reasons:

1. It clearly indicates the expected duration of the call, helping to respect the recipient's time.
2. It provides context for the discussion, allowing the recipient to prepare or prioritize accordingly.
3. It sets the time of the call, so the person knows when to expect it.

If the recipient is unable to respond immediately, it serves as a reminder of the topic you intended to discuss when they do get back to you. By adopting this method, you foster a respectful and considerate communication environment.

Formulating the Question

Okay, let's get down to brass tacks here. Constructing a question that hits the mark is an art in itself. First off, lay the groundwork by stating what you already know. Be clear, concise, and straight to the point. Short, bullet-point style things that you have tried and learned about the problem.

Now, let's talk about the meat of your question. Avoid complex sentences that leaves people scratching their heads. Complexity is your enemy here; clarity, your ally. You want every sentence to have maximum value with zero fluff. The respondent doesn't want to wade through layers of ambiguity to get to the core of what you're asking.

Your ultimate goal?

1. A well-phrased question that starts with a subject
2. Has bullet point of what you already know about the issue (how you assume it should to be)
3. Things you already tried to fix the issue
4. A straightforward question that allows no ambiguity to what is expected.

There’s actually a great method for figuring out what you want to ask — the rubber duck method, it’s mostly used to solve hard problems, but it also helps you structure your thoughts in form of a question, as the duck acts as a sparring partner.

Acquire a rubber duck, preferably of the kind you'd find in a bathtub.

Position the rubber duck on your desk and politely tell it that you plan to walk through some code with its assistance.

Begin by describing to the duck the expected results, followed by a detailed walkthrough of each line of code.

As you articulate your process aloud, you may suddenly notice a discrepancy between what you intended to do and what the code is actually doing. Despite its silent presence, the duck has facilitated this realization, aiding you in identifying the issue

Remember, the quality of the answers you receive is directly proportional to the clarity and precision of your question.

Enjoyed the read? Join a growing community of more than 2,500 (🤯) future CTOs.

Email address

Subscribe

Free, no spam, unsubscribe at any time.

After the answer

After you've got your answer, it's not time to move on just yet. It’s time for some exercise in comprehension. Summarise what the person has told you and ask them if you understood it correctly.

Now, let's talk about the ripple effect of knowledge — it's time to pay it forward.

You can pay it forward in several different ways:

1. Next time someone comes you with a question — remember this moment and help them as you were helped.
2. Write down the knowledge in internal knowledgebase so someone can look it up later and find out the relevant parts without asking anyone (like you did).
3. If it's a cool issue that you solved — write a blog post, or linkedin post, or reddit post, share it in some way.

This act of sharing not only benefits others who might grapple with similar issue in the future but also reinforces your understanding.

That's basically it, hope it gave you some insights, if not, here are some more resources that might interest you:

• https://jvns.ca/blog/good-questions/
• http://www.catb.org/~esr/faqs/smart-questions.html
• https://blog.codinghorror.com/rubber-duck-problem-solving/
• https://dontasktoask.com/

---

Other Newsletter Issues:

• Rules of Thumb for Software Development Estimations
• Managing difficult software engineers
• Being a good mentor – a developers guide
• Things they didn’t teach you about Software Engineering