Great Developers Ask for Help
By: Raafay Khan
Tags: Software Engineering, Remote Work, JavaScript, Programming, Startup

Great Developers Ask for Help

It’s tempting to do everything yourself, but we can go much further together

Photo by Perry Grone on Unsplash.

When we start our engineering careers, everything seems difficult — from complex programming paradigms to the weird syntax of a language. Once developers get the hang of things, they find that whatever problem they come across can be fixed with elbow grease and coffee. This creates an “I can do anything!” mindset.

While this holds true, let me explain how this can lead to reduced productivity and ultimately burnout.

Programmers often take on difficult features without consulting their team to prove that they are excellent engineers. They believe that they can create a solid solution by themselves. This may be due to impostor syndrome and the need for validation from peers and supervisors. Every developer wants to prove that they can create reliable features and pull their weight on the team.

This approach generally backfires, as the developer has taken on a task that is difficult and must implement it in a limited time frame. Since they said no help was required, it would be embarrassing for the task’s timeline to slip or for the result to have bugs. The added pressure of getting it right creates anxiety and the development process is slowed down even further. Now, there is a negative feedback loop generated.

Existential dread, “Why am I even doing this?”/minute, and coffee cups/hour are inversely proportional to the number of days until the deadline. Since the developer cannot focus on the solution because they are so fixated on saving their reputation, the timelines start to slip. After pulling all-nighters and hacking together a solution, the developer finally turns it in to QA for testing. These situations can create burnout. Burnout does not only affect a single individual but the morale of the whole team.

In retrospect, we can see that the easier way would have been to ask for help when they got stuck. Once multiple people start working on a problem (like a team), responsibility is lifted from a single person’s shoulders and the negative emotions created by stressful deadlines are greatly reduced. There’s no better sense of security than knowing that someone has got your back.

The rubber ducky method is widely celebrated and recommended in the programming community. A human rubber ducky is exponentially more efficient and effective, as you get real-time feedback on your proposed solution. When you have to explain a solution to another developer, you first need to have a deep understanding of the problem and the thought process you went through to create the proposed solution. What I have learned is that when you explain the problem to your peer or supervisor, you often come up with the solution yourself, as you now have a deeper understanding of the problem and your solution’s possible caveats.

When you are explaining the problem to a peer, ask them to poke holes in your thinking. This is a highly effective method in catching nuance bugs in logic before they occur. Once you verbally agree on the problem statement and the path that you are going to take to solve the problem, create pseudo-code and dry-run it once or twice with multiple cases and conditions. This is effective in finding out solutions.

Great people stand on the shoulders of giants. Leverage your team’s collective wisdom and ask for help when you are stuck. This does not mean starting off by asking for help. Individual learning and self-reliance are important. Plus, you do not want to bother your peers every time you face a problem. This will make you reliant on people and decrease the overall productivity of the team.

In Dale Carnegie's book How to Make Friends and Influence People, he explains how the easiest way to befriend a person is to ask for a favor. This might seem counterintuitive at first, but when you ask someone for a favor, you get the chance to interact with them on a personal level. Say you’ve asked someone to take a look at your program while you’re waiting for your code to upload and compile. You can fill the gaps with small talk and then you can get to know the other person on a personal level.

And when you ask someone for a favor, they will be more inclined to ask you for one as well. This will create a bond between team members and increase the quality of team interaction. It is essential to learn, help, and grow with your team members.