Leveling Up Skill #17: Asking for Help

Reading Time: 12 minutes
Sorcerers Apprentice
Painting of “The Sorcerer’s Apprentice” by Jim Salvati. Buy a print: https://www.disneyartonmain.com/the-sorcerers-apprentice-disney-art/

*Heads up: I use the term “dumb” twice in this post. That word is ableist. I use it here for clarity while debunking a specific quote. In general, I recommend replacing this word with a different word (like ignorant, foolish, thoughtless, or brash) that does not cause harm to a marginalized group.

This post is part of a blog series called Leveling Up: A Guide for Programmers. The series covers skills you can use to learn faster, more easily, and more strategically as a programmer.

So far we have talked about things that you can do by yourself, with resources that other folks have already created, or from the feedback of your colleagues. Today, let’s talk about some options available to you when you’re struggling with something and would like some one on one help.

This is the first in a three part series about asking for help:

  1. Asking for Help
  2. Who to Ask, How to Ask
  3. Seeking Longer-Term Help

In this post we’ll be talking about help in the time frame of one question or one project.

Why seek out one on one help?

People learn differently. Some folks internalize information by reading, some by writing, some by listening, and some by talking. I internalize information chiefly by writing, and also by engaging with the material with another person.

I have learned the most while on the clock by asking questions of (or with) others. I pair programmed 6-8 hours a day for about three years. This gave me opportunities to experiment with code alongside folks with a different perspective than mine. Sometimes that perspective included more experience in the technology we were working with than I had.

Though I did (and do) a lot of solo learning, solo learning has a weakness: it is bounded by the information available in the source we’re learning from. Many of the leveling-up skills we have discussed so far in this series focus on getting around those limits. For example, we talk about active reading as a way to get around the bounds of what a single resource has to say on a topic. We also talk about commit tracing, in which we explore software libraries by looking at the implementations of the methods we use. These techniques sometimes still don’t unearth answers to all our questions. In these situations, I have had a lot of luck with seeking out an expert.

But what if I end up looking ignorant for asking an ignorant question?

So, first of all, I know people love to say “there are no dumb questions.” I don’t subscribe to that.

There’s no such thing as a question you shouldn’t entertain. There is such a thing as a question that you shouldn’t ask a person. And you can avoid asking them by doing your research.

As someone who does a lot of advocacy work, I often get asked questions that would take me a lot of time and care to answer. For many of these questions I know, for a fact, that the person could have googled and the top result would have been at least as good as whatever I could come up with. Though the asker may not mean it this way, that comes off as willful ignorance predicated on the belief that my time is not as valuable as their time. Before you ask someone your question, do a quick check of your other available resources. Don’t waste hours of someone else’s time because you didn’t want to devote ten seconds of yours. 

Suppose you googled and you did not see an answer, but you still worry that asking this question will make you look uninformed. You dread the idea that someone might say “oh my god, how do you not know this?” You’ll be a laughing stock. They’ll see you as a hack!

There are helpful people who will gladly answer your questions. There are also jerks who will try to make you feel small for not knowing things. Maybe they’ll make stuff up to hide the fact that they don’t have the answer. Some especially jerky jerks will do both of those things for the same question!

Here’s my recommendation: lean in the direction of asking the question, even if you’re not sure how people will respond to it. 

Here’s why:

1. It’s common for folks to respond better than you think they will: I have been regularly floored by the willingness of both colleagues and strangers to help me when I am having trouble.

  • I have had the core maintainer of a library pair with me until my niche implementation was working.
  • I have had a graduate student who used a boosting library send me a detailed explanation of the data structure used by the library.
  • I have had developer advocates offer balanced, considered advice on how to implement something their competitor’s software.

In each of these cases, I would either have never reached the conclusion these people helped me reach, or it would have taken me a very long time.

I like to pretend that most people want to help. I have no data to support or refute that, but by acting as though it were true, I find the people who will help me.

 2. If folks respond crappily, it’s their problem, and the consequences will eventually be theirs to bear.

We talked a little bit about questions in this blog post on growing software teams. Our industry notoriously collects question jerks:

Developers are not always kind to other developers who ask questions—especially questions that they consider to be ‘easy’ or ‘basic.’ In fact, developers are so bad at this that several developer education academies have specifically banned the demeaning way that developers react to questions they know the answer to.

OK, so these jerks make others feel bad for asking questions. But why would the consequences ultimately be theirs to bear? Here’s why:

No matter how good at something they are, if they make it unsafe and humiliating for people to ask them questions, they will never be viewed as a go-to expert—nor reap any of the career benefits that come with that distinction.

So when someone responds crappily to you, you can remind yourself that the upper echelons of the technical career track will ultimately be closed to them. This is another thing that is not necessarily precisely true, but thinking of it as true has definitely helped me stay motivated and curious when faced with one of these jerks (that, and writing down their names in a notebook, just in case I ever need to remember).

3. The consequences to you of asking a ridiculous question are not as high as you think they are.

