DEV Community

Cover image for Dealing with Imposter Syndrome
Jing
Jing

Posted on • Originally published at blog.jingjinghu.com

Dealing with Imposter Syndrome

When I started my first developer role about a year ago, I was both excited and worried. Excited to code on the job, and worried that they'd fire me when they found out that I didn't actually know how to code.

I had just written my first lines of JavaScript a couple months ago, and the knowledge gaps I had seemed infinite. It felt strange to call myself an Engineer when others who started with me clearly knew so much more than me.

At first, I attributed these self-doubts and feelings of insecurity to my career change. After all, people's professions often form an important part of their identity, and mine had just changed completely. But over time, I realised that a lot of people around me felt the same, regardless of their background.

I also realised that there are moments when I feel more like an imposter and moments when I feel less like one. And while I still have self-doubts every now and then, there are some practices that have helped me to feel more confident in my skills over time. So I thought I'd share these with you in the hope that they'll help you too.

Recording achievements

I know I have mentioned this one in another post before, but it really helped me a lot. It was actually my manager who suggested I record my achievements when I first started. It was mainly intended to help me pass probation. But it eventually turned into a reassuring habit that also helped me later down the road.

Looking at my personal achievement sheet from time to time made me realise two things: 1) We forget so much more than we realise, and 2) however little you think you know now, you most likely know more now than you did yesterday.

You think you'll remember all the amazing things you've done and learnt along the way. But every time I look at my sheet, I stumble upon something I completely forgot about. And it's hard to feel a sense of achievement over something that you don't remember.

Looking back, I at one point also realised that there are so many things on that list that seem small to me now, but probably wouldn't have to my past self. Thinking about it this way, the sheet highlights all the progress I've made since the very beginning. And that feels very reassuring. To know that however little I think I know, I know more than I did yesterday.

Pairing up and asking lots of questions

Pairing up with others is not only fun, but also helps to put things into perspective. Initially, I had a tendency to think that everyone around me knew and understood everything. But while pairing up and asking lots of questions, I slowly realised that that wasn't the case. Instead, every member of our team seems to have their own area of expertise that simply overlaps with that of others. But no person knows it all.

I still remember pairing up with our lead engineer for the first time. Every time I asked a question, I fully expected him to launch into a lengthy explanation of the details of what I wanted to know. So every time he responded with "I don't know" I felt a strange sense of reassurance. Even after over 10 years of experience in the field, there were things he didn't know. That doesn't mean that he wouldn't be able to find out, but it's a gentle reminder not to put yourself under too much pressure to absorb everything.

Treating yourself like your best friend

This is a tip I've come across at one point in my life that I've never forgotten since. When we experience self-doubts, we often engage in negative self-talk. Instead of lifting ourselves up, we tend to enter a downward spiral where we beat ourselves up over the mistakes we have made. We also tend to compare ourselves, which only makes us feel worse. But imagine it wasn't you who was struggling. Imagine it was your best friend. Would you say the same things to them as you would say to yourself?

If one of your closest friends came to you and said "I can't seem to solve this problem, I'm so bad at coding". Would you discourage them from continuing? Would you dig out whatever doubts they might have shared with you? Would you encourage them to compare themselves to others? I don't think you would... or at least I wouldn't. I'd try my best to remind them of all the progress they've already made and encourage them to take a break before continuing. That's what I'd do.

For some reason, a lot of us seem to find it easier to be compassionate toward others than ourselves. While I'm not sure why that is, thinking about your closest friends and the way you'd treat them in the same situation might help you to avoid negative self-talk and treat yourself better.

Finding a go-to person

I was lucky enough to be assigned a mentor at work that did not only help me become a better developer, but also became a good friend over time. But even if you weren't formally assigned a go-to person, there are still many ways to find one.

You don't necessarily have to go up to a person and ask them to be your mentor. What you can do is pay attention to the things other people are good at that you'd like to learn and ask to pair up with them on certain tasks. That way, you can also get a sense of how patient they are and how comfortable they are with you asking lots of questions before making them your go-to person. Or at least that's what I did. That way, I actually found myself another person I'd consider a mentor even though we don't have a formal mentoring relationship.

A go-to person is someone I often turn to for feedback or for questions that I might not feel comfortable asking in a bigger group.

And if you can't find a person at work or want to find one outside of work, why not try one of the many free mentoring platforms out there.

Focusing on learning

Or more specifically, focus on learning things that you're curious about.

