Working as a software engineer has its downsides. One of them is that it is very easy to get bogged down in the problem. We have a constant flow of decisions and trade-offs to make.

  • Should I continue with this refactor or should I leave it? It looks like it’s almost done, but I’ve said it three times already.
  • Should I write the tests first to refactor this? Yeah, but I won’t be able to write the tests that easily if I don’t extract this. But if I extract this without tests I may break something.

We keep having such dialogs in our minds for hours and everything seems so complex and each option looks like a dead-end.

We can add remote work on top of that, where we have to do additional work in order to talk to someone. We may fall into negative beliefs:

  • How is that possible that everyone knows each other and I still don’t feel comfortable with the people in my team?
  • What am I actually doing here? How did I even make it through the interview if I’m so stupid?

That also makes it harder for us to talk through the problem because we can’t just walk over to someone’s desk as we can’t see if they are available or not.

The multitasking and asynchronous work is the cherry on top of the cake. Not only can’t we talk to people when we need them, but we also deal with a constant feeling of falling behind because we start multiple topics and never have a chance to complete anything.

These factors may contribute to our negative emotions and stress. Staying in the state for too long and we end up burnt out.

We can deal with these feelings in two ways

  • on our own (physical exercise, meditation, going for a walk, etc.)
  • or ask others for help.

I would like to focus on the latter.

Other people sit outside of our head, they have a different background, different experience and they simply can provide an alternative point of view. Besides that, the mere process of explaining the problem is usually a huge help – hence the rubber duck debugging term was coined.

On the other side of the communication channel there is a human. Showing our vulnerabilities can be perceived as trust. This in turn can make others open up too and we can destroy that false image that everyone is perfect except us. It also helps build healthier team relationships where mistakes and problems are the reasons to grow and not to stigmatize others (Lencioni P., 2002).

It could be that a lot of people are willing to help us but because we, for example, work remotely they don’t even know that we may need any assistance. There are days when we see each other only during quick meetings, where we talk about current work related topics, so there’s no chance to mention challenges we’re dealing with. Therefore, the responsibility may be on our side to reach out for help. And I know this is hard, I’ve gone through it myself. And the outcome was surprising. I’ve been given complete understanding and even some days off outside of my base pool to recover from a feeling of being  overwhelmed and drowning in tasks.

If we struggle with asking for help we can do a quick thought experiment:

If someone genuinely asked you for help, would you refuse?”

Asking for help may be related to our psychological state, and we may need support to avoid burnout, but it can also be related to day-to-day work. And in fact asking for help for code/design related problems may have a lot of benefits. Firstly, it’s easier to catch basic errors when there’s a second pair of eyes looking at the problem.

It can also help us to stop feeling bad about ourselves when we can’t solve a difficult problem at work. When someone looks at it, and they also struggle we may feel ok, because we realize it’s indeed a tough problem.

To sum up, it’s good to ask for help. We often forget that this is one of the benefits of teamwork. We can detect mistakes more easily, we can feel a better connection to the team, or simply reduce our stress by talking to someone. Do you also have any interesting stories when you asked for help and it turned out to be a great idea? Share it in a comment. 

References

  • Lencioni P. (2002), The Five Dysfunctions of a Team: A Leadership Fable, Jossey-Bass
  • “Help wanted” Photo by Nathan Dumlao on Unsplash
Author

I'm a software engineer with 9 years of experience. I highly value team work and focus a lot on knowledge sharing aspects within teams. I also support companies with technical interview process. On top of that I read psychological books in my spare time and find other people fascinating.