Get your Business passes to TNW Conference 2024 🎟️ Buy now →

This article was published on July 15, 2020

A developer’s guide to dealing with growth, burnout, and imposter syndrome

The moment where the onboarding ends and work begins is often a bit overwhelming. Here's how other developers handle growth, burnout, and imposter syndrome.

A developer’s guide to dealing with growth, burnout, and imposter syndrome

This article was originally published on .cult by Ryan Latta. .cult is a media platform for untold developer stories, where developers can read content around the softer side of development and watch documentaries about the tech they love. You can read this original piece here.

Those first few days of a new job are full of excitement, nerves, and dreams of the future. As the onboarding comes to a close, millions of questions remain about how to start doing valuable work. This moment where the onboarding ends and work begins is often a bit overwhelming, and even more so for developers early in their career. Here’s what you might experience, and how to handle it.

Imposter syndrome

Ever feel like you’re a fraud and that sooner or later, everyone will find out? That’s imposter syndrome. People feel this throughout their careers. I still feel it after a decade. For people new to the field, it can create incredible levels of anxiety and doubt. If only we were as good as those other developers! When faced with those feelings, what do you do? What plan do you put into action to stop feeling like a fraud? It turns out that feeling like an imposter urges developers to feel as though they have to catch up.

Catching up

Almost every developer I’ve met, including myself, feels like we need to catch up. We have to learn the technologies, the code base, the social norms, and a million other details before we can be productive. For a start, we don’t know where to look in the codebase. We don’t know what system design exists, so we can’t begin building. What are the standards we should follow? What’s the process the team uses for code reviews and sharing code?

The way most developers catch up is basically the same way they first learned to code. This approach typically involves trying to read every bit of documentation that exists. Suddenly they are looking at tutorials, reading documentation on Redux and internal Wiki documents. They are trying desperately to consume all the material they can. They believe that if they know all of this information, they won’t be so far behind.

Except that it doesn’t really work out that way. At some point, they have to stop reading and start developing. Despite everything unknown, they must write their first line of code. Writing that first line is when that information gets put into practice. You can’t read your way to writing code, you have to write it.

Burning out

The feeling that you’re a fraud is leading you to think you have to catch up, and the pressure to finish work items, and keep up with peers means you begin to work nights and weekends. Trying to read all the material they couldn’t while at work. Then you might do a side project to push yourself even further. You’ll be working late into the night constantly chasing that voice in your head, the one telling you that you should be better.

Exhaustion begins to set in.

How long can someone keep up this round-the-clock pace while constantly feeling inadequate? Everyone has limits, and when this is the way we work, there’s no finish line. There is always someone who does it better and knows more, while making our tireless efforts look easy. We can never keep up, and so we burn out.

How do you know you’re burning out? It shows up differently for everyone, but there are a few key signs to watch for:

  •  Loss of appetite
  •  Major weight fluctuations
  •  Short temper
  •  Fitful sleeping
  •  Nightmares
  •  A daily feeling of hopelessness
  •  Increased chances of illness

Early in my career, I developed a rule for myself. When I started having nightmares about work, I quit. I noticed that by the time I was having nightmares about my job, something had gone so off the rails, and by staying I would only prolong my suffering.

You need to pay attention to what is happening to your body and soul if you experience imposter syndrome. Think of burnout as the culmination of countless small hurts. Each individual one seems tolerable, but together they can damage your health, your mental state, and life. It can take years for those countless small hurts to heal.

How do others handle it?

All those people you think have their act together deal with this as well. They go to new jobs, start new projects, deal with new technologies too. How do they cope in these moments of self-doubt?

It’s important to know that all of us cope with imposter syndrome.

Developers early in their career believe they lack information and knowledge. Senior developers understand they will never know it all and leverage processes to power them onwards.

That’s the difference. Early developers focus on information, and senior developers focus on the process.

How does this look? Well, a senior developer when encountering a new code base confronts the same problem as the junior. They need to quickly make sense of it so they can begin to make changes. A more seasoned developer may apply the following techniques:

  • Matching existing design/architecture patterns
  • Debugging to bisect functionality
  • Executing tests
  • Asking for help

Now some of these things come with practice. One difference would be that senior developers tend to close their knowledge gap with a different process.

Each one of the techniques listed above is a hands-on approach to the codebase. This hands-on approach is a stark contrast to attempting to read your way through the unknowns. Pattern matching is a technique that comes with experience. When developed, a developer can see a new technology or a codebase and make very accurate inferences to how it works compared to similar patterns they’ve seen elsewhere. This technique allows them to focus on the exceptional elements instead of the common ones.

Debugging requires firing up the application with the ability to interrupt it at key spots in the codebase. This technique lets them see what is happening instead of reading about it. Executing tests provides a very similar level of insight while also communicating the intended behavior. The last one is the one to bring attention to.

Asking for help

More seasoned developers have learned to sense when they are spinning their wheels and not making much progress. They also learned early on that there isn’t any reason to struggle alone. They’ll seek help within minutes of encountering a surprise. Someone in the company has the answer.

Getting up and asking them compared to combing through documentation is faster, more effective, and provides longer-lasting information retention. The developer asks a question about one part of the code today, and when they come by tomorrow, the context is already there. This means the answers get richer and more appropriate as the conversation continues.

So for everyone out there who feels like they have to catch up, ask for help! When you get stuck, set a timer for 5 minutes. When it goes off, stop struggling alone and go ask for help. Someone already has the answer for you. This will save you days of struggle, protect you from burning out, and help you get moving sooner. Eventually, you’ll see that all these paragons of productivity are still just people.

Get the TNW newsletter

Get the most important tech news in your inbox each week.

Also tagged with