Dealing with ‘Imposter Syndrome’

Gordon Smith
OneHub | Product Engineering
5 min readApr 2, 2019

This year will mark my 5 year anniversary as a developer. Before then I had moved between technical roles and positions, always knowing enough to be useful but never feeling I had a grasp of all the solid fundamentals.

In much the same way as many developers, I didn’t study Computer Science at university, my introduction to software and code in general came many years earlier, copying code I had found online and trying to piece together something useful from speaking on various forums and in chat rooms — tinkering with games trying to bend the rules or writing bots for IRC so I could carry out a list of tasks from a single command.

Admittedly, the “usefulness” of anything I would put together was debatable, but just the experience of problem solving using only a few lines of code, no matter how big or small the problem was invaluable.

I discovered as I got older and the challenges became more and more complex, writing code was only one small component of software development.

Constantly surrounded by terms and ideas I couldn’t really grasp whilst everyone around me seemed quite comfortable — I often turned to Google, which in turn led me to Stack Overflow, which introduced more terms I didn’t understand, more concepts that left me scratching my head. I started simply copying and pasting code and then patiently waiting to see if it would run.

On reflection, I think I probably abandoned 90% of projects I started that had an error I didn’t understand. In hindsight most would have been a simple fix had I understood the fundamentals, but none the less I took these struggles as a sign I didn’t belong in engineering.

“Focus on being good at one thing…”

I considered leaving the field many times, until a conversation with a senior engineer left a lasting impression on me. They told me the were impressed by how often I asked questions and that striving to learn was a quality I should keep - That I shouldn’t walk away from engineering just yet, instead try to understand the fundamentals and focus on being good at one thing and not worry about being great at everything.

Now, as I have matured and surrounded myself with other engineers from various fields I have come to realise the very nature of software engineering is so fast paced, changes happen so quickly you will often find yourself up against things you do not know, this feeling is normal.

It is in fact one of the things that makes writing code so interesting.

I haven’t put together this list as a “be all, end all, 100% guaranteed” way to solve imposter syndrome, rather I am sharing what worked for me in the hope it can help someone else feeling out of place.

  • Pick a skill and practice it
    It is easy to quickly become overwhelmed by the amount of things to learn and the directions you can take as an engineer. I have written code for the web, servers, desktop applications, mobiles, command line tools, networking tools and various scripts for tying aspects of them all together.
    Never fully understanding everything about each of those platforms only contributed to that feeling of inadequacy. Eventually I picked a field and focused on it, things I would always google became second nature because I decided “I don’t want to google this every single time I need to do it”.
    Now I’m excited by the challenge of a project, rather than filled with dread wondering “How is that even going to be possible…”
  • Ask questions, lots of questions
    If you feel like you may be the dumbest person in the room, embrace it. Here at Benefex I am lucky enough to be surrounded by smart people, solving challenging problems everyday. So be curious, ask questions and don’t be afraid to say you don’t understand. If you are not lucky enough to have a team around you that is easily accessible, search for meet-ups, online communities, read blogs and attend hack days. Immerse yourself in the culture and those connections will start forming.
    Eventually asking questions will become second nature and whilst your pride may initially take a dent, you will understand this is how you are going to learn the most.
  • Understand how your code works
    At times you may inherit someone else’s codebase or take on a project with little (or no…) documentation. It’s easy to fall into the habit of copying and pasting code or adopting patterns that are just “how that thing works”. This may accomplish the task at hand, but you haven’t learned from the experience, instead you have simply taken the thoughts and decisions made by the original author and blanket applied them to a new problem. That is a slippery slope. Take the time to understand the goal and how you can apply your code.
  • Accept you do not know what you do not know
    Being aware of what you do and do not know is the first step in combating self doubt. It is important to remind yourself, you do not need to know everything, but rather just need to know where and how you can find out. Even experienced engineers have their knowledge gaps and this is just the nature of working in a field that is constantly in flux.
  • Pair Program
    I cannot give this enough weight, if you have the opportunity then take it. I feel pair programming is massively underrated as a learning tool. Sitting down and actively discussing the code you write forces you to make conscious decisions about the direction you take. A simple 30 second discussion about why X is required to complete Y can open your eyes to a whole other perspective. I couldn’t begin to tell you how many concepts have become so much clearer to me after sitting down with someone that understood them and actually writing code together.

That’s all folks!

I still ask lots of questions and I still find myself in conversations where concepts are new and confusing, but by following the steps above and making the effort to learn as I go, I find more and more I am less concerned about not knowing something and more excited by the opportunity to learn and expand my skill set.

--

--