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!
Top comments (10)
"Remember that code is a just a tool you use to get your job done"
Someone else said the above in the comments. They are absolutely correct. It took me a long time to realize this. I am all the better for it now.
You also mentioned feeling like you are never ready and then not applying for those jobs. I am currently battling that. Trying to get ready enough to apply for a particular job but always feeling like I am not. Thank you for such a beautiful piece.
Wow thank you so much.
I have now been at my first dev job for a year and I still feel like i'm not ready most days. I'm not sure that feeling ever goes away. But then I get a task and I either make it work, or I struggle - and both are fine. It's always going to be that way throughout your career.
Learning to navigate those emotions is one of the more important skills I've been working on.
very great read with a lot of solid points.
I've been getting burned out more times then i'd like to admit, sometimes to the point where i give up learning entirely haha but I've always managed to come back to it, These days, I take a chunk of material at a time and set up some mental breaks every other day.
After my bootcamp's final project, I got burned out so badly I didn't participate in the demo day and didn't touch code for months.
I was concinved I hated it. But then a challenge kind of fell into my lap and I was given the opportunity to do a challenge for a possible internship. I wasn't ready at all, but I figured I had nothing to lose.
It was in React, what I primarly did my final project in, and what I was never strong at. I told the employer as much, and he gave me an extra week to watch tutorials and then attempt the challenge.
I built out the project but it was full of errors. Components were duplicating when publishing comments, but I made it.
I did a walkthrough of the challenge and explained the parts that didn't work, and what was wrong with them (not how to fix them). I ended up getting the internship with the comment that a week is not enough time to grasp a large framework like React but my ability to pick up stuff quickly and understand what was going wrong was what excited them.
TLDR: Burn out is real and even more so is the desire to give up completely. But sometimes that self-destructive voice is just that - self-destructive.
Very encouraging! Thanks for sharing this experience. I'm still going through my full-stack course online. I've learned to just take it a little at a time.
Try to solve your problems in 6 hours per day. Additional 1 hour you can think of a better way you did today and 1 hour to read something in your field or other code.
Working out is the best brain boost you can get. Go outside and walk.
Best advice I can give :)
I used to tell myself I would stop once I solved the error/bug or made the particular chunk work. I would keep going until I would work myself into tears and cry to my husband that I just didn't understand what I was doing at all and I wasn't built for this.
I would walk away. When I came back the next time, the problem was almost always solved way easier, sometimes within minutes.
Sometimes we need to shift your lens entirely away for things to make sense.
Good topic and insightful to read.
Absolutely!
"Preposterously convoluted code is harrowing and onerous leaving your colleagues irate and wanting to throttle you (probably like you now wanna do to me)" LOL I was so confused until I kept reading