Impostor Syndrome: The One Challenge Developers Don't Talk About  

Sometimes self-doubt can make you feel like a fake. You’re convinced you’re a fraud and that it’s just a matter of time until your co-workers find out you’re not as smart as they thought. Looking at your achievements doesn’t really help because you’re too busy internalizing your mistakes. If this sounds familiar, you might have something called impostor syndrome. You might also be an engineer.

Software development is no stranger to impostor syndrome. Because tech stacks and languages are evolving constantly, it’s easy for developers to feel like we’re falling behind. Over winter break this past December, my aunt, before even saying hello, said, “Matthew, I read an interesting article about how everything you learned in college will be obsolete in two years.” Not exactly what you want to hear on vacation, but there's some truth to it. We’ve chosen a field that’s always changing and the pressure to keep up with tech, and our peers, manifests itself into this belief that we’re not good enough.

Even though I’ve read a lot about this and why impostor syndrome is so common in developers, for awhile I thought I was one of the few who had ever actually felt this way. So I recently sent a survey to software developers (both at HubSpot and external) simply asking “Have you ever experienced impostor syndrome?” Here's what they said:

That's an insane amount of yeses. Keep in mind the sample size wasn't huge, but still: 88% of developers said they’ve experienced impostor syndrome. Even developers with over 10 years of experience shared feedback that they worry about keeping up with technology, their co-workers, and the pace of development. For a 22-year-old developer with just 14 months of “real world” experience, this was (selfishly) good news. It meant I wasn’t alone; feeling like an impostor from time to time was actually “normal”.

With Great Power Comes Great...Uneasiness

For me, self-doubt didn’t really kick in until I had the opportunity to make mistakes. I worked closely with an engineer during my first internship at HubSpot who has over 3700 answers on StackOverflow and is frequently referred to as the resident Java guru. By my second day, I was given complete control over the project I would be working on. I was architect, implementer, and builder - I shipped my code as soon as it was ready. Today, these are the things that make our development process engaging and rewarding. But at first, that level of autonomy was scary. Having my code reviewed by one of the smartest people I’ve ever met was, too.

I started to wonder if I had somehow fooled my tech lead into thinking I was smarter than I actually was. I waited for everyone to discover that I had gotten here by accident. But that didn’t happen. No one ever pulled me aside to say they were onto me because it was all in my head. Instead, I made a ton of mistakes, quickly learned from them, and slowly started to realize something that’s helped put me at ease over time. And that’s that being uncomfortable can be a good thing because when you’re complacent, you probably aren’t growing. 

Getting Comfortable with Being Uncomfortable

I’ve interned with companies in the past where there was separation of state for the product. There were QA teams, there were architects, and there were two week iteration cycles. As an intern, I was constantly monitored and given mundane tasks that other engineers had passed on. I never really doubted myself as a developer because I never had to leave my comfort zone or collaborate with experienced engineers.

The problem with that is that you have to be challenged if you’re ever going to get better at something. That’s as true of development as it is of tennis or playing the piano. Staying in your comfort zone won’t change the way you develop code. But challenging things, which for me were autonomy and smart people, will because you want to make sure your code is perfect before it’s in production. I now review my PRs four or five times before submitting them and pay closer attention to my code. That doesn’t mean I don’t still feel like an impostor from time to time; there will always be tons to learn and smarter people in the room. It’s just that I try to think of my internal doubts as growing pains.

A Few Thoughts on Building Confidence

Getting comfortable with discomfort has helped me deal with self-doubt. But on a day-to-day, that’s a lot easier said than done. So, here are concrete ways that have been key in building my confidence over time:

• Take Your Time: I think a lot of engineers, especially younger ones, feel this giant need to produce code and tangible advancements quickly. There’s so much emphasis on speed when you usually have much more time than you think you do. Take an extra hour or two to write more tests or review your code; it’ll save you time in the long run.

• Look, Then Ask: On my first day at HubSpot I got a bowl of cereal and milk, but couldn’t find a spoon. I sat and waited for someone else to grab a spoon just so I wouldn’t have to ask anyone where they were. I’ve realized since then that it’s ridiculous to be afraid of asking questions. Most people like explaining something that they know that you don’t. Just be sure to look before you ask because there’s probably some documentation or source code out there that can help, too.

• Give Yourself a Break: Development has a wide scope and you probably won’t master everything there is to learn. And that’s okay. In the survey, Josh Levinson, an engineer here at HubSpot said of some of our co-workers: “I might feel like an impostor when talking architecture with Hatchet, or code with Matt Ball, or math and analysis with Axe. But I’ve managed to internalize that just because I'm objectively below some people in one specific skill doesn't mean I’m not as skilled overall.” Instead of getting hung up on what you don’t know, try to relax and learn from the people around you.

• Look for Growth-Oriented Cultures: Impostor syndrome is, by definition, an internal thing. But managers and companies play an important role in how confident employees are in their work and skills. Take feedback, for example. I’m lucky to have managers today that don’t just say “You’re doing great,” but tell me what I’m doing well and how I can improve. There’s not as much room for second-guessing when you truly know how you’re doing. For less experienced employees like me, mentorship is key. Over the course of writing this post, HubSpot actually launched a new company-wide program for employees to get 1-on-1 guidance from leaders who aren’t their direct managers. If a company cares about helping employees grow, their culture will reflect that.  

When I first started writing this post, I felt (fittingly) nervous about putting myself out there. But then last week, during our annual INBOUND conference, our VP of Culture tweeted a quote from Seth Godin that resonated with me. During his talk he said: “The story you are telling yourself about your competence or incompetence, it’s all invented.” Instead of letting self-doubt craft elaborate stories in our heads, developers should remember that it’s okay to feel uncomfortable sometimes as long as it's not stopping us from taking on new challenges or eating a bowl of Cinnamon Toast Crunch.