Imposter Syndrome Series Part 3: I'm going too slowly!

Nicole GathanyNicole Gathany
12 min read

Welcome to my series on imposter syndrome! So far, I’ve made a laundry list of all the things that make us, particularly software engineers, feel like we’re not good enough but that shouldn’t. I also did a deeper dive into one thing that makes us feel that way: not knowing enough.

In this blog post, I’m doing a deep dive into another major source of imposter syndrome: not progressing quickly enough. This slowness could be in our careers. In our ability to land a job at the same time as those starting out with us. In our ability to advance to senior, staff, principal, or lead engineer or engineering manager at the same pace as our peers.

It could also be in our ability to finish a course or learn a concept with those in our learning communities.

I can speak for myself. I’ve known people who started programming around the same time as me or even after who have titles like “Senior Engineer” or even “Director of Engineering” sometimes as FAANG companies or companies where I would love to work but couldn’t even get past the 2nd round of interviews for a senior or mid-level role.

Lots of people have zipped through the 100Devs course in 2 months, while I’m still in class 12 after 1 year.

Some of my delays have been the result of getting distracted by other things like a React course on Scrimba, freeCodeCamp’s course on React Native, client work, interviews, Leetcode practice, or a system design course.

Even without the distractions, I can just be plain slow. It took me a whole month of deliberate focus to just get through the Shay Howe reading (if you know, you know). I wrote questions and answers for some of the concepts and Anki cards to match. That made it even more time-consuming.

And my personal project, MournTogether, is taking forever!!

I started with the UI designs I made in Canva which was pretty easy, then I started building the design in React Native, thinking “This will be easy. React Native is just like React.” It’s not just like React. It’s kinda different in quirky ways, and I didn’t realize styling would be such a challenge not only because React Native defaults to style props but because 1. I don’t want to use style props because it violates separation of concerns and CSS modules, the alternative requires downloading dependencies but also 2. I forgot a lot about flexbox (which is defaults to) and because it’s not a perfect translation from flexbox in vanilla CSS.

I’ve been really hard on myself about the speed at which I’m progressing for so many things.

I feel bad about the speed at which I’m able to land jobs, get promoted, or complete a course.

However, for the past month I’ve been tutoring kids–yes this is what I have to do to survive in this economy while a freelancer and working on projects. And I learned a lot about learning and pacing from some of my temporary students.

/

What I learned about pace from kindergarten scholars

I tutored kindergarten students recently, and helping the little students with a worksheet changed my perspective on speed.

We worked on a worksheet together where there were pictures at the top and at the bottom there were 3-letter words with the letter “o.” The mission was to pick a word, find the picture that matched with

The first word was “pop.” Most kids were able to identify the balloon being popped with a pin as representing the word “pop.”

Most rapidly colored the picture and moved on.

Enjoying the journey and gaining extra skills

There was one girl (we’ll call her C) who made the connection quickly, but she took her time coloring the balloon.

She said “I’m coloring it a rainbow color, because I saw a rainbow balloon at my house!”

When she got to the word “sob,” like most kids she asked what that meant. I told her “It means crying really hard!”

So she found a picture of a little girl crying and said “I’m going to color her with this crayon because it’s close to my skin color and I’m going to color her dress pink because I have a pink dress.”

She won’t get extra points for it, but the way that she deliberately chose a way to color the pictures and explained her thought process is a great skill in my opinion! It may have taken her longer, but I think it’s really great that she made it her own.

Needing extra help and getting distracted

Another kid took longer because he did need extra help. It took him a while to get started because he was distracted but when he saw the other kids working, he asked for help.

He asked “What’s this word?”

I asked “What sound does the letter ‘p’ make?”

He said “Pa, oh, pa. Pop!”

He quickly colored the balloon blue. He did this for all the words.

This student was taking longer for another reason but I appreciated his fearless in asking for help (another great skill for software engineering and beyond).

Like these kids, I get slowed down by the same things. By wanting to make the project my own. By getting distracted. By just not knowing but still demanding to understand. By just enjoying the ride and wanting to make the most out of the experience.

Watching the kids learn, I now don’t see my lack of speed as a bad thing (I know that lowing latency in a system save money but when it comes to learning, speed can mean something different).

Why speed is good but has tradeoffs

I also want to say on the other hand, there was a kid that just colored whatever picture whatever color with reckless abandon. And I see kids like this all the time.

I grew up with kids like this.

Those who rushed through classwork and rushed through homework in class so they could do something else when they got home, like play video games or go outside and play.

My dance teacher said she rushed through the work so she could focus on dance. She did get good grades but she didn’t retain anything afterwards.

Some students rush through assignments faster than others and still get the answers right. Some do not.

I think what happens is we want to finish some tasks efficiently because we care less about them. Who wants to take 2 hours everyday washing dishes when we could watch TV or go to the park?

One of my classmates I grew up with wanted to spend more time outdoors riding his bike with friends.

My dance teacher wanted to focus on her true passion: dance.

Some students want to get on their computers and play whatever game.

But me and C, we want to do the work. And me and K we want to understand the work and might get distracted in between.

As a software engineer, I would personally rather work with people who are thorough and are good at explaining their process and who have fun while making it their own or people who aren’t afraid to ask questions, accept help, figure it out and learn.

There are many people who are able to balance speed and accuracy. That’s never really been me. Not that I can recall.

Why we rush

I think also sometimes we have our own natural pace, but we feel pressure to go faster because of things like time tests which if we don’t do well on, we getheld back a grade or miss out on opportunities like the Duke Tip program (which while I was in the gifted program was never invited to do) or go to our dream college. We miss out on a certification that might look good on our resume. We miss out on a client or a job.

The world wants us to rush so when we can’t, this brings out the imposter syndrome in us.

