Managing Imposter Syndrome

I was recently promoted at Hugo Health from Software Engineer I (the equivalent of a junior-level position at the company) to Software Engineer II. Being a part of a small startup has allowed me to grow and become more knowledgable quicker than I could have ever imagined, but the days of imposter syndrome still loom and it's honestly difficult to overcome the feeling that you do not have the knowledge needed to tackle the problems presented to you. I find myself worrying constantly about what I don't know.

My recent promotion has had me reflecting on where I started, where I hope to go, and what I still struggle with as a developer - whether that be technically or mentally.

My Tools for Managing Imposter Syndrome

It's the gnawing feeling that you're not good enough to be here. You believe that you don't have the same skills as those around you, or that you don't deserve to be there. All this anxiety is in spite of one's competance and success.

Almost every junior developer, or junior level worker in any industry, feels this way at some point within their beginning months. It's frustrating trying to learn the ins and outs of a new stack, or the quirks of a certain company.

I can tell you with 100% certainty that I didn't feel remotely prepared arriving to the job. I was properly equipped with a computer science degree and could apply data structures to college-type problems or tell you all about Big-O of a certain algorithm, but I had only used git for personal projects, or projects with only two other collaborators (minimal conflicts). I hadn't used a Kanban board, Kubernetes, or a queue service like RabbitMQ. My SQL abilities were enough to get me through courses and I could tell you how to implement databases on a theoretical level but navigating our Mongo database scared me half to death.

I think many of us have this idea in our heads that in order to take on a job, we should be 100% prepared and we should know how to do everything ahead of time. This is beyond unrealistic. No one person can know everything, especially in a field as vast as software engineering.

Reflecting on my time in the beginning of my career, there are a couple things I did that I believe helped me become more comfortable taking on tasks without the help of coworkers.

Outside Learning

To start, I made an effort to learn about the tooling we used outside of work. I am generally one to advocate for work-life balance, but I would argue that adding this additional time (generally about 30-45 minutes) of reading every day shortened my workday. Maybe not immediately, but over time. Instead of reading documentation or resources that were necessary to accomplish the task, I could stick to asking questions only where I got stuck, or doing readings that were relevant to the blocker.

Over time this allowed me to build my background knowledge to a point where I could become relatively self-sufficient. This ability to rely on others less made the Imposter Syndrome feel less overwhelming.

Asking Questions

Speaking of questions, I tried to adopt an practice of always asking the stupid question. I often preface these types of questions with "this is probably a stupid question", or some other variation of the sentiment, to which my coworkers reply "there's no such thing as a stupid question". Most believe this to be true, but I do believe that there is such thing as a stupid question. But just because it's a stupid question, doesn't mean it shouldn't be asked. Even the stupidest of questions demonstrate to your coworkers that you are actively engaging in the material and system, that you're curious, and that you want to be able to understand these things on your own.

He who asks is a fool for five minutes, but he who does not ask remains a fool forever.

Mark Twain

Besides, nobody knows what they don't know until they know it.

The 40 Minute Rule

I also adopted something I call "The 40 Minute Rule". I would attempt to resolve a bug, or problem within 40 minutes. If I couldn't or got stuck, I would reach out to someone to ask a question or for help.

When asking for help, try your best to provide the following:

• what you have tried (code examples or text description)
• what you have read (stack overflow, github issues, etc)
• what you are expecting from the code
• what you are actually recieving from the code

Providing this information as opposed to just saying "I'm stuck" or "I need help" is respectful of both you and your coworker's time (i.e. your coworker doesn't provide a solution you've already tried). It also shows that you've put a reasonable amount of effort into resolving it yourself (which, personally, makes me feel better about reaching out for help in the first place).

Try to Have a Game Plan

Something that I learned, unfortunately pretty late, in college is that breaking a large problem up into smaller sub-problems made tasks feel way less overwhelming and ultimately get solved quicker. This can be demonstrated in metaphor. For example, say you're making chicken parmesean over pasta for dinner.

There are two "big" parts of the meal. The chicken cutlet, and the pasta. Making the pasta is pretty simple. The chicken cutlet can be divided into two smaller issues. Breading the cutlet, and frying the cutlet.

Simple example, but it's a simple concept that divides large problems into managable tasks. It's a great skill to have, and helps manage the feelings of overwhelmed.

Being Realistic About Imposter Syndrome

Everyone, even mid and senior level engineers, experiences Imposter Syndrome from time to time. The world of computers, software, and technology is so vast that it is physically impossible to retain all information about every individual subfield.

It's worth putting in mental effort to accept that there will be times where you don't feel like your ability is valid. You shouldn't accept the feeling to be true, rather, accept that the feeling exists. Remind yourself that this is something that everyone experiences, and that you are capable of solving what's in front of you (especially if you ask for a little help along the way).

Also of importance is reminding yourself that your value as an engineer is not tied to the problem at hand. You bring value, not just when you solve it. But also as you work through it.

A Side Note about Being a Woman in Technology

Technology, specifically software engineering, is not a field known for having many women. I remember walking into my Introduction to Computer Science class in college and being surrounded by men. There were maybe 6-7 other women in a class of 80. My university also boasted about having a graduating class that that was 37% women. Granted, that stat is above the national average.

Everything that is difficult about dealing with Imposter Syndrome is exasterbated immensely by simply being a woman in this field.

I'm not implying that only women struggle with imposter syndrome, rather, it's much more likely that a woman in the men's club is going to let that anxiety get the best of her. There is something to be said about representation, especially in the workplace. When you aren't surrounded by people that look like you, or resemble you, it's easier to wonder about why you are there. Are you qualified to be there? Is there a reason others like you aren't there? It feeds into the bias that Imposter Syndrome creates.

If you're interested in helping to close the gender gap, you can visit organizations like Girls Who Code to get involved in the community of women in software engineering.

Closing Thoughts

Managing Imposter Syndrome is difficult, but one can all find comfort in the fact that they are not alone in this struggle. Talking openly about anxieties like this is helpful for everyone. I only hope that more people share their tips and their experiences. The world is more interesting because of it.