If you ever worked as a software engineer, chances are you must have gotten stuck in a problem that seemed super hard to solve. Also, if you work in sprints like setup, pretty much all your time for the next two weeks is booked already. What usually happens with these tricky issues is that, it would totally derail all your estimates and planning and you would seriously lag behind your tasks and might perform even poorly because of the mounting time pressure.

Here are some of my suggestions based on my personal experiences working in early stage startup:

This one trick was taught by my CEO at the time in 2013 was that if you can’t figure out head or tail of what to do with a problem, give it 30 mins of serious effort and ask for help.

Why is this such a great advice? Let me break it down for you.

• Asking for help early on basically limits the amount of time that could be wasted because you are trying to figure out something for which you don’t have complete context/background knowledge. If you have more experience folks at work, they can always show you a correct path and you can then follow their advise and solve it with a much higher probability than earlier.

• On the contrary, if you don’t ask for help and only ask the team sometime or some days later, you also put them under pressure as someone else needs to do that task in place of you albeit with more time pressure.

• All setup related issues should be immediately brought to attention of the platform/Ops/Senior developers. A good reproducible working environment is a must with any productive company.

• However, this doesn’t mean that you run for cover every time you face a problem. You should definitely try to think about a solution and write it in a written format, then discuss your approach without writing a single line of code. The good thing about this approach is that your peers will see that you have put some effort into the problem, and discussing potential solutions also gives them an opportunity to improve your high-level design and suggest improvements.

• This is also the culture that one should teach newer/junior devs so that it becomes more of a cultural thing with the dev team.

• You don’t have to suffer because of a hard problem/setup issue mostly because you are not asking for help because of your EGO. EGO has no place in a collaborative environment. It’s good to know what you don’t know so that you can ask help and be better at it.

• Another important thing to note here is that one should try not to ask for the same advice twice. Let me explain:

Say you had a Docker issue, and you ask your senior for help and they solve your problem. It’s your duty to make a note or video recording of the help, so that if you face that problem once again, you can solve it on your own next time. This saves time for everyone involved. Anyone will get annoyed if you get stuck with the same problem and don’t take notes of the solution, and keep coming back with the same issue. Making notes of the solution is a great approach and it shows how much you respect others’ time.

Hope these tips would help you become a better developer and an asset to the team.