For any new programmers who are starting off at their junior developer position or internship, I have some advice: The 20 Minute Rule (when to ask for help).

When I first started my web development internship at scientist.com, it was a bit overwhelming. Jumping into a massive codebase and making sure you don’t set anything on fire or bring down the company’s online platform had literally given me nightmares. Once I got over that hump, I ran into a new issue I hadn’t faced before.

I would spend a whole morning trying to fix a small bug, and would be hesitant to reach out for help. Was it pride? Was it because I wanted to get unstuck to learn from my mistakes? Or was it because I was hesitant to bother the software engineers on the team? The answer for me was all of the above.

During my coding bootcamp at LEARN Academy, all of our daily coding challenges would consist of pair programming. Each day or week you would work with someone else in the cohort. I really value the concept of pair programming. Not only is it great for catching mistakes and being able to bounce off each other’s ideas, but it gives you the chance to learn from others and how someone else may break down a problem. Prior to the bootcamp, I had very little coding experience (basic html, css & javascript).

Some days I would be paired up with a classmate who had prior experience in programming. They would start breaking down the problem and have a solution while I was still scattering through my notes trying to figure out where to even start. Not only was it frustrating, but I felt like my programming skills would’ve improved a lot faster if I was able to break down a problem at my own pace. And of course I was worried about slowing down my partner and having them explain their solution repeatedly until my lightbulb came on.

While some of the experienced pair programmers were patient enough and slowed the pace, others were not. Out of the 20 people in my class, there were about 3-4 others at my programming proficiency. I wanted to get most value out of the bootcamp, and it wasn’t until the middle of the program that I made it a priority to pair up with peers who could benefit from going at a slower pace.

This is mainly why I thought it was okay to get stuck in a whirlwind of a problem at my internship. It was a way to make up for the days in my bootcamp that I wasn’t challenged enough and was given the solution without really understanding the process behind it. You should 100% try to figure something out on your own before asking for help, but don’t get stuck down the rabbit hole for half a day.

The software engineer I reported to noticed my frustrations and I explained to him the reasons why I hadn’t asked him for help. He then told me about the “20 minute rule”, which means if you can’t solve a problem in 20 minutes, ask for help”. He would rather have me bother him instead of letting me spend all morning fixing a bug he may be able to easily fix within a minute or at least provide me with a hint on how to solve it. He stated a really valid point.

I’ve come to learn that software development is all about efficiency and continuous delivery. You must be able to ship code to production on a daily basis. Being stuck on a problem for half the day is not only going to interfere with your workflow, but it will also negatively affect your team and the overall value you bring.

If you’re stuck for more than 20 minutes and you are going to ask for help, I would highly suggest to jot down some notes beforehand to clearly state what the problem is and the solutions you’ve tried. Although you may be “bothering” someone for help, at the minimum you’re making it easier and quicker for them to help you.

I’m so thankful to have been given this advice, and I hope I can forward this message onto any other entry-level developers in the same boat!Would love to hear your thoughts and comments on this subject. Feel free to connect with me at kristasimmons.design@gmail.com