Is it Bad for Junior Devs to ask for help too often? 4 Signs for when Junior Developers should Ask for Help.

Do you ever struggle with whether you are getting help too often as a junior dev?

Maybe it's been a few months, but your questions still seem silly?

How do you know if you should spend more time trying to figure things out on your own before messaging one of the more senior devs?

I covered how to effectively ask for help ask a junior developer in my last post, today I will cover a related topic of when and how frequently you should ask for assistance as a junior developer.

By the end of the post, you'll have a 4 step checklist to help you determine whether now is the right time to get help, follow these signs and the senior devs on your team will be more than happy to help you every time.

Before we get to the question of 'when to get help from a senior dev', we first need to answer the question 'should I be consistently asking for help?'. And the answer is an emphatic 'yes!'. As a senior developer, it is both my pleasure and my job responsibility to help more junior developers grow professionally, and answering questions and the extended discussions they lead to is one of the best ways to do that. Not to mention it feels at least a little gratifying to 'flex my knowledge' a bit :).

That being said, it is not a great feeling to be asked the same simple and easily searchable questions multiple times a day or day after day. So after some thinking, here's are the 4 sure signs that will tell you whether it is the right time to call for an airdrop of dev support.

Sign 1: You can clearly describe the problem

Let say you are a junior front-end developer who wants to create a Javascript-based front-end sliding animation. After some Google-fuing you found out you can use a setInterval function to move the sliding element every 100 milliseconds, but the resulting animation just looks wrong. One way to ask for help would be messaging someone else on your team and ask:

Can you help me with my animation? It looks wrong.

This question is hard to answer, it gives the other person nothing to go on and honestly can set off some anxiety since they have no idea if this is a small 5-minute lift (syntax error) or a 2-hour trip down in CSS layout performance land. The lack of context on what kind of animation it is can also cause problems, troubleshooting a 2D slide animation is something I feel pretty confident about, whereas a Three.js based transformation is something I would be much less confident about.  

Here's a better question that would put me at ease and bump the question top on my list tasks because I can estimate the lift:

Can you help me with the new top navigation animation I created with setInterval that looks quite choppy?

Sign 2: You took a good stab at solving the problem

A problem you can articulate is a problem you can search and learn more about. Make an honest attempt at solving the problem, even if it feels like spinning your wheels. It's hard to provide an exact amount of time but personally, I think the lower bound is 30 minutes to an hour of tackling the problem on your own.

One thing about tackling the problem on your own instead of asking for help right away is it shows that you respect other developers' time. Everyone's time is valuable and going around interrupting others every time you run into a speed bump can be perceived as annoying, or even worse, lazy. On the other hand, you don't want to spend too much time going down the rabbit hole either, I'd say something around 3 hours to a day is the top end limit if you aren't making progress. Whether it should be 3 hours or a day depends on issue complexity.

But tackling the problem on your own isn't just for the other developers, it also helps strengthen your own problem solving and research skills. It is especially helpful to develop the mindset of thinking deeply about a problem and the ability to tackle a problem from different angles.

In the case of our choppy navigation menu, perhaps you tried to change the interval and the sliding amount, and after you researched some more about animation and setInterval you learned that requestAnimationFrame provides smoother animation, but it is still janky.

Now your request looks more like this:

Can you help me with the new top navigation animation I created with setInterval that looks quite choppy? I tried changing the interval amount and using requestAnimationFrame, but it is still not smooth.

Sign 3: You learned something

The 3rd sign that you should ask for help on a problem isn't so much about the other developer as it is about you. As a developer, we learn new things daily and one of the best habits to develop is to see every problem as a learning opportunity. To that end, take note of what you've learned while you tackled the problem on your own.

Perhaps in your research in 'choppy sliding animation', you learned that the industry term for it is 'janky', maybe you even came across http://jankfree.org/ in your research. Learning to learn and keep up with all the technological evolution is a huge part of being a developer, so it's good to get a good handle on the practice.

You may mention it during your question, although it's mostly optional:

Can you help me with the new top navigation animation I created with setInterval that's janky? I tried changing the interval amount and using requestAnimationFrame, but it is still not smooth. I assume it's from some kind of layout thrashing, although I can't say for sure.  

Sign 4: Pick the right context

The right context is everything in programming, as it is in life. Nothing kills a developer's productivity like having to context switch in the middle of a deep dive. If you fulfilled the 3 steps above, but followed up with physically moving over to another developer's desk and tapping them on the shoulder to ask for help, you'll still be seen in a less than positive light.

Here are some good times to ask for assistance:

• At the beginning of a meeting while waiting for everyone to assemble.
• Right after a meeting when there' no urgent tasks to attend to.
• When in the office, when you see the other developer at the water cooler.
• When working online, when you see the other developer posting a funny 'gif' or chatting in a 'common interest' channel.
• At the beginning/end of the workday.

And if none of the above opportunities arises naturally, it is always good to also send them a non-urgent message/email with your problem description and ask that they reach out to you when they have the mental bandwidth.

Here's our final message:

Hi XXX, when you got a free moment, can you help me with the new top navigation animation I created with setInterval that's janky? I tried changing the interval amount and using requestAnimationFrame, but it is still not smooth. I assume it's from some kind of layout thrashing, although I can't say for sure. No rush, I'm working on the footer positioning fix in the meantime.

And there you have it, we went from a short, nondescript, and potentially anxiety-inducing message for help to one that shows respect for another developer's time and efforts. We took the time to demonstrate that proper research and efforts have already been put into resolving the issue, and we've learned something along the way. Your senior devs will love to receive the final message and will think more highly of you with every single one, even if you went down the wrong path and using CSS animation is ultimately what you settle on.

So next time you need to reach out to another developer, remember to be on the lookout for the 4 sure signs. And you make sure your questions provide the most learning possible, check out my articles on using the PADD method to effectively ask for help.

Happy coding!