How To: Avoid Common Mistakes Made By Junior Developers

This post was originally written by me for CodeCast.

Whether you're just beginning your career, or are switching fields, entering the workforce as a junior is daunting. It’s expected that you know less than your peers and that you will make some mistakes. On one hand, that’s slightly relieving. On the other, it feels slightly like always waiting for the shoe to drop, wondering when you will have made too many mistakes. Anyone passionate about their work cares greatly about performing well. However, this tends to create extra pressure to perform to an unrealistic standard.

I took my very first fundamental coding course in February of 2020. I got hired here at CodeCast for an internship that same November. I went from knowing almost nothing to being hired within ten months. Entering into this industry, it is common for people to offer advice on how to overcome Imposter Syndrome. While Imposter Syndrome is a topic all of its own and is definitely not limited to only juniors, it brings forth the common feeling that juniors are constantly struggling to find their footing and place within the industry.

An important thing to remember, and something I really want to emphasize in this post, is that when you are a junior developer, this is expected. Now, I’m not saying that you get a free pass, or get to screw up more than needed. However, it is unrealistic for anyone who is entering the development world to move forward without making mistakes. That being said, there are some mistakes that a lot of junior developers tend to make over and over again. In this post, I will be going through some of the most common mistakes that junior developers tend to make, and how to (best) avoid them.

Not Knowing When to Ask for Help

This was, and often still is, one of the largest problems I faced when beginning my journey here at CodeCast. I was extremely concerned about delivering something in what I deemed to be a reasonable amount of time that I wouldn’t let myself get stuck. I would spend a short amount of time trying to problem solve on my own before reaching out to ask for help. More often than not, I would end up finding the solution to my problem before the person even responded to me.

My boss is incredibly patient and passionate about learning (I mean, that’s kinda our whole thing here at CodeCast). This meant that he would patiently remind me over and over to take the time to be stuck. He emphasized that being stuck and coming to a solution to my own, would help me learn the concept far better than if he just answered my question. And of course, he is totally right. Some of the things that made me go absolutely insane thinking I would never figure them out are some of the things I understand the best now because I took the time to try every possible option and figure it out the best that I could on my own. When I finally did get it, it was so clear as to why it worked over everything else I tried.

Now all of this is not to say that you should never ask for help. You’re going to face issues that you need clarification on, or perhaps you’ve been stuck on something for a length of time and your team needs to move forward with the project. The skill here is learning when to ask for help. It will depend entirely on your job and specific circumstances, but I know here at CodeCast, they would rather me spend a bit more time being ‘stuck’ and figuring it out on my own.

Not Knowing What To Learn

This is a complicated topic because developers truly never stop learning. There are always changes and updates to languages currently in our repertoire. On top of that, we learn dependencies, frameworks, and whatever else we need as we begin working on a specific project. As a junior developer, figuring out what languages to learn to make you hireable can be extremely challenging. There are so many different languages and frameworks out there, and job posts tend to list 10-15 things just in the description. It can feel incredibly overwhelming. Realistically, no one hiring you expects you to be incredibly proficient in 15 different languages, libraries, or frameworks. It’s just not realistic.

One of the traps we junior developers can fall into is concerning ourselves with keeping up to date and trying to learn all the popular languages because we think it’s what will get us hired. While it’s important to know what the current and most used languages are, it’s not valuable for you to know a little about a lot.

Do some research into the area you desire to work in and learn what the most popular languages and stacks are. Learn what will help you to get a job doing what you want, and go from there. Even then, it’s unlikely that you’ll look at a job post and meet most of the requirements. If you’re proficient in a language like JavaScript, picking up something like React is a lot easier. Learn the basics and expand your knowledge where it feels right for you, and understand that as a developer, jobs expect that you will need to learn something on the job. Often they’ll decide to change pieces of their stack as time goes on, meaning the entire team needs to adjust and change. We’re all learning, we just need to be practical and realistic in what we are learning.

Only Looking Through Your Own Lens

One of the biggest facets of humanity as a whole is that we have the ability to empathize. We can imagine what it would be like to experience something we have never experienced ourselves. While we’re (probably) not specifically needing to relate to others' emotional states while developing, being able to look at things outside your own perspective is incredibly helpful. Once you know and understand something, it’s easy to get caught up in only viewing things from the perspective of a developer. Learning to try to look at things from a different point of view will help you massively, as the better you can understand a general user or your client, for example, the better your work will be.

In addition to this, being able to visualize things from another co-workers point of view will help you deal better with criticism. The entire next section is on taking criticism, so we will definitely dive deeper into that. However, for now, know it’s easier to understand where the constructive criticism is coming from if you try to envision how your work appeared to the person who gave the feedback.

Long story short, learning to view things outside of your own lens will help you become a well-rounded developer. You don’t want to make decisions in your career that only make sense or look good to you. The better you can understand others' needs, the better your work will be.

Taking Criticism Poorly or Too Personally

Learning how to take criticism well is difficult for everyone, no matter what you do. Hearing negative feedback affects our emotions, no matter how much we try to pretend it doesn’t. No one likes hearing the thing they spent x amount of time working on wasn’t as good as they thought it was. However, learning how to take criticism and feedback and use it for your benefit is one of the best ways to become a better developer.

For the most part, people don’t criticize you just to hurt your feelings. Of course, there are exceptions to that rule, as we’ve all had co-workers or bosses who have seemingly thrived on micromanaging and controlling. But for the sake of this, our focus is on the people who provide you criticism and feedback because they want you to do better. While learning to look outside your own scope can make the blow of criticism feel softer and make more sense, we still need to know how to navigate the world of feedback.

Firstly, criticism and feedback are, for the most part, subjective. If you are truly passionate about what you submitted being the best version possible, you are allowed to say that and respond accordingly (and appropriately). But usually, everyone's work can always be improved upon with a second set of eyes, no matter how much experience we have under our belt. The best thing you can do for your work long-term is learning to work with this feedback.

This is especially true if you regularly receive similar feedback. If someone is regularly providing feedback you've heard before, take a moment to evaluate what those pieces of work had in common. Did you write it all in the same way? How could you have done it differently to avoid the problem? If you’re unsure, ask the person providing feedback for some information on what would have made it so that they didn’t provide that criticism.

Regardless of what you’re handed as far as criticism, as you navigate the professional world, and especially when you’re just entering into a new field as a junior, you need to be able to accept and hear criticism professionally and use it for your advantage. Instead of taking it to heart or hearing it as a failure, take it as a piece of friendly advice or a tool you can use to evaluate your work going forward. Showing your team that you’re open to advice makes it so that you’re approachable and easy to work with, and also shows that you’re very willing to grow and change wherever you need to.

There is a myriad of mistakes you will make as a junior developer. The best thing you can do for yourself is to recognize them, accept them, and move forward. I personally have struggled with every single thing on this list, and some days, have to remind myself of some of the things that I just wrote down.

Keep your head up and do the best you can! Others will notice. Keep an eye out for another part coming soon!

Checkout more of my work here:

CodeCast Tutorials
Blogs
Twitter