Managing Imposter Syndrome

I was recently promoted at [Hugo Health](https://hugo.health (opens in new tab)) 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

<Aside>

🌟 **Imposter Syndrome**, also known as impostor phenomenon or impostorism, is

a psychological occurrence in which people doubt their skills, talents, or

accomplishments and have a persistent internalized fear of being exposed as

frauds.

</Aside>

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 competence 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.

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 receiving 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 parmesan 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 manageable 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](https://girlswhocode.com/ (opens in new tab)) 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.