A guide for junior devs: How to ask for help in 5 steps

Pairing session with junior dev Vickie (center), Brett (right) and myself (left)

Ten Forward is a teaching tech shop, which means we have a steady flow of junior programmers, apprentices and interns, and our more senior employees are often in high demand. 

To make it easier for juniors to get the help they need, Brett and I came up with a list of the steps juniors should take before reaching out directly for assistance.

(Note: Skip ALL of these steps if you've just broken production 😂)

Compiling these was a good reminder for us, as well, and while targeted at programmers, many apply to non-coding roles, too.

1. Check the Readme / Confluence / Bookstack / Wiki / etc.

We very well might have already internally documented the issue you're having or question you're asking; if we haven't, consider adding documentation yourself after you come to a solution or answer! If you're struggling with something, chances are someone else also will in the future, or possibly has already in the past.

2. Google it

It might sound simple, but when you’re frustrated, it’s easy to focus on the problem, and not the solution. Even programmers with decades of experience are constantly googling when they hit snags; with rare exceptions, this should always be your first step if you can't find internal documentation.

It might be tempting to just go straight to asking for the answer - after all, it’d probably be faster than figuring it out yourself - but then you’re not really learning, and learning should be your primary focus.

3. Phone a friend

If Googling doesn’t yield a working solution, then it’s time to reach out to someone else, whether via Slack or in-person. 

(If you haven't done so yet at this point in the process, we highly recommend the rubber ducky approach as a preliminary step ... you'd be amazed how often just saying something out loud gives you a different perspective, even if you're only saying it to yourself.)

As for when is a good time to stop searching and start conversing, every case is different; one solution is to decide beforehand how long you think is reasonable to work on the problem and set a timer. If you’re still stuck and haven’t made any progress (or haven’t made enough progress) when the timer runs out, that’s usually a good time to press pause.

When talking to someone else about your problem, use the following guide:

• First, clearly explain what you’re attempting to do; it’s almost impossible to over-explain. 
• Second, succinctly outline what you’ve already tried (and what resulted from those attempts).
• Third, list any possible additional solutions you’ve thought of or read of, but either don’t know how to try or have concerns about trying.

4. Detail how the other person can assist you

Finally, present your “ask” - that is, what, exactly, that you would like from the other person.

Do you want to pair on the problem? Just be pointed in the right direction? 

Be sure to include any timeframe requirements: is the client expecting a solution by end of day or end of week? Is this a high-priority bug on production, or is it something that can wait until the other person has free time?

5. Finally, remember that everyone else has their own problems they're trying to solve, and might not be able to respond right away.

And that's where your timeframe data in the previous step is important. If you have a week to figure out the solution, and other things you can work on in the meantime, the person you're asking for help might respond that they can't take a look for a few days. 

If that's the case, that's fine! To make sure it doesn't get lost in the ether, make a calendar event, invite the other dev, and then move onto something else. #teamwork