It’s been a year since I graduated from my Bootcamp and about 8 months of working at CodeCast. While I’m still a junior developer through and through, I’ve started to get more comfortable with where I am at. Looking back I can see a lot of things I wish I had done differently, which is great, to be honest. Being able to recognize that I’ve changed and grown as a developer is fantastic.

I previously wrote a post about some of the common mistakes that junior developers make. Since then, I’ve come up with a new list of mistakes I see myself and others making, so I thought it was the perfect time to write a second part. Without further ado, let’s get into it!

Wait… What’s Going On?

When you start developing, it’s very easy to just assign super quick names to things like functions and variables so you can focus your attention on understanding and building out the logic. We all want to focus on the difficult aspects, and sometimes, coming up with a good name for something can take some mental energy. However, it’s important to overcome this bad habit for several reasons.

Firstly, even if you’re the only person who is ever going to touch your code, you’d be surprised at how quickly you can forget what you’ve written. Sometimes I’ll write an entire chunk of code and the next day look at it and be like ...hold on, I have NO idea how this works. It happens! But if you have a bunch of functions and variables working together named well, it makes figuring out what the code is doing again a lot easier.

Secondly, even if you’re the only one working on your code now, that’s not always going to be the case. You’ll have your code reviewed, work on existing codebases, or move on and leave your codebase to a brand new developer. Anyone who has ever picked up someone else’s code knows how incredibly different two people can write something that achieves the exact same thing. Wrapping your head around someone else’s thinking style is difficult enough without having random variables like a and secondOne thrown into the mix.

Even if you don’t think it affects you now, it’ll come back to haunt you later on, and it’s best to get in the practice of assigning clear and informative names sooner rather than later.

Unnecessarily Difficult

Preposterously convoluted code is harrowing and onerous leaving your colleagues irate and wanting to throttle you (probably like you now wanna do to me).

I could have just said “unnecessarily difficult code will make everyone that works with you want to strangle you” and you would have understood it perfectly. Being complicated for the sake of being complicated is an easy trap to fall in. You learn some new methods and practices and want to write them into your code so you don’t forget them.

Knowing how to use something is important, but knowing and appreciating the basics is even more important. Returning back to our first point, at some point you’ll be writing code that other people have to read. It’s easy for juniors to want to write impressive code to show off their skills. They want to make it obvious to their peers that they’re capable. But if you’re consistently the person getting comments on their PR’s about re-writing chunks of your code to be simpler and clearer, consider that more often than not, simpler is simply better.

Learn and then ...Learn More?

One of the hardest things to grasp when you’re entering the world of coding is that there will never be a day where you suddenly feel like you are ‘ready’. Or, at least there very much wasn’t for me. Students consistently feel like they need to learn more and more stuff before they can enter the job market. This is especially true in the programming world because essentially, your job will always require learning - it’s not a skill set you can cap out on.

Take a look at any single developer job listing on LinkedIn and you’ll see a list of skills longer than your grocery receipt. It feels overwhelming and it feels impossible to know everything you’ll need to know.

So what do you do? You apply anyway. You’ll never check every single box on those lists as a junior developer. You’ll likely not even check them as a senior. The easiest way to learn and increase your skills is to do so while working. Those ‘ah ha’ moments happen after being stuck on a ticket or feature for a while.

If you’re sitting there feeling like you’ve been learning to code forever and you’ll never be ‘ready’, chances are, you never will. You just have to become comfortable with feeling uncomfortable and put yourself out there.

Not sure where to learn? Check out CodeCast to watch some of our tutorials, like this one on React/Redux!

Eat. Sleep. Code. Live Your Life.

There are a lot of trends with junior developers that are based around coding every spare second you have. The "Eat Sleep Code Repeat" mantra (as seen above) is a popular one. While consistency is important, so is taking care of yourself. Burning out quickly or giving yourself no time for yourself isn’t helping yourself or anyone else. You have to make sure you’re taking care of yourself and not focusing on delivering 110% all the time.

Burnout is a very real thing and needs to be taken seriously. Don’t push yourself beyond your capabilities every possible second. As a junior developer, do you often have to work harder to prove yourself? Absolutely. But don’t do it at the cost of sacrificing yourself and your wellbeing. Elsa has previously written a blog post about achieving a healthy work-life balance, and it’s definitely a skill to learn in itself.

All in all, as I said in my previous blog, juniors are expected to make mistakes. Don’t beat yourself up when you make them. Recognize them, actively work on being better and one day you’ll notice those mistakes start happening less and less.

For more of my work, check me out on Twitter, LinkedIn, CodeCast, & Medium!