Why Not Ask for Help?

This is a response to a Hacker News thread I started about becoming a decent developer. A lively debate broke out in the discussion. My most controversial point was “Don’t ask for Help.” The following comment sums up the objections:

I gotta say, this sounds like a perfect recipe for becoming the narcissistic, self-centered developer. The modern equivalent of the ladder-climber. To me, the perfect example is the “never ask for help” advice.

I hope I’m not narcissistic, or self-centered, but I stand by my advice.

I wasn’t always a decent software developer. Actually I sucked. Like anyone, I was full of bad habits when I started.

I worked a few jobs before joining Google. At each, I’d run for help when I’d been stuck on any problem for more than 5 minutes.

I probably adopted this habit during college. The Teacher’s Assistants were always there to help with coursework. My behavior didn’t change after I joined Google as a junior software developer.

My mentor at the time was a brilliant PhD. One of the best code reviewers I’ve ever had. He also had answers for everything, and I’d make the trek over to his desk 5-10 times a day. Even with my bad habit, I still worked hard. Every night I’d stay late trying to master Google’s systems.

After a year of this, I figured they should promote me. I worked long hours after all. So why not? Don’t we all feel like we should be promoted? I put together my promotion packet and sent it off to the committee (at Google, you nominate yourself).

I knew I hadn’t been at the company for that long, but I was positive I had a decent shot. I worked harder than anyone I knew.

After what seemed like an eternity, I got the result. I opened the email and…. OUCH! No promotion. I was crushed. I hadn’t thought I’d cared. But now that I couldn’t have it, I was devastated. And pissed off. So what happened? I looked through my peer feedback. It had all been positive, except one guy’s. The one who sat next to the desk of my mentor. His was a one-liner.

Spend more time trying to figure things out for yourself before asking for help.

WTF!? I was furious. Who was this dude!? It made more sense to ask for help instead of spinning my wheels. How dare he disagree with me? Did he want me to sit there all day?

Although it was only one guy, that feedback changed my behavior. I became extremely self conscious of asking people for help. That guy wasn’t going to put nasty comments on my peer reviews ever again. It wasn’t until later that I realized it had been one of the best pieces of advice I’ve ever received.

A few months after my failed promotion, I switched teams and got a fresh start. And for the remainder of my time at Google, my performance improved drastically. I doubled my salary in a short period of time, and I lead a sub-team for Google+. Each of my bosses gave me excellent feedback, and I wound up getting the promotion. A couple of years later, I left Google on excellent terms to found my own startup.

My eventual success was caused by many things – luck being one of them. But I also became known as a person who could figure anything out. Give me the description of a problem, nothing more, and I’d come back a few days later with a working solution. I developed a self reliance that I hadn’t known when I first joined Google. And it was all because of one seemingly negative piece of feedback.

The Types of Help

My experiences aside, I’m not advocating you NEVER ask for help. There are some situations where it makes sense. So let’s break it down. Assistance comes in several forms:

Design or Product Discussions ✓ Debugging ✗ Development Tool problems. Ever borked git? ✗ The nuts and bolts of implementation. ✗ How do you implement rounded corners in each browser in CSS? How do you do something in Java, Python, C++, whatever? How do you make MongoDB index your data?

If you have a Category 1 question, it’s essential you talk it over with your team.

You have to include other people in major product decisions. If you’re talking about software architecture, other engineers are likely to point out flaws in your design. Or they’ll make it faster. Or they’ll see a class structure that makes things simpler. These improvements are a great use of your time.

But all the others, you should figure out for yourself. You’ll become a much stronger developer. If you’re debugging, then you need to learn how to find your own bugs. If you screw up git, then you’ll be more productive when you determine how to fix it quickly. And you’re always better off if you fully understand your technology stack.

Of course there are exceptions to each of these. For example, imagine you’re debugging a problem that appears to come from code a co-worker changed in the last week. By all means, ask him or her if the issue is related. But if in doubt, don’t ask. Sit there and figure it out.

What about Teamwork?

Now let’s talk about the prickly issue of teamwork.

How can you still be a “team-player” if you refuse to ask other people for help? Since Google, I’ve worked with many software developers In many cases, I’ve been the more senior member of the team. I love helping folks, and I love explaining things.

I take pleasure in helping someone understand the intricacies of git, or how a deployment system works. I believe in making others better.

But just giving someone the answer doesn’t usually make her better. It’s a short term fix. A band-aid. And it allows her to fall into learned helplessness where she thinks he needs help with everything.

If you’re a good teacher, you’ll get her part of the way there, and let her figure out the rest for herself. But how many of us are good teachers?

I’ve seen super intelligent people, way brighter than me, fall into the pattern of learned helplessness. Nothing is wrong with them. They just develop bad habits.

The Cost of Asking

Asking for help becomes a problem when you regularly consume the time of 1-2 other engineers with issues that you could easily figure out yourself.

This was me at the beginning of my Google tenure, and I’ve since worked with many people who do the same thing. Involving other people in your problem increases the cost of solving it drastically.

You’re barging into their attention, ejecting them from the zone. You stand there talking for 10 minutes, and then it costs that person another 20 minutes getting working again.

In our industry, you have to focus intently on what you’re doing, so these interruptions add up quickly. It’s probably cheaper for the organization if you sit at your desk spinning your wheels, even if it takes much longer.

The Benefits of Resilience

The most important benefit you’ll receive when you stop asking for help is the resilience you gain as a software developer.

We usually associate resilience with entrepreneurs. The one who failed 5 times but got up 6. Navy Seals. Iron man athletes. Not software engineers.

But developers can benefit immensely from the trait. If you’re a hacker, you depend on it. You’re doing things that have never been done before. Most people think those things can’t be done! And you have to prove them wrong.

During my 2.5 year entrepreneurial stint, I had countless situations where nobody could help me. Our first product iteration was a digital billboard running on the Barnes & Noble Nook (now a defunct product).

We turned the Nook into a display that we put in restaurants and coffee shops. I was the technical lead. And not only did we solve all sorts of weird Nook firmware issues, we also found long-standing issues in that version of Android.

Those issues would never be resolved because the Android team had long since moved on. But we had to work around them. No instruction manual existed to tell us what to do. No firmware documentation. Technically, we weren’t supposed to be doing what we were doing.

Despite these challenges, we created a working product, and our devices were in 30 restaurants before it became clear that the business model wasn’t going to work.

Then we pivoted to an HTML5 email product, and the process began again. Now we were dealing with brand new browser APIs that nobody was using. Memory leaks. Performance problems. Browser crashes. As the tech lead, I was responsible for all of this. Nobody could help.

I had worked for Google sure, but I didn’t know anybody on the Chrome or Android teams. I was stuck in the public forums along with everyone else. Plus we were doing weirder things than everyone else, so others were unlikely to run into the same problems.

If I hadn’t built up resilience years before, there’s no way I would have been able to ship either of those products. I would have given up and walked away and declared what we were doing “impossible.”

Seriously, who turns a Nook into a billboard? We were crazy. But we didn’t walk away. We solved all of our own problems, and we wound up with working products.

In summary, not asking for help is one way to build this resilience. It’s one small step. When I began in computer science, I never would have dreamed of solving the sorts of intricate problems that I ran into later. But I did! I didn’t get any smarter. I just became more willing to sit for long periods of time until I figured the problem out. So please, please, please, consider the advice that my coworker gave to me.

Spend more time trying to figure things out for yourself before asking for help.

You might be running a company someday and find the product depends on your ability to do so.

Ever had success or failure following this technique? Tell me about it below.

Photo Credit: Daniel McCullum