How To Ask For Help As A Junior Developer [The Right Way]

We only partner with brands that we know and trust. If you use our links to buy a product we may make a small commission at no extra cost to you. Thank you for supporting HHT!

Being a junior developer is like being a college freshman all over again.

You have so many new things to learn, stress levels are high, and the fear of looking dumb in front of older, more experienced people is real.

Eventually, though, you're going to have to go to your colleagues for help, but unlike in college, the rules are a bit different.

While people expect junior developers not to know much from the start, it's important to show initiative. Having a system to categorize, understand, and dive deeper into a problem (before asking for help) is a key skill for new devs and can earn you the respect of your superiors.

I've asked a lot of questions to my former tech leads, both successfully and not-so-successfully.

With those experiences in mind, I came up with a framework that can help new developers ask for help more confidently.

What To Do Before Asking For Help

Not knowing what you don't know opens up the fear that you might ask a question that has an easy answer.

Every manager says that there are no dumb questions, and as a junior, this is partially true.

There may not be dumb questions, but there are avoidable questions. Questions that, if you knew where to look and how to start, you might be able to solve on your own (even if it isn't immediately apparent how).

Since starting my software engineering journey, I've found the most success by following simple, repeatable steps to diagnose these kinds of issues. Here's an outline of what I've learned:

  • Save

There's a lot going on in the diagram, so let's look at each step in more detail.

1) Start With The Basics

The basics. Old reliable. Tried-and-true hacks that are often all you need to fix a technical issue.

Before we get into my top tips, quick story time first.

In my second week as a fresh junior dev, I came to my tech lead with an issue that I couldn't figure out how to fix after hours of finagling. I was convinced it was some advanced configuration error or something inherently wrong with the code base. Maybe he'd given me a ticket that was over my head?

After he recommended a restart (which fixed the problem, coincidentally), I realized how important it is to cover your bases.

It's easy to forget, but as a developer you're working with imperfect systems. Computers, IDEs, VPNs, and all the various technologies we use to create software are not fault-proof.

Besides restarting your application (or computer) here are some basic action items to run through when debugging an issue:

  • Are your repos up to date? – if you're running out-of-date code, it's possible the fix you're looking for has already been issued
  • Are there any system-wide updates waiting on your work machine? – believe it or not, sometimes a system OS update can help things run smoothly
  • Is your application (and all of its contingencies) actually running? – modern applications often require many dependencies (which can be tricky to keep track of) that all need to be running simultaneously

Once you can safely say you've gone through each item on the list above, the next step is to categorize what kind of problem you're dealing with.

2) Categorize Your Problem

In my experience, there are really only two categories of bugs you can run into: programming-based bugs or those that rely on specific domain knowledge.

Let's break this down a bit further, starting with programming-based bugs.

These are issues where the fix is based completely on an understanding of how the code works, what syntax to use, how to handle edge cases, et cetera.

If you don't need to know what the code or file does in the grand scheme of your system's architecture, it's an isolated programming issue.

Contrast this with a domain-specific issue, where you do need to know how your codebase works – i.e. the details of its configuration (databases, VPNs, version control), which files interact with which, and so on.

Quick example: let's say I'm working at Netflix, but I don't know how classes that handle the video player interact with those that handle audio streams. It's going to be pretty tough to diagnose an issue where those two concerns overlap, right?

This issue technically has nothing to do with the actual contents of those classes, but rather the relationship between them that's already been defined by previous developers.

Pro Tip
This kind of domain knowledge takes weeks if not months to accumulate – don't feel bad if you have a seemingly simple question in this category. The answers are not always obvious.

Being able to categorize your issues as domain-specific or programming-based is a keys step in this whole process because it will inform your next step: doing your due diligence.

3) Do Your Due Diligence

Asking your tech lead for help without having anything to show for yourself is a big no-no.

Compare these two example messages a junior developer might send their tech lead:

Hi Mr. Tech Lead, I'm pretty stuck on the ticket you assigned me yesterday, could you help me out?


Hi Mr. Tech Lead, I've been working on the ticket you assigned me yesterday, and while I think I understand [insert key finding or observation], I could use a bit of direction. Could we chat sometime about what I found?

The second message is miles better than the first because it's clear the junior developer did some work beforehand. Right off the bat, the tech lead can see they've spent time trying to fix the bug (and has hopefully tried a few different ways of doing so).

More importantly, when shown proof of effort, a tech lead is more likely to think that their junior dev isn't wasting their time with avoidable, simple issues and they'll be more receptive to help.

Doing your due diligence is a win-win for both parties, and if there's only one thing you take away from this article, it's exactly that: always have something to show for yourself before asking for help.

Remember how I also said it was important to categorize your problem before jumping in to this step?

This is why!

If you know your problem is programming-related, check the developer docs or online tutorials sites. If it's a domain issue, then it's better to refer to your company's wikis or comments / documentation from previous developers.

Approaching Your Colleagues

If you've gone through all the steps from above, checked the docs or company wikis for answers, and still run into issues, then it's a good time to ask for help.

In general, I'd recommend following these steps to have the most success when reaching out to your superiors:

  • Avoid chatting colleagues that are offline or in meetings – if they're already busy (or unavailable), chances are they won't be able to help you in that moment anyways
  • Prepare your message (and the work you want to show) in advance – on the off chance that a colleagues is immediately available to help you, have your ideas prepared and be ready to present your problem
  • Stay productive while you wait – read online tutorials, peruse the company docs, anything that keeps you busy is a good way to use your time

The common denominator here is to show initiative.

Having your materials and source code prepared before a colleague helps you will make your discussion with them quicker and easier.

Your being prepared saves them time which makes them way more likely to help you again in the future.

Every company and dev team is different – by and large, though, people will notice and appreciate young developers who respect other peoples' time and schedules and who make a conscious effort to learn.

The Bottom Line

Starting a developer job is like going back to school for a little while – you're constantly stressed, your mind is spinning in overdrive, and inevitably, you're going to get stuck with a problem you can't seem to fix.

The stakes are a bit different than college, though. People are paying you to deliver work product. Time is of the essence.

Plus, you're new – you definitely don't want to look stupid in front of your smarter, older, and far more experienced colleagues.

So, what's a young developer to do?

The most important first step is to recognize that it's perfectly natural to get stuck when you're new. The second step is to develop the habit of systematically categorizing, understanding, and researching any problem before asking for help.

Coming to your colleagues for help is a fact of life – but if you can show a more-than-surface-level understanding of the issue at hand and be able to present some initial discoveries (that prove you've done some work), people are much more likely to help out.

Have you learned any other tips about asking colleagues for help in software? I'd love to know your thoughts, so be sure to let me know in the comments below! 🙂

Question mark on memo paper on pink background. Solution concept
  • Save

Leave a Reply

Share via
Copy link