5 Reasons to Get Comfortable Asking 'Dumb' Questions as a Software Engineer

Ever sat in a meeting where your co-workers were discussing a complex feature or strategy, and just realized “I have no idea what is going on right now”? Or everyone’s throwing an acronym around and you have no idea what it means? How do you handle it? Do you just sit back and drown in the voices or do you speak up and say, “Hey guys, I’m totally lost. How does this work?” or “Can someone tell me what HYUUP means?”. Speaking up feels akin to exposing yourself as the fraud in the group. However, I’m the biggest advocate of asking dumb questions.

But first, let’s define what dumb questions feel like. They are the questions you ask when you feel like everyone else in the room understands what is going on except you. They are also the questions you ask when a topic seems really obvious, but you still need to clarify that your teammates are saying exactly what you think they are saying.

We know that a huge part of engineering culture is “belonging” to this group of seemingly smart people who know how the internet and all its moving parts work. No one wants to seem like the dummy in that group. Interestingly, I’ve come to find that the people who ask the dumb questions produce the best outcomes. Here’s why.

5 reasons for asking dumb questions

1. You need absolute clarity to do your work

There’s nothing more discouraging than working on something you don’t understand. And by this, I don’t mean you don’t understand the tech. I mean you don’t understand what you’ve been asked to do. Imagine you’ve been asked to build a feature or product and the requirements are not clear. But your product manager and engineering leads have both expressed to you that “this should be pretty simple to implement.” What’s your next step? Well, it may seem simple to them, and that’s great for them. But you don’t understand what they are talking about, so it’s definitely not simple for you. At least, not yet.

You need to ask for more details. Walk through the user requirements with them. Ask them to explain it to you again. I’m giving this advice with the assumption that you work in a healthy team where people are encouraged to reach out for help if needed. If you don’t, well… I don’t think I should tell you what to do, but you know what to do.

The reason why you need absolute clarity is because programming is very precise. You translate requirements into code, and that code does exactly as you’ve defined, given the conditions. How do you know the conditions to account for if you don’t understand the requirements? That clarity is the difference between expected behavior and a storm of unforeseen outcomes.

2. You force people to think through their requests

As a software engineer, I’ve gotten requests where, within a minute, it’s obvious the person hasn’t thought it through. You probably have, too. The question is, do you take on the burden of their lack of clarity, or do you force the both of you to walk through the logic together? I prefer the latter because it gives better results every time.

Ask questions until you both understand what is required and why. Only then can you properly start on the execution.

3. You contribute to shaping the product

We should all care about the things we build. As an engineer, you’re spending several hours a day writing chunks of code that will eventually make up important parts of a product. Whether you plan to work on that product for two months or two years, you should be concerned about how your contribution shapes it.

By asking simple questions, you get to the root of the tasks being assigned to you. You can help refine the ideas, suggest improvements to them, or even help avoid drastic mistakes. You hold a lot of context that the non-technical members of your team do not have. That comes with some responsibility. So, ask the simple questions. Use “why” until you truly know why.

4. You advocate for your users

If you’re a product engineer, then you have users. They could be internal or external, they could be paying or not, but someone somewhere relies on your product to solve a problem they have. We should all build with this in mind. Ask dumb questions so that you can properly understand how a request will affect your users once implemented.

5. You enjoy your work better

Who enjoys working on something they do not understand? Definitely not me. Instead of complaining about the lack of clarity in your tasks, ask the needed questions. You will all be better for it.

And that’s it, folks! I hope these points are enough to get you started on asking more questions at work. Not the right question, or the smart questions, or the questions that make you seem competent. The DUMB questions. Go ahead, I promise, life’s better on this side.