Asking for Help

There will be times when you’ll hit a dead end with your code. Either you’re getting an error or your code just isn’t doing what you think it should be doing. It’s tempting to drop everything and ask a coworker for help, but you shouldn’t ask them without being prepared.

Knowing what to ask is often the hardest part. You’re struggling to get the code to work because you don’t have a good grasp on the problem you’re trying to solve, but where do you even begin asking for help?

A simple thing to remember is that you should be asking for advice, not a solution. Don’t expect your coworker to fix your bug or code your feature for you. While most people will be happy to help you arrive at a solution, no one wants to do your work for you.

When you ask someone for help, you’re asking someone else to take time away from their own projects to help with yours. Switching context back and forth is hard when working on something that requires deep focus, and you need to respect your coworker’s time if you want to build trust with your team. Try not to waste their time with a question that you can easily find by querying a search engine.

So how can you do that?

• Come prepared with a clear explanation of the problem you’re trying to solve. If you can’t explain the problem clearly, you’re not ready to ask for help yet.

• Give examples for how to recreate the problem if you’re able to.

• Show them what solutions you’ve already tried so they can eliminate potential options.

• And remember: ask for advice, not a solution.

The more effort you put into asking the question, the less time your coworker will need to get up to speed with the problem. You’ll help your coworker understand the problem quicker, which means they’ll be able to help you quicker.

What to Ask

Don’t be discouraged if you’re having trouble explaining what the problem is that you’re trying to solve. Oftentimes, it’s a complicated explanation involving lots of context before you can even get to the problem itself. It may be hard to find the right words to explain what the problem is, so it’s important to take the time to understand the problem completely before asking for help.

If you don’t understand the problem well enough to explain to someone else, take some time to review everything again. Reread the description of the task to make sure you’re understanding it correctly. In some cases, it helps to write the problem down on paper first or type it out in your notes. Getting the thoughts out of your head will help you organize them, and sometimes, the solution will come to you during this time.

Consider the following:

The second example conveys more information to the person helping you, and it gives them enough context to know what you’re trying to do and where you need their help. Try to be specific in the details of your question, and the more context you can provide, the better.

Narrow Down the Problem

It sounds silly, but if you’re getting an error, make sure to read the error message. I mean really read it. Read it multiple times to make sure you’re fully understanding what the compiler or interpreter is telling you. Sometimes the answer is staring right at you from the error message, but you may not even realize it because you’re skimming over it.

If you have a stack trace, follow the code path line by line. The compiler is giving you hints at what the issue is and where you can find it, so follow the trail. Pull up each file and go to the line listed in the stack trace. Do this for the last few functions that executed before you hit the error.

If there isn’t a stack trace available, try modifying the code in your local environment to add some logging. Add log statements to print out the information you need to figure out what’s happening.

Better yet, use a debugger if you have one set up. Being able to step through the code and see the values change feels like superpower when tracking down bugs. Not only that, but you’ll be able to see how your logic works in real time, with real inputs. You’ll come away with a better understanding of what the code is doing and how that part of the system works.

Reproduce the Issue

Next, make sure you can reproduce the issue before asking anyone for help. If you can’t reproduce the issue, then you’ll just be wasting other people’s time by asking for their help. You’ll want to be able to show whoever is helping you how to reproduce the issue to give them context on what you’re trying to solve. After all, if you’re not able to get your application in the right state to trigger the error, how will you even know that you fixed it?

​important​ There are exceptions to this rule, however. For example, if you’ve spent three days trying to reproduce an issue and you’re still not able to, it might be good to ask for some help. Use your best judgment and only ask for help if you’ve put in significant effort to reproduce the issue and you’re still not making any progress.

Try different inputs, both good and bad. Does the error only show up with specific input types, or does your program throw an error regardless of the kind of input. Check the same thing but with different application configurations as well. For example, does the export functionality break for all file types or just a subset of available file types your application provides?

Give Context

Give some background context about the problem to the person helping you out. Don’t assume they know what problem you’re trying to solve, and don’t assume they’re familiar with the part of the codebase you’re asking them about. If possible, try to give them some context around the problem to help get them up to speed. Show them what solutions you’ve already tried, and explain to them where you’re getting stuck. Are there solutions you’ve been able to eliminate? Give a quick explanation about how you were able to determine that certain solutions won’t work, and why.

The more information, the better, so try to be as specific as possible. Does your data need to be in a certain state in order to reproduce the bug? Let your coworker know. Are you able to reproduce the bug with all third-party integrations, or just a specific one? Let them know. Give as much context as you can, because that will help them narrow down the problem and eliminate potential scenarios.

Do Your Research

There’s a misconception among young developers that experienced programmers know so much that they rarely need to Google anything, when in reality, it’s just the opposite. All programmers use search engines and Stack Overflow to help answer their questions, even the senior and staff engineers.

Humans can only retain so much information before we begin to forget things. Our brains can hold vast amounts of knowledge, but there’s still a limit to how much information we can retain.

Chances are you’re not the first person to encounter an error message or run into an issue with your implementation. There’s a good chance that there are plenty of people who have posted similar questions to online communities or written blog posts on the same issues you’re running into.

Try searching Stack Overflow, reading blogs, or reading GitHub issues and pull requests. Those are the best places to start. Be descriptive in your search queries, but try to remove any specific file or variable names that are unique to your code. You may need to try a few different search queries before you find what you’re looking for, but if you’re able to explain the problem correctly with your query, you shouldn’t have any trouble finding someone else who also ran into that same issue.

​caution​ If you can find a solution to your problem by searching the internet, that’s great. That means you didn’t have to ask any of your teammates for help! But be careful though. While it’s tempting to copy and paste solutions you found on the internet, there are many examples online that may not be the most efficient code or the most secure, and the last thing you want to do is compromise the security of your codebase using a solution you found on the internet. If you’re unsure of something, ask a teammate to help you evaluate the quality of a solution first.

Search Internal Documentation

It’s easy to forget that your team’s internal knowledge base is a good place to look for answers. Engineers often document how a part of the system works, including any known issues, limitations, or other considerations and trade-offs they made when designing a feature.

If you’re running into issues setting up your environment, getting your build to compile, or running your test suite, the solution to your problem may be documented in the internal knowledge base. It doesn’t hurt to take a quick look there first.

While you may find an answer in the internal documentation, that page may be out-of-date by the time you find it. If you find an answer, try to find the original author and ask them to verify that it’s still up-to-date. If the original author is no longer on your team, ask a teammate who you think would be familiar with that part of the system.

There’s a lot to consider when asking for help, but in some cases, you can avoid it altogether if you’re able to leverage the tools around you.

Sometimes, you’ll run into scenarios where you’ll need to ask questions to gather more information before you can proceed. In these situations, you’ll need to ask questions to clarify something.