Overcoming fear and succeeding as a new software engineer
Being a software engineer is scary. We are surrounded by some of the world’s most talented, intelligent minds, solving complex problems with constantly evolving technology. As a new engineer, it’s easy to get overwhelmed by the intimidating skills of our brilliant peers and the ever-changing technology we are expected to master.
I started my career as a professional software developer right before I turned 30. I am self-taught, mostly learning to code through online tutorials, making video games, and a scattered amount of introductory computer science courses. My coding background left me feeling inadequate, constantly behind my peers, and thinking I would never achieve the status of being a real software engineer. Thankfully, I didn’t let that stop me.
In this article, I hope to offer insights about overcoming hurdles as a new software engineer and practical solutions to fighting the fear of never being good enough. To do this, let’s start by looking at a few problems commonly seen in our field.
Imposter Syndrome
Most of us have heard of imposter syndrome. You know the feeling: somehow, despite all your successes, your portfolio of past work, and getting through an intense set of interviews, you are stuck feeling like you don’t belong — that you aren’t skilled enough to be a real developer. I often find myself doubting my ability to accomplish a task, especially when I’m unfamiliar with the technology or an aspect of a codebase. However, time and time again throughout my career, facing these challenges head-on has helped me overcome these feelings of self-doubt, and I remind myself of this whenever these feelings creep back into my mind.
Imposter syndrome plagues even the most talented engineers, and it’s understandable. Our career path forces us to constantly learn new things; for many of us, this can feel like we are forever trapped in beginner-land. The fact is, however, that this is what we signed up for. We are here because we love solving problems and we love learning new technology. If we embrace this reality, we can dispel the myth of inadequacy that imposter syndrome makes us believe, and realize the beginner’s mind is an asset that will help us overcome the many challenges we regularly face in our profession.
The Dunning-Kruger Effect
Imposter Syndrome can be explained, in part, by the Dunning-Kruger effect — a cognitive bias where an inexperienced person may perceive their ability to be higher than their performance, while an experienced person perceives their ability to be lower than it is. Another way of putting it: the less you know about something, the more you think you know, and the more you know about something, the less you feel you know. Sound familiar? It is impossible for a software engineer to know everything there is to know about a given topic. This can make us feel inadequate; that there is so much to know that we really don’t know much at all! Many of us feel imposter syndrome because we are experienced enough to know—in the grand scheme of software development—we don’t know that much, and that’s ok! So, how do we combat imposter syndrome and accept that our place on the Dunning-Kruger curve is actually a good thing? Start with your ABCs.
ABC — Always Be Coding
The best way to overcome imposter syndrome is trivial: write code as often as you can. Our coding brain is like a muscle, and we must use it often to help it grow stronger. This can sometimes be a challenge due to family circumstances, mental health, or a variety of other factors. The good news is if you have a job writing code already, you can gain confidence and experience just by going to work and focusing on your tasks. For a new engineer, this might not feel like enough, so it’s important to prioritize learning outside of work hours if you can. Don’t just do work after hours for the sake of it, though, unless you are still learning the fundamentals and need the extra time.
Instead, spend some time doing something fun with code. Create a website and experiment with CSS you wouldn’t use in business-grade software, recreate Wordle with your own twist, or use your raspberry pi for home automation. I enjoy game development, so I often tinker with new game engines or participate in game jams. I also have a large backlog of web development Udemy courses that are applicable to work, and I try to always have one of those courses in progress. The key is to flex your coding muscles regularly, solving unique problems that will help you learn to overcome new challenges and build your confidence.
Learn how to read code
While it may not feel as productive as putting fingers on keys, being able to read and comprehend code is arguably more important than writing it. As a software engineer, you must be able to quickly understand code you didn’t write, whether it is reading the documentation for your framework of choice, reviewing a teammate’s pull request (PR), or extending an existing codebase. Reading code is not like reading a book; it requires you to jump around the codebase to understand the full story, keeping many different ideas in your head at once. As you get better at reading code, you’ll start to see patterns that will help you discern what is important to investigate and what can be left for later. You will come to know the cost of writing confusing code and will start fully thinking through problems, breaking them down into easily digestible chunks which will result in writing better, cleaner, easier-to-understand code.
How do you get better at reading code?
- Always have a software book you are reading through. Some good starter books are Clean Code by Robert C. Martin, The Pragmatic Programmer by David Thomas and Andrew Hunt, and The Missing README by Chris Riccomini and Dmitriy Ryaboy.
- Find a blogger in your tech stack that you like and read their posts regularly. One of my favorites is Scott Hanselman’s blog.
- Pull down an open-source library and get it running locally, set some breakpoints, and investigate the flow of execution. Not sure what open-source library to look at? Check out this list of great libraries by topic on GitHub and choose something that interests you.
- Spend solid, focused time reviewing your team’s PRs, especially those coming from more experienced engineers on your team. Don’t just hit the approve button after a few minutes of scanning through the PR; dedicate some quality time to fully understand the change and ask clarifying questions along the way. You’ll learn a ton doing this.
- Periodically go back and read code that you wrote. See if you can understand it and think through how you could write it better now.
There are many ways to become better at reading code, and just like writing it, the more you practice the better you’ll become.
On-the-job tips:
- Say yes, often — One of the biggest boons to my career development has been volunteering often for a variety of work, especially if it relates to something I don’t know much about. At my first development job, we had a small development team that supported over a hundred applications, many of which were old and hadn’t been touched by any current employee. When we received a customer request to modify one of these applications, I would often volunteer to handle these requests because no one else knew about these programs and it gave me a chance to learn something new and add value to our team. Eventually, I gained a ton of domain knowledge on applications we weren’t very familiar with. I was able to share this with the team and put myself in a position where I was the go-to developer for many applications.
While it can be scary attempting to deliver on a ticket or project you have little experience with, they are great learning opportunities. You may have to interact with people you don’t know, expanding your network within the company and building connections that will make the next time easier. You are also put in a position where you get to become the subject matter expert on something, which makes you valuable to the team and able to help others who haven’t worked on the thing you just delivered. This is a great technique to squash imposter syndrome quickly, forcing you to overcome obstacles regularly and building your confidence by giving you considerable experience. - Failing is ok — It never feels good to fail, but it happens to all of us, and it is expected early in our careers. One of the first applications I wrote by myself for work quickly went from a simple application with a clear purpose to one that was so generic that it was hard to enhance, difficult to understand, and ultimately a failure. In retrospect, this was due to unclear requirements and not understanding how to prioritize customer and peer input, so I tried to do it all. While this was a frustrating experience, it was a great learning moment that helped me see warning signs in the future when a project has drifted out of scope.
Failing is often one of the greatest ways to learn. Ever break production? What a terrifying experience, right? But you are forced to learn how to fix the issue on the fly, and that will teach you how to not do it the next time. Failure exposes weaknesses, not just for you but potentially your teammates and their processes. When you broke production, what caused the issue? Was it something in your code, or was it really a safety mechanism in the release process that missed the underlying issue (which you have now exposed to be fixed and prevented from happening again)? Fail fast, fail hard. It’s all part of the learning process, and the more you do it the more resilient you (and your team) will become. - It’s ok not to know — It can be tempting to pretend to know things you don’t know. You don’t want to look like the only person who doesn’t understand something. However, this can lead to clarity problems, resulting in work that doesn’t meet the requirements. It is far better to ask clarifying questions early in the process to make sure you know what you need to deliver than to wait until it’s too late, forcing you to have a difficult conversation about not delivering what was promised. It is ok to not know something. We can’t know everything, and if you don’t know something, someone else likely doesn’t either. Asking questions is also a very important component of designing resilient software. You might be scared to ask, but clarifying your confusion could expose an issue with the software and lead to a better product overall, so please ask away!
- Try before you ask for help — While asking questions is certainly encouraged, don’t presume you can’t figure something out before you’ve tried your best. Struggling through a problem is a valuable experience that can teach you troubleshooting skills and allow you to process how something works. Senior developers will often expect you to have tried everything you could before coming to them with questions, too. If you are truly stuck, reach out and pair with your teammates, but give it your earnest best attempt first. You will be surprised how often you prove to yourself that you can solve a problem you didn’t think you could, which is another great way to stave off imposter syndrome.
- Don’t forget balance, and avoid burnout — Software engineering isn’t just a job — it’s a way of life. You will have to learn new things often throughout your career, which can easily lead to overwork. Prioritize your work-life balance: take your vacation time, go outside, move your body, get a good night’s sleep, and give your brain a rest!
Before I got a job as a developer, I was working full time, then coming home and spending an additional 15–20 hours per week developing a video game. I was struggling to break into the software development field, so I thought the best way I could gain enough experience to get a job was to ship a full product from start to finish. The result of this was 6 months spent on a game I never finished and burned myself out on. I did gain experience that was crucial to me finally landing a software job, but it sunk my mental health and it took me almost a year before I was excited about coding again.
It is so easy, especially when working from home, to sit at your desk all day for work and then go right back to your desk after work. Try to avoid this as much as possible. While it may seem like using every spare moment of your time to squeeze in a little bit of coding time will help improve your skills and boost your productivity, letting your brain get some distance will clear your mind and allow you to use your time more efficiently when you’re on the clock. Your happiness at your job will depend, to some extent, on your ability to avoid burnout, and keeping this in mind will help pave the way for a long and happy coding career.
Imposter syndrome is difficult to overcome, and it can crop up occasionally even if you have defeated it before. When it does come up, reflect on your past successes and remind yourself that you are here for a reason. If you are early in your career, focus on refining your craft in a balanced and sustainable way, and realize that your commitment to improving every day will help you advance through a successful career. I hope these tips help you, and I’m glad we’re here together.
