In my experience, the best way to insulate yourself from the pangs of imposter syndrome and unproductive self-doubt is with experience of past successes.
Early in my software engineering career I would constantly and painfully wonder if I was actually capable of fixing a certain bug or solving a new or difficult problem. But then after working hard on a solution, 99% of the time it would work out. After going through this process of debilitating self-doubt and eventual success over the course of years, it has become much more manageable.
I still sometimes panic when initially faced with a very difficult programming problem, but I can put those fears to rest much more easily by saying, "ok, I've solved hard problems before. I may not know how to solve this particular problem yet, but I feel confident that I will be able to figure it out just like I did in the past with difficult problems X, Y and Z."
At the risk of sounding pedantic, part of leaving the beginner phase — and the true value of experience — is developing a kind of armor against those feelings of inadequacy (of course you don't want this to go too far into feelings of overconfidence or an inability to reflect when things do go wrong).
I also think it's the responsibility of more senior engineers to recognize when a more junior teammate might be having those self-doubts and be empathetic while helping them build up their own successes.
> I still sometimes panic when initially faced with a very difficult programming problem, but I can put those fears to rest much more easily by saying, "ok, I've solved hard problems before. I may not know how to solve this particular problem yet, but I feel confident that I will be able to figure it out just like I did in the past with difficult problems X, Y and Z."
The following this just my experience, but it's a bit of an odd one! So I thought I'd share for fun :)
I have this too and I only have 1 year of work experience.
What helped for me doing a course where I needed to know:
- C
- X86
beforehand.
The course was about analyzing binaries and malware. I didn't know any C and almost no x86. I did the course as a challenge, but it to date has been the most difficult programming challenge of my life. Teaching yourself 2 prerequisites while following a normal course load at the same time, while feeling insecure and have a strong suspicion to not be intelligent enough was tough, for me.
I've worked at 3 companies in that little 1 year of experience (2 times as a freelancer) and it hasn't come close yet. I'm hoping where it finally gets tougher, but I've heard from people who actually are experienced full-stack devs for 4+ years that that course was way harder than anything they have ever done.
So long story short: do super hard courses. If they're not the hardest courses of your life, then it isn't hard enough.
Self-doubt is just as human as fear, anxiety, or loneliness. It helps when there's some social environment that helps counteract these bouts. By the same token, if the existing environment works to enforce these demotivating feelings, then one needs to acknowledge that it maybe "them", not you, and either build some mental defences or just move on.
Everyone one on the team should be allowed to make mistakes or take bad choices. Juniors, seniors, managers... we are all people, we're all engineers, we're a team! Cult of perfection is limiting to everyone. The manager's job is to recognize everyone's contribution, no matter how small.
Too often, the teams project a higher bar than is actually reachable. Sure it will lead to sense of inadequacy, for absolutely baseless reasons.
Early in my software engineering career I would constantly and painfully wonder if I was actually capable of fixing a certain bug or solving a new or difficult problem. But then after working hard on a solution, 99% of the time it would work out. After going through this process of debilitating self-doubt and eventual success over the course of years, it has become much more manageable.
I still sometimes panic when initially faced with a very difficult programming problem, but I can put those fears to rest much more easily by saying, "ok, I've solved hard problems before. I may not know how to solve this particular problem yet, but I feel confident that I will be able to figure it out just like I did in the past with difficult problems X, Y and Z."
At the risk of sounding pedantic, part of leaving the beginner phase — and the true value of experience — is developing a kind of armor against those feelings of inadequacy (of course you don't want this to go too far into feelings of overconfidence or an inability to reflect when things do go wrong).
I also think it's the responsibility of more senior engineers to recognize when a more junior teammate might be having those self-doubts and be empathetic while helping them build up their own successes.