Overcoming Imposter Syndrome as a Software Engineer

5 min readAug 17, 2021

The nature of software development is fast-paced, fluid, and always in flux. It’s what makes building software so challenging, interesting, and fun, but that also means that you’re constantly faced with things you don’t know. Even the things that you don’t know (and everyone says you “need to know ASAP”) are changing before you can even start to know them.

So, you’ll need some ways to overcome that feeling of being an imposter. Here are a few ways that help me:

Get a Mentor

This one ain’t easy but it’s one of the things that most helped me get through my beginnings as a Software Engineer. Preferably, your mentor is someone who is more experienced than you in software engineering or has worked on software teams. A mentor can really help you get over the many humps you face early on. They don’t necessarily have to help you get over those humps by coding with you, but they can help give you perspective and guidance on your progress.

Likewise, once you you become more comfortable and experienced yourself, I encourage you to pay it forward and reach out to those who might be facing the same struggles we all faced in the beginning.

Get a Peer Pair

Form a “peer pair” with someone who is going through what you’re going through. It can be immensely helpful to be able to communicate your frustrations, failures, victories, or even just the day-to-day. With a peer, I have found that you can be more open without worrying about how they may view you. And more importantly, you can listen and learn from what they’re going through.

There’s a lot of fellow “newbies” out there in the developer community (check out the appropriately-titled CodeNewbies community) and everyone is a newbie in something. There’s a lot to learn about the different ways we all approach learning. So, find someone with whom you can share your learnings.

Surround yourself with smarter people and take advantage of it

My first job in software development was as a Test Engineer at Groupon. I realize that not everyone is as fortunate to join a company with hundreds of experienced engineers. But, as you search for meet-ups, online communities, or prospective employers, put yourself in an environment where you’re the dumbest person in the room. That’s the way you’re going to learn the most.

Be curious

Once you’re surrounded by smart people and challenging problems, be curious. Apprenticeship Patterns by Dave Hoover and Adewale Oshineye is a great book and a must-read for all developers. It treats software development like the craft that it is and paves your long journey from an apprentice to master with practical patterns. One of these patterns is “Exposing Your Ignorance”:

“The most obvious way to expose your ignorance is to ask questions. This is easier said than done, particularly when the person you’re asking has assumed that you already know the answer. Press on! Sure, you could protect your pride and take less direct routes to obtain the required knowledge, but remember that your road to journeyman will be shortened by taking the most direct route available.
With practice and time, you will find that asking direct questions to the most knowledgeable people on your team will become second nature. While you are exposing your ignorance, you are also exposing your team to your learning ability. And sometimes they will gain a new clarity about their own knowledge in the process of answering your question.”
— Chapter 2: Emptying the Cup, Apprenticeship Patterns

Pick something and practice it, regularly

Earlier this year, a fellow coworker of mine declared his next month the “month of React.” So, he spent that month focused on learning React. From an outside perspective, I could see his conversations around React evolve over the course of the month. By the end of the month, he had created a #react-js slack channel within the company, was sharing links to libraries and concepts that others hadn’t encountered, had written a great blog post about learning ReactJS, and is now building a big feature in React.

I’m not exactly sure how he picked ReactJS to be his focus, but it doesn’t matter. He picked it, stuck with it, and deliberately practiced it.

Make decisions consciously

Oftentimes, when faced with an overwhelming codebase, it can be easy to fall into the trap of programming by copy-pasting code, following existing patterns, and “making it work” without thinking through your choices. Try not to fall into this trap.

When you’re writing code, make sure you understand how your code works and why it’s structured in the way that it is. Remember, I’m not saying that you shouldn’t ever copy-paste code. I’m saying that, if you are copying code, it’s important to understand the code that you’re copying because you are implicitly making all the decisions that were made by the original author(s) of that code. And you are also making an explicit decision not to refactor the code so that you don’t have to copy it.

Basically, when someone asks you, “Why did you build it this way?” — try not to respond with, “Well, this other code was written that way.” This may mean that you won’t write a solution as elegant or reusable as a more experienced colleague but, if it meets the requirements of the task, that’s okay! Over time, each decision you consciously make, articulate, and learn from will help you make better decisions in the future.

Be aware when you’re experiencing imposter syndrome

Awareness is a big step in actively combating imposter syndrome. For me, self-doubt creeps in as I’m implementing a feature and it starts to take longer than it “should.” As this happens, I start to stress about how I’m being viewed by my co-workers and managers and this usually further delays the feature. It’s a vicious cycle and the only way to get out of it is to realize that I am stuck in this circle. I remind myself:

The feature will take as long as it takes me.
I work hard and care about the quality of the code I produce.
I have asked for help when I’m stuck. If not, I can and should.
I have communicated my current status to the stakeholders of my feature.
F**k everything else.

Read Chapter 1 of the Pragmatic Programmer

I recommend the whole book, but if you’re only going to read only one chapter, this first chapter articulates the philosophy of a pragmatic programmer. Some of the great advice include reading a technical book every quarter, participating in local meet-ups, and so much more. Don’t worry about your current skill-set or experience or how you’re perceived. If you’re practicing the lifestyle laid out in this chapter, then you’re doing it right.

That’s it

Now go forth and fight those battles against self-doubt, insecurity, and imposter syndrome. Remember, there’s a big difference in how you perceive yourself and what is reality.