Reading Time: 10 minutes

*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. Today, let’s talk about some options when you 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 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.

Though I did (and do) a lot of solo learning, solo learning has a weakness: you can’t customize what the source says.

Many of our leveling-up skills focus on getting around this. We talk about active reading as a way to triangulate from several sources. We talk about commit tracing to directly investigate the libraries we use. What if these techniques still don’t unearth answers to all our questions?

In these situations, I have had luck with seeking out an expert.

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

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 ask. There is such a thing as a question that you shouldn’t ask a person. You can avoid asking them by doing your research.

I do a lot of advocacy work. I often get questions that take a lot of time and care to answer. Many of these questions have excellent answers in the top google result.

Before you ask someone your question, check your other available resources. Don’t waste hours of someone else’s time if you haven’t devoted ten seconds of yours. 

So you googled and you did not see an answer, but you still worry that asking this question will make you look uninformed. What if someone says “oh my god, how do you not know this?” You’ll be a laughing stock!

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 not necessarily precisely true, but thinking of it as true has 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: “People will think I don’t know my stuff, and that will get back to my boss, and then I’ll get fired, or maybe I won’t get promoted.”

So, on firing: it’s actually sorta hard to fire someone.

Companies don’t want to 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 that it’s easier to wage a costly, annoying war of attrition so the person quits. Companies fire people, but 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 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 and not asking any questions for fear of revealing further underperformance. That behavior, combined with the fact that the company lacked clear documentation for the person to get the answers they needed without asking someone, resulted in no further progress.

If an underperforming employee continues to ask questions and show a modicum of progress, management would rather keep them than subject themselves to an uncomfortable termination conversation.

Disclaimer: firing policies vary by company. Companies also apply their policies 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. 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 switch companies. There’s a reason for this: when someone is already delivering superior output, there’s no benefit to the company to pay them more for 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 the company is 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 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 attorney. Sunah Suh had this same experience:

I would not have been promoted last year if I didn't have three levels of management looking out for my advancement (and fwiw this last one was my only regular in-job promo ever.) Find yourself management like this and never let go 😁 https://t.co/gf6kLjFPYG

— Sunah Suh (@sunahsuh) January 6, 2019

Here’s what it means: persuading, cajoling, and convincing managers has more of an impact on your 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 promotion at another company when you’re ready. Your next employer isn’t (usually) going to call your current boss and ask their opinion of your skills.

Conclusion

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 ask. 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)