This is something I sometimes neglect by accident. But I've noticed that I tend to feel more positive about development and my coding skills more generally when I take the time to explore technologies and frameworks that I'm curious about. They don't necessarily have to have anything to do with work. That's where my problem lies, because I sometimes get so caught up in learning whatever is directly relevant to my work that I spend less time exploring topics that are not.

But it's important that you do, especially at the beginning of your career, because that's how you find out what you really enjoy and what you'd like to focus on. I can't say that I've been particularly good at it, but I want to make it a priority for 2022. I know, I know it's never too early to start... but mentally, I still find the end of the year a good time to wrap things up and start with somewhat of a fresh mind in the new year.

Of course it's even better when what you're curious about and want to learn and what you're working on overlap, but that's not always the case. And that's ok.

Helping others

And finally, helping others. Whether it's helping new joiners at work or people outside of work - it's a way for you to apply your skills. Even if you think you're not ready for it, there is something you know that another person doesn't. And when you try to help others, you'll find out what it is.

Of course there will be things that you don't know from time to time, but sharing is not only caring but also a form of learning. Being a buddy at work, for example, does not only remind me of the progress I've made since joining, but also makes me realise where the gaps are that I need to fill. It helps me narrow down what I need to focus on in terms of learning.

Concluding words

And that's it. Those are some of the practices that, in hindsight, have helped me to feel less like an imposter. That doesn't mean that I don't experience self-doubts from time to time, but it has definitely helped me to feel more confident in my skills over time.

Apart from the above and a general willingness to learn and improve, I think that a supportive team is also very important. I consider myself lucky in that regard, but I just wanted to mention this, as I've been in less supportive environments before and have definitely felt the difference. So it's not always you.

And at this point, I should probably also mention that if you are a more experienced engineer and want to help new starters and career changers feel more comfortable around you, there are two things you can do today: 1) avoid using acronyms or explain them properly the first time you do, 2) say "I don't know... but I'll find out" more often.

That's it (for real this time). Thanks for reading and have a nice day! 😊

Cover image by Timothy Dykes on Unsplash

Top comments (7)

Collapse
 
artdevgame profile image
Mike Holloway

Could you give some examples of the achievements you took note of please? I think this could help me, but not really sure what to note. It would be useful to see an example or two.

Collapse
 
codedpills profile image
Zak

I have a similar question as Mike. I've heard this a couple of times but I'm not sure what to note down as achievements. If I'm able to complete my assigned tickets in time within a sprint, is that considered an achievement?

Collapse
 
artdevgame profile image
Mike Holloway

I found an earlier post of Jings that goes into specifics, also worth a read: blog.jingjinghu.com/tips-for-start...

Thread Thread
 
codedpills profile image
Zak

Thanks for sharing, Mike!

Collapse
 
jingjing142 profile image
Jing

Hi Mike, sure!

So, for example, when I first started, I did a Udemy course on TypeScript. And shortly afterwards I worked on a ticket converting part of our codebase from JavaScript to TypeScript. So I wrote down "took TypeScript Udemy course and learnt about the fundamentals of TypeScript". For the ticket itself, I wrote down

PR #XX Ticket name

  • Link to ticket
  • Converted several components to TS
  • Worked largely independently and applied newly acquired knowledge
  • Pair-programmed with XXX to solve unexpected, tricky errors
  • Addressed PR comments from other team members
  • Took notes that others can use as a future reference when converting files to TS

Of course it can vary a lot based on the ticket, but that's how I do it. I mainly use bullet points to keep it simple. I also note down the number of the PR, since I find it quite motivating to see how many tickets I've already handled, but of course the amount should not matter as much as the quality :P It's just a personal thing. I also add the link, so I can always go back and check my own PR in case I'm doing something similar again or forgot how to do something I already did (it happens).

But again, it really depends on you and what works best for you. You can always experiment and see. Just try not to discount your own achievements. What might seem small to others, might be a big achievement for you, and you should record it accordingly :) Working independently, for example, might not be worth mentioning for some others, but as a career changer it felt like a little milestone so I recorded it.

Hope that's helpful 😊

Collapse
 
artdevgame profile image
Mike Holloway

Thank you Jing for the detailed reply, very helpful.

Collapse
 
dozykeys profile image
Duru Chidozie

In addition to what Jing stated,i want to assure you that if you consider researching on a topic and writing little topics on it. Over a little while,you will be surprised at the opportunities you will be exposed to. Asides tht,it will give your self development a big boost.