The fear here usually seems to boil down to this: “people will think I don’t know my stuff, and that will get back to my boss, and then my boss will think I don’t know how to do my job, and then I’ll get fired, or maybe I won’t get promoted.”

So, on firing: it’s harder to fire someone than you would think.

Companies don’t want to do the paperwork or offer the severance without the work product, and managers bellyache about the awkwardness of having to initiate an uncomfortable conversation. So they’ll often hold out for a while and see if the person quits on their own. This is why “managing out” is a thing: firing someone is enough of a pain in the neck that it’s easier for companies to wage a costly and annoying war of attrition so the person quits. I’m not saying companies never fire people. I am saying it isn’t likely to happen because you asked one question that made others think less of you.

It’s even less likely to happen if you are showing clear progress. I have seen folks get fired over staying at too low a skill level. These people usually weren’t progressing too slowly—instead, they weren’t progressing at all. This was, I should say, just as much the company’s fault as it was theirs: the way their managers brought up their skill levels with them scared them into going into defense mode, staying in their little corner, and not asking any questions for fear of revealing further underperformance. That behavior, combined with the fact that the company lacked clear documentation or instructions for the person to get the answers they needed without asking someone, resulted in no further progress. So no, not entirely these people’s faults that this happened. But if an underperforming employee continues to ask questions and show a modicum of progress, management would often rather use this as an argument to keep them around than subject themselves to an uncomfortable termination conversation.

Let me put a disclaimer on this whole statement: firing policies depend on the company, and companies often also apply their policies very differently on a person-to-person basis depending on the manager’s personality, the manager’s opinion of the person, and a number of other factors that definitely should not matter. I cannot guarantee anything with regard to whether you’ll get fired for asking questions. That said, I have seen a few firings in my day (and a number of “team reassignments” and other things that would have been firings if firing were easier). Underperforming in the presence of progress has resulted in backhanded comments, mistreatment from colleagues, and scare tactics. However, it has not, by itself, resulted (in my experience) in someone getting fired.

Also, on promotions: as a technical contributor, you are probably not going to get promoted anyway.

It’s sort of a joke in the industry that if you want to move up, your best bet is to find the position you want as a job opening at another company. There’s a reason for this: when someone is already delivering superior output, there’s no benefit to the company to promote that person to senior, lead, or principal for them to continue delivering the output they already deliver. So managers will neg these people or string them along without a real promo in sight.

Compare this to if they’re hiring for a position at a higher level: it’s hard to find technologists in the first place, and that disparity grows as you go up in level. So if the company can get just one candidate in the door for a high-experience technical contributor position, their incentive is to find that person capable of the high position because they might not get another candidate.

How does this play out? The anecdotes might surprise you. Jess Frazelle (yes, the one who wrote an enormous chunk of Docker) has never been promoted. If you check out the replies to that tweet, you’ll see that a lot of technical contributors, both women and men, some with 20 years experience, have received shockingly few promotions. So what does it take? In my experience, it takes convincing a manager or director with more power than you to compile a case for you like they’re your personal attorney. Sunah Suh had this same experience:

Here’s what it means: persuading, cajoling, and convincing managers has more of an impact on your career advancement than your technical contributions do, because if you just kick ass at your job, they are either not informed or not motivated to go to bat for you. But spending the time to persuade, cajole, and convince managers means spending time that you might otherwise spend kicking ass at your job, or leveling up so you can kick more ass at your job. So if that’s the case, who cares if you need a little help sometimes? Get the help, let people think you’re a hack, increase your actual skill level, and let it help you land that position at the next level up at another company when you’re ready.


It’s a common adage: “there are no dumb questions.” But that’s not precisely true. There’s no such thing as a question you shouldn’t entertain. There is such a thing as a question that you shouldn’t ask a person. You can google your question to figure out if the answer is easy to find by spending your own time. If that doesn’t work, you’re ready to find someone to ask.

When should you ask a question? Here’s my recommendation: lean in the direction of asking the question, even if you’re not sure how people will respond to it.

I say this for a few reasons:

  1. People often respond better than you think they will, so give them the opportunity to impress you.
  2. If people don’t respond well, that’s their problem, and they’ll suffer the consequences.
  3. The consequences of you asking a ridiculous question are not as high as you think they are.

Asking for help offers you an opportunity to identify folks whose knowledge you’d like to get and then take ownership of that transfer. In the next post of the series, we’ll talk about how to identify those people and how to ask them for help.

If you liked this post, you might also like:

The rest of the leveling up series (Fun fact: we are now in the second encore of this series. You people really want to level up. Go you!!!)

Code Mechanic: Numpy Vectorization (If exploring code sounds like a leveling up tactic that would work for you, here’s an example)

Behind the Scenes series (if your skills are already good or great and you want to accelerate your career, this might help)

One comment

  1. The most challenging thing for me is getting over the embarrassment of not knowing. It’s irrational, I know. There is a vast body of things I don’t know and that’s the normal human condition! As with most things we struggle with, there’s a feelings component involved and we just have to feel the feelings and act anyway.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.