Xandr-Tech
Published in

Xandr-Tech

Photo by Caleb Jones on Unsplash

Overcoming fear and succeeding as a new software engineer

  • 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.
  • 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.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store