Three ways to overcome your insecurities as a developer

One of the insecurities that I’ve never been quite able to shake off is the infamous Imposter Syndrome. Although it’s not something developers have discovered per se, the software development community has certainly been shining a light on the pattern for the last few years.

Imposter Syndrome prevents you from appreciating your accomplishments. Instead, you attribute them to luck and often have the feeling that you’ll be found out as a fraud.

I am not a psycho-anything therefore I won’t postulate as to the causes of Imposter Syndrome but will instead highlight remedies I’ve found helpful while navigating the high-pressure world of software development.

Everyone is terrible

No, seriously. The only reason we think we don’t measure up to the people around us is because we are only really seeing what we’re doing. Unless your colleagues come up to you and say flat out, “Dude, I have no idea what I’m doing and I’m sweating profusely,” chances are you’ll feel that your insecurities are based on truth.

Regardless of their actual qualifications, managers are typically excellent at projecting confidence. Not because they have some elusive skill or particular piece of knowledge that makes them shine like bright beacons of impervious decision-making but in fact because they understand that moving forward is often preferable to standing still.

Accepting that, you might say something wrong or make a decision that won’t lead to optimal results is not about lowering your standards, it’s stopping yourself from remaining paralyzed by fear and giving yourself the agency needed to propel the project forward.

His secrets not revealed

Anxiety is just like pressure, it builds up when nothing is being let out.

I briefly touched on the topic of honesty in a previous post and I believe it plays an even larger role in controlling anxiety. Nothing screams Imposter Syndrome like having an unrelenting voice in your head saying that everything you’ve ever done is terrible while getting an in-depth, in-person peer review by a more experienced developer.

Saying what you think — or what you think the other person is thinking — out loud will only lead to good results. Worst case, they’ll agree with you but will still appreciate the self-assessment. Best case, they’ll tell you you’re flat out wrong and explain why. It’s a strange exercise at first but doing it feels like a weight is instantly lifted off your shoulders.

Managing anxiety by externalizing it is also beneficial for your colleagues. Chances are they’re feeling the same way as you and will either join you in proclaiming their faults or, at the very least, enjoy being in the same boat as someone else.

Be direct when expressing your self-doubts. Take time to reflect if need be but ultimately say what you’re really thinking in a concise manner: “I’m apprehensive about working on this” conveys much more meaning than “this sucks”.

I was great… before

We all underestimate the toll having to constantly learn and adapt to the ever-changing technological landscape takes on us. Sure, you won’t feel it too much when you’re fresh out of school but a few years into it, you’ll find yourself having to set up a decent training schedule for yourself to keep up with the latest bleeding edge technologies.

Problems arise when dealing with unexpected requirements. A new project lands on my lap and uses a framework I don’t know? What the hell is functional programming?

Most will agree that there is no shame in asking for help when you’re the brand new developer in the team but we tend to forget that it’s not being new that makes you say “I don’t get this”, it’s that you’re learning.

To quote the oldest possible reference on the subject:

“The only true wisdom is in knowing you know nothing.”

― Socrates

There is nothing noble in pursuing the stereotype of the old developer who settled on what they knew by their second year in the workforce. We produce work via iterations, so why wouldn’t we follow the same methodology when it comes to what we know? If we’re not batting an eye during the planning phase of our sprints, why should be we ashamed of taking time to learn before we work?

Living on the bare minimum

I’ve found that there are two ways I see my past achievements depending on how much of a fake I feel like at that particular moment: something extraordinary that I’ve accomplished or the bare minimum needed to complete a task.

On the somewhat extraordinary days, when it’s sunny outside, I look back at what I’ve done with much less self-judgment tarnishing my outlook. If you were to ask me what I’ve done in the past week, I would joyously point to the numerous tasks I’ve miraculously completed.

On the much more numerous bare minimum days, when the monster of perpetual mediocrity is looking over my shoulder, I strive to reflect on what I’ve done that was not an abject failure. Finding what the absolutely bare minimum is for a task to feel like an accomplishment can be difficult but it allows us to more accurately see our own worth than when we’re feeling purely mediocre. Maybe you simply lived through a challenge without collapsing? At the very least you got paid while doing it!

Chances are you won’t be getting a medal on the days you’re feeling bleak but how many medals do you really need? After making it through a hard day, remember that you’re making a living out of typing on a keyboard. That’s a major achievement in and of itself.

If you are interested in reading more of my work, take a look at my blog post on How to be honest with yourself as a developer or at the software development section of our blog.