As a manager, a common pattern I see with Junior engineers is that when they run into a problem they will try to solve it on their own. They may spend a whole day going down all sorts of rabbit holes trying to get around the problem.
Most of the time people don't ask for help because they don't want their teammates to feel that they are being bothered by them. Believe me when I say that it is their job to be bothered by you and it is your job to bother them with questions. Your more senior teammates are expected to help out and share their knowledge and it is your job as a junior engineer to learn from them.
However it can be difficult to balance the trade-off between persevering with a problem or asking for help with it. That is where the 30 minute rule comes in.
The 30 minute rule
My advice is that if you have run into a problem and have not been able to get around it after 30 minutes then you must Ask. For. Help.
30 minutes is long enough to have ruled out simple mistakes by checking what you have done. It's long enough to have Googled any error message and tried out one or two possible solutions you find online. It means that you will have done some basic due diligence to try and get around the problem yourself. The benefit of spending this time is that you will know you have a legitimate issue that you can't easily get around. You won't feel like you're annoying your colleagues with trivial problems.
It's also a good idea to not spend less than 30 minutes trying to solve your issue. If you just ask for help as soon as you run into a problem you can waste the time of your colleagues if the problem you have has a trivial solution that is one Google search away. Also by not persevering and trying to find the solution yourself, you are denying yourself the opportunity to practice debugging. Debugging is a skill in it's own right and every problem debugged is an opportunity to hone this skill.
So don't waste your whole day. Use the 30 minute rule and accelerate your learning.
Photo by Gary Bendig on Unsplash