We see people take an 11-week bootcamp and get a job within a month and get to be a senior engineer in 8 months.

We see people progressing faster than us and we think “Why can’t I do what they did?” “Why did it take me 6 months to get a job after the bootcamp?” “Why did it take almost 2 years to get a job that actually paid well?” “Why is it taking me so long to finish my app” “Why is it taking me 2 years to land a role after being laid off?” “Why am I only on class 12 of 100Devs after a whole year?” “Why does this video say I can learn React Native in 4 hours but it’s actually taken me 10 hours to get through one of the four?”

Looking back on some of these questions, especially the ones about landing a job, I feel like I was a little entitled, honestly. (Sorry, 2020 Nicole, and no offense to anyone who relates to these questions, but it’s true).

These are jobs that typically take a 4-year degree in a subject that’s not easy and a couple of summers of internships. Why did I think I was promised a role like this with 11 weeks of learning outdated React? (We learned class-based React in 2019).

This is not to discourage anyone who is self-taught, community-taught, or has done a bootcamp. This is not to say that college-educated software engineers are automatically better than those who just learned on the job or by building things (I may write a post about this as well).

But the fact that it’s taken me longer than others (so I assume and I say “assume” because I don’t know what they were doing before their bootcamps) doesn’t mean there’s something wrong with me. Or maybe it does? But that doesn’t take away my humanity. And it doesn’t mean I’m a bad engineer…some of the best engineers I know are neurodivergent.

It could just mean that I’m going at my own pace like I always have.

It could mean that I’m taking my time to really understand and remember like my student K.

Or that I’m enjoying the process like C.

Or that I’m distracted like K.

Whatever the case, I accept myself.

My brother used to tell me that I was slow at life. All the time.

Kids at school would say the same.

Then one day after my brother had been teaching for a few years said “You’re not slow…You’re just thorough!”

Me, C, and K , we’re just thorough.

I also want to talk about how sometimes we have that technical interview with Google in 3 months and we want to go over every leetcode problem in that time. Or at least 75 leetcode problems. But Alvin the Prorgammer says it’s better to review problems more than once than rush through problems and never come back to them.

The benefit of learning slowly is that you get to enjoy the journey and might have a better chance of retaining it all.

Deeper knowledge can slow our process down…in a good way?

As I said before I have been taking the 100devs curriculum for a year and i’m only on class 12. One guy told me that because I’ve worked as a software engineer before and because I’ve already done a bootcamp, I should be able to zip through the 100Devs curriculum.

I feel like actually I’m going more slowly because of those things.

Because I’ve worked on an enterprise-level application, I know the importance of things like accessibility and responsive web design. How not having accessible applications can make a company or startup lose money and have to lay people off. How it’s better to design with all screens in mind before implementing CSS. How flexbox is just…hard to learn and remember because it doesn’t make intuitive sense but that it’s still important.

Because I know these things are important, I am going more slowly and more deliberately through the HTML and CSS parts of the course. In the past, when I learned HTML and CSS, when I was a fresh programmer back in 2014, I went through them quickly. I thought they were easy. But now that I know what they can really do, I’m going through them slowly.

Because I’ve worked with JavaScript so long, when I learned recently that typeof null === object, that stopped me in my tracks. Whereas if I had learned that as a beginner, I wouldn’t have even blinked or I might have been confused, but ignored it because that would have meant nothing to me.

Before if you told me that “Read-through” caching is a solution to cache-aside’s consistency problems, but Read-through has database cache consistency problem too, I would have just been like “Weird but ok.”

Now I’m ready to investigate why.

It reminds me of when my mom told me that when she started college, she thought she knew everything. When she graduated from college, she felt she knew nothing. Or when a 4-year old girl told me that 2+2 was 4 and when I was amazed she told me she knew everything even though she asked me if knew 100+15 was 115 because I counted it with my fingers.

The more we learn, the more we realize we have to learn.

The deeper I go, the more curious I get, the more questions I have.

Maybe imposter syndrome can be a sign of growth.

...Maybe it’s better to look at your process and speed like an engineer. Rather than as a value judgment.

I feel bad for being critical of the fast engineers. The fast learners.

Maybe it’s better to look at your process and speed like an engineer. Rather than saying fast is better and slow is worse, or vice versa, we can say that there are trade-offs. The benefit of going faster is that you can get the job done faster or make time for others more important things like dancing or spending time with friends. The downside is you might not retain it all or you might miss something.

An engineer doesn’t just measure how fast a system is—they measure why it performs the way it does. Is the latency due to heavy load? Is it because of a memory leak? Or maybe it’s optimized for readability and maintainability, not raw speed.

You, too, are a system—complex, evolving, built with purpose. Your pace might come with trade-offs, but it also comes with benefits: deeper understanding, empathy, creativity, and grit.

And like any system, you can iterate. You can review your “performance logs,” experiment, pause, and refactor. But none of it means you’re broken.

Maybe you're just like C: coloring in your life with intention and detail.
Or like K: needing help sometimes, but figuring it out fearlessly.
Or maybe, like me, you’re just trying to build something beautiful—even if it takes a while.

So if you’re moving slower than others, whether it’s in your coding journey, your job hunt, or your personal project, that’s okay.

I’m learning that progress doesn’t always look like speed. It can look like curiosity. Like coloring a balloon rainbow colors because you saw one once. Like asking for help and sounding things out. Like coming back to a problem again and again until it sticks.

I might be slow, but I’m thorough. And I’m learning at my pace, just like I always have.

0
Subscribe to my newsletter

Read articles from Nicole Gathany directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Nicole Gathany
Nicole Gathany

I am a people-centered software engineer with a past life in public health and reproductive justice. I'm using this blog to combine my love for tech and communication.