Beginner’s Guide to Asking for Help
X: I need help.
You: With what?
X: With something.
You: What thing?
X: A thing that’s giving me problems.
You: Okay.
X: Can you help me?
You: ¯\_(ツ)_/¯
How would you feel if you we were part of a similar conversation? Wouldn’t you get frustrated at the fact that you are not given sufficient information from the person who is asking you for help? I would. A conversation like this feels like pulling teeth. The person who is asked for help is also asked to do a lot of work in order to provide said help. So why do many beginner developers do the exact same thing?
I believe that a typical beginner programmer has no clue what kind of information they have at their disposal. When something goes wrong an avalanche of information is thrown at them and they are basically drowning in it and cannot parse out what is valuable and important from what is just noise. When you’re new to something, everything is foreign and you have no idea how to establish a hierarchy of importance when it comes to the data you’re given. A person learning how to be a developer is no different. The output of an error or program is a wave of information that hits the developer straight in the face. So to them, all they know is that something didn’t work and they need help figuring it out.
As a mentor, you want to help a beginner programmer learn and progress while helping them debug their code. To do that, you want to lead them towards an answer and not give it to them without explaining how you got there. A lot of the times this process takes place over chat (like on Slack), but the same thing applies in person as well. Here’s the equivalent of the above conversation but about code:
X: I’ve got an error I can’t figure out.
Me: Okay.
… *wait to see if X is typing up some more info*
… *5 minutes later*
Me: What’s the error?
X: undefined method
Me: What’s the undefined method?
X: undefined method '[]'
Me: Can you copy/paste for me the whole error and everything relevant to it? I can better assist you if I’m not flying blind and I need to see the whole output of the command line and the relevant piece of code.
X: sure thing, one sec…
*X typing…*
*is X typing the whole error from the command line letter by letter instead of copy/pasting?
*X pastes a bunch of stuff then deletes it*
*okay, maybe X is trying to format it in a legible way and is trying to figure out how this ``` thing works in Slack*
Quick interjection: There are a lot of tools out there that a beginner programmer needs to get familiar with, and although most people are used to chat apps, formatting code within those apps is not a familiar thing. So here’s a what otherwise would be a simple thing stomping them because they still have not yet mastered this part of communicating via chat, while trying to understand an error. And when you already feel like you’re drowning, a single additional drop could feel like an ocean. At this point, depending on how evil I feel, I either suggest we hop on a call and share screens or let them struggle hoping it’s a learning opportunity for them to get better at communicating via chat. I’m mostly evil and watch this thing unfold slowly, but also make sure to compensate this with times where I make it easier on the person because I want to strike a balance and not make the experience insufferable. Now back to the original plot…
*a few moments later…*
X:
undefined method `[]’ for nil:NilClass on
features/step_definitions/foo_steps.rb:28*wait a couple of minutes longer*
Me: You know Slack doesn’t charge us a tax on the number of works or messages we send right?
You don’t have to be stingy with the code you share with me. You can paste all of it here, Slack won’t charge us extra.
And I don’t read minds nor do I have a 🔮. So I need to see what you’re working on to be able to help you out.
X: haha
X:
fill_in(‘First Name’, with: @user[:first_name])ʕノ•ᴥ•ʔノ ︵ ┻━┻
*keep your cool, they’re new to this, they don’t yet get it*
Me: Okay, is there more code around the line you just sent? Does the file that you’re working on have more lines of code?
X: Yes
def new_user
@user = { first_name: ‘First’, last_name: ‘Last’ }
endGiven … do
fill_in(‘First Name’, with: @user[:first_name])
fill_in(‘Last Name’, with: @user[:last_name])
end...
Me: Finally. Now we’re talking.
You, the reader, may think I’m exaggerating, I am not. This 👏🏽 happens 👏🏽 all 👏🏽 of 👏🏽 the 👏🏽 time 👏🏽. This is not taken out of one example with one person. This is has happened with me on multiple occasions per person, with many people of different sizes and shapes, over a decade worth of work in the industry. I know there might be a couple of people reading this right now thinking I am specifically talking about them. One of you is guilty of being the latest person to do it and where the example above is inspired by, but you are not alone 😉.
Because this scenario has happened multiple times, I decided to write a blog post about it because I am sure this will happen to me again soon and probably to others out there. The next person I go through this with will likely get a link to this post instead of me spending half of the day going through the tedious motions (Hi! 👋🏽 Glad to be working with you, it’s going to be fun…). So here are a few tips to help you ask for help with your code from someone:
1. Chat is asynchronous:
The beauty of chat is that it’s asynchronous.
What not to do: Kill its killer feature by sending something like “Hey, can you help me with something?” or “Hey, I’m getting an error.”
What to do instead: Say what you came here to say. Whoever you’re talking to will get back to you once they’ve got a minute, so make sure in that minute they have something meaningful to say other than “Sure” or “In 5 minutes” or “What’s the error?” or even worse “I did a moment ago but not right now”. Set it up so that when they see your message they have everything they need to know.
2. Do the hard work yourself:
Don’t make the person you’re asking help from, do more work than you. They are taking time away from what they have to do to help you out. Respect that by doing the hard work upfront.
What not to do: Ask a question to someone that you can Google yourself.
What to do instead: Do some research before reaching out to someone else for help. Don’t spend an entire day (or even more than 30 minutes) researching something, but as long as your search keeps coming up with new answers keep looking. The moment you hit a block is when you should reach out.
3. Read:
That’s an odd one to include, right? Well, sometimes common sense approaches are the ones most valuable to repeat and highlight.
What not to do: Run a program (app, small script, tests, anything), see red in the terminal (or browser), immediately switch back to the code editor and change a bunch of stuff randomly, and try again. A few tries later you’ve deleted the code that was working, kept the broken code, and are in a messy situation.
What to do instead: Read the error that’s printed on the screen. Programmers have put in a lot of work to make languages and frameworks print out helpful messages with good instructions on how to fix common errors. Do them and yourself a favor and read the output of the error. Read EVERYTHING. Start by reading the full thing, then go back and re-read every chunk at a time and try to comprehend exactly what is being communicated to you. Many times the answer is in the error report but beginners don’t bother reading the whole thing, get to the first two or three words then assume they know what’s going on. It’s amazing how beginners assume they know what’s going on when they are the most likely people to have no clue what just happened. We, humans, are hilarious in our behavior!
4. Context matters:
Be generous with the information you share upfront that sets up the context for the other person. This is the culmination of everything above. You’ve read the error carefully, you’ve done some research about what could possibly be happening, you’ve hit a roadblock, and are about to reach out for help. What you do next is what will determine the outcome and the onus is on you to do it right.
What not to do: Send something like “I’ve got an error I can’t figure out.” on Slack. Before you hit enter on the first thing you send, make sure you have everything the other person needs to help you out. Treat the first message you send as the difference maker between whether you will get help or not.
What to do instead: Start by sharing the context, the full context. Which usually means including the following:
- Intentions: what are you trying to do? In layman’s terms explain what you want to achieve. The code you’ve written might not actually coincide with your intentions, so if the person helping you doesn’t know the “why”, they’ll miss the opportunity to give you directions towards achieving your actual goals and might send you down the wrong path.
- Your proposed solution: In a natural language (i.e. English), explain the solution you’re proposing to use to solve the problem at hand, or get to the intended goal, what you described in the intentions section.
- The code: Share the FULL snippet (or multiple snippets, as many as necessary) of code that is relevant to the problem at hand. This is the code that supposedly implements the proposed solution you’ve described. Be generous. Don’t share one line of code, or just the minimum. In fact, share everything that you think is relevant or touches on the part of the code that is causing you to request help. It’s okay to share more than you need, an experienced developer can easily ignore the extra stuff, but none of us have crystal balls and can read minds (contrary to popular belief), so no one would be able to guess code they are not aware exists. Make sure to use proper formatting when sharing, either by using the ``` code block if using Slack or uploading a snippet with the appropriate language setting so that syntax highlighting can make it easier for others to read what you’re sharing. If you’re sharing snippets from a class, indicate that by either copying the full class or at least the class definition (`class Foo … end`) and using
…for the omitted parts. If the code that you’re dealing with spans multiple files indicate that as well. - The output: If there’s an error that you want help with, share the full error message and the full stack trace, leaving nothing behind. If the output you’re dealing with is the output of a test run, share the full output and highlight any colors that the terminal might be showing you (so for example, a passing test that is in green, pending in yellow, failing in red need to be all specified) so that the person reading can tell what part needs attention. In situations like this sharing a screenshot of the output might be easier, but if you do that also share a text copy of it, the other person helping out might want to copy/paste a code block and screenshots mean that they’d have to manually type something up and that’s just a pain and added work you’re asking of them.
- Your interpretation of the output: If you are getting mentored by someone, the important part of the process is for you to learn how to help yourself out in the future when faced with similar situations. For that to work, you need to learn how the more experienced person, the mentor, is solving the problem. Which means that the important piece of the discussion is not the answer, but how to get to the answer. So share what you think is happening so that the mentor can assess whether you’re on the right track or not and if not explain to you what their interpretation is and help lead you towards the fix.
- Your research: Let your mentor know what you’ve tried so far to deal with the situation. It helps avoid going down paths you’ve already tried. It also helps identify an area where you might have been on the right track but missed the aha moment or the key part that would have solved the issue for you. Situations like these are nice because they let the mentor nudge you in the right direction but also show you that you were almost there and just needed one tiny piece to the puzzle and you would have gotten it yourself. So it can feel like a small victory and progress, which is a great thing.
In summary, when asking for help from someone else do not make them do the hard work for you, do the initial work yourself. Share the snippets of code, the output, and everything that can help identify what the issue is. Without this information, you’re asking the person doing you a favor to put in a lot of effort just so that they can tell you that you had a typo. Don’t do that, that’s not nice!
