Developers: How to Overcome Imposter Syndrome

Abhishek Pillai
Jul 28, 2016 · 7 min read

“Impostor syndrome can be defined as a collection of feelings of inadequacy that persist even in face of information that indicates that the opposite is true. It is experienced internally as chronic self-doubt, and feelings of intellectual fraudulence.”

Caltech Counseling Center

Whether you’ve just begun your journey to learn how to code or you’ve been paid to code for many years, you can and (likely) will face imposter syndrome. I’ve been working as a Developer for four years now and I still face imposter syndrome every day!

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. And 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:

This one ain’t easy but it’s one of the things that most helped me get through my early days as a Developer. Preferably, your mentor is someone who is more experienced than you in software development or has worked on software teams, i.e. in QA, Product, Design, etc. 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.

Here’s an awesome post by Flatiron School on how to find a mentor.

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.

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. Because that’s the way you’re going to learn the most.

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

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.

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.

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:

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

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.

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.

Perception versus Reality

If you want to talk more about overcoming that feeling of being an imposter or how you can help others overcome that feeling, find me on Twitter!

Also, if you’re looking to learn or are currently learning how to code, check out what we’re building over at Flatiron School

Click the ❤ below so other people will see this here on Medium.

Learn. Love. Code.

Insights on education and tech from Flatiron School’s…

Learn. Love. Code.

Insights on education and tech from Flatiron School’s passionate community of coders and creators.

Abhishek Pillai

Written by

Sr. Product Manager @ Teachers Pay Teachers (We're hiring! Formerly at @learn_co and @Groupon. Always Learning.

Learn. Love. Code.

Insights on education and tech from Flatiron School’s passionate community of coders and creators.