When I was an instructor at Girls Who Code and Techtonica, my absolute favorite lesson to deliver to students was one I had created around asking for help. Why? Three reasons:

  1. Asking for help tends to be the most emotion-filled aspect of being a software engineer, but I love helping people understand that it doesn’t have to be!
  2. It’s the most powerful tool someone can use to spark their skills growth, which leads to career growth.
  3. It’s a skill everyone has complete power to develop and perfect.

The do’s and don’ts that follow are a distillation of the instructional lesson I’ve honed over the past couple years. My goal is to help you completely rethink how you ask for help as a software engineer.

Don’t: Fall into the trap of thinking negatively about yourself if you need to ask for help

The universe of knowledge within software engineering is absolutely enormous. Even core contributors to a programming language like Python specialize in different areas of the code base and probably couldn’t answer every single question you might throw at them. “Not knowing” is a natural part of being a software engineer.

A wonderful thing about our community is the wealth of resources available to us freely online to help us troubleshoot our problems and work towards solutions. On top of that, most engineers recognize that neither they—nor anyone else—will know how to do everything all of the time.

So there’s never a reason to beat yourself up for needing to ask for help. Our brains tend to jump to the hyperbole of: Since I don’t know how to do xyz, I am a failure and do not deserve to be here.

I want to tell you that that couldn’t be farther from the truth. It’s safe to replace “I should know this already” with “Even though I’ve come across this concept a couple times, I’m still working on making it stick.” Instead of fearing that you’ll be judged for asking a question, recognize that everyone around you has gotten to where they are by also asking questions.

Don’t: Spin your wheels because you’re afraid to ask for help when you need it

It’s tempting to tell yourself “just 5 more minutes!” when you’re stuck on something, especially if it seems small or you think the solution would be obvious to someone else. The problem with this habit is that you can wind up spending 20 minutes, an hour, half a day… not making any progress.

The way I prevent myself from wasting time like this is to commit to spending no more than half an hour trying to solve my problem on my own. If I haven’t made significant progress in that time, I ask for help.

On the other hand, if I’m relatively certain that one of my teammates knows the answer to my question off the top of their head, I’ll go ahead and ask them if I think it will save me at least 15 minutes. This is a shared value on my team—we’d all rather spend 2 minutes quickly solving something for someone else, than have someone on our team wasting 15 minutes.

Do: Remember that asking questions gives others the opportunity to feel helpful and knowledgeable

I don’t know about you, but when I have the opportunity to answer someone’s programming-related question, it feels great to be able to help them out. On top of that, being able to teach them something is a signal to myself that I’ve learned and retained a particular concept.

These are really great feelings to have. They’re interesting feelings because in order to feel helpful and to feel a sense of mastery via teaching, we need someone else to be the recipient of our help and of our teaching.

Not to sound too corny here, but I challenge you to think of asking questions as an opportunity to exchange little “gifts”— you give to your colleague the opportunity to feel helpful and knowledgeable, and they give you their knowledge. I think that’s a good trade!

I write for early-career software engineers like you. Subscribe and never miss a post!

Do: Get to a place where you can ask the question without emotion if you’re feeling frustrated

In my past roles as a software engineering instructor, I’d often encounter students who had waited too long to ask for help, became frustrated, and had lost the ability to be emotionally detached from what they were working on. (“I have to figure this out or else I will never be good at coding!”)

If I could sense from a student’s body language that they were frustrated—slumped shoulders, chin deeply in palm, dejected tone—I’d ask them to go take a walk or get a snack before I’d sit down to debug with them.

The reason I did this is because frustration can close off one’s creativity, openness, curiosity and willingness to try. As I’m sure you know, these qualities are essential for problem solving. If you find you’re lacking them, take a break until those can-do feelings come back.

In addition to that, bad energy spreads like wildfire. Be kind to your teammates and contain yours.

Don’t: Call your question (or yourself) dumb

How many times have you sat in a classroom or a meeting and heard someone say something like, “Sorry, I have a dumb question…”, and then proceed to ask a question that 1) wasn’t dumb, 2) was the same question you had, or 3) was actually a really good question? My guess is that you’ve seen this happen a lot. I sure have.

What someone is really saying when they do this is: I’m anticipating you will judge me for asking this, and I’m going to acknowledge that in advance to soften the blow.

It pains me when I hear “Sorry, I have a dumb question…” because it undermines the speaker by exposing their lack of confidence. This preface paints them in a worse light than if they had just owned their question from the beginning.

Here are some much more effective phrases you can use instead, though my preference is to not use qualifiers at all. These phrases are more effective because they all communicate that the speaker is owning their learning experience.

  • “Since I’m new to this, I’d like to ask…”
  • “I have a question about something I haven’t come across before.”
  • “I’ve seen this concept before but haven’t yet had the chance to study it.”

Do: Be thorough when preparing your question

After you’ve asked your question, the person you’re asking should have a full picture of the situation without having to ask you for major details. It’s OK if they need to ask clarifying questions, but you should do the work of preparing all the info they’ll need in advance. These are the intermediate questions I ask myself in order to extract from my mind the details I need to share to communicate my problem effectively:

  1. Ask them if it’s a good time to ask a question about my specific issue.
  2. What am I trying to do?
  3. What is my blocker?
  4. What background info or skills do I possess that are coloring my assumptions or approach?
  5. What have I already done to try to solve the issue?
  6. What resources have I already used to try to solve the issue?
  7. Make the “ask”.

Do: Ask specifically for what you need

When I get stuck, the question I often have in my head is How do I do xyz?. I’ve noticed that this thought is often a stand-in for other, perhaps more useful questions, like:

  • What do you think I should try next?
  • How would you approach this?
  • Can you point me in the right direction?
  • Am I on the right track?
  • What should I be doing differently?
  • Can you help me understand…?
  • How does our team approach…?

Asking for the specific thing you need is usually way more effective than asking something generic like How do I do xyz? because the response you’ll get will be better targeted to your situation. Try it and see for yourself!

I write for early-career software engineers like you. Subscribe and never miss a post!

I hope these 7 do’s and don’ts of asking questions has helped you shift your perspective on asking for programming help! It’s so important to our productivity and skills growth to have the mind set and the confidence to do what we need to do to get un-stuck.  

What tips do you have for asking better questions about programming? Let me and other Empowered Engineers know in the comments below!