10 Things I Wish I Knew When I Was A Junior Developer

Well, we’ve all been junior developers at some point in our careers. Do you happen to remember when you were a junior developer? And what your struggles were?

I do. I remember at one point, doing a uni project in C++. I broke down over the phone to my then-girlfriend, crying in complete defeat. I wanted to hand in the towel with development. I said things like, “I just can’t be a developer!” “It’s just too hard and nothing works!”

I happen to remember most of the mistakes I made as a junior developer; the wrong approaches I took and all of the bad decisions I made.

So, in the interest of helping other junior developers, I’ve compiled a list of things I wish I could tell my younger self.

Plan before coding

This is one of the hardest lessons to learn as a developer—hell, even in life. It will take many repetitions, failures, and lost time before you learn this lesson.

I used to alwasy think of the potential solutions to my problems as I was writing code. This would quite often lead to me rewriting blocks of code due to realising my solution was incorrect or inefficient.

I would often think about the problem in such a closed-minded way that I would forget about edge cases. I wouldn’t think about how the typical user’s experience or how they might ultimately break the code I was writing.

The lesson here is just to plan before you start writing code.

There are so many ways you can force yourself to plan, and most of them don’t require sitting in front of a computer. Here are just a few suggestions and some of the things I like to do:

• Take a walk and picture yourself as a user
• Go prepare a snack and think about the problem
• Draw the solution on a piece of paper

Ultimately, you want to ask yourself: Is there a better way to solve the problem? No, really? Is there?

If you end up saying: “Nope this is the best way!” with 100% confidence, then you’re good to start coding.

Take breaks

This is a lesson that I still fail, even to date. I often catch myself thinking: “Okay, well just push through this block and code for another hour. Then take the rest of the night off.” But does it ever happen? Nope.

Without taking breaks, I end up making more mistakes. And it takes longer to write the solutions than it would if I had just taken a 20-minute break. These breaks reset my mind and, more importantly, give my fingers a rest from typing on a keyboard.

The biggest culprit for us as developers not taking breaks is ourselves. We’re quite often promising to do a task “right after this one”. That mentality locks you into working straight away after that task, and not be able to take a break. If that code ends up taking you longer than expected, then you’ll go even longer without a break.

The best way to force yourself to take breaks is to use the Pomodoro Technique. Work for 25 minutes, then take a five-minute break—ultimately ending up as 10 minutes of breaks in an hour block.

Stay calm

Programming can be stressful. Especially when working under deadlines—whether set by you or your boss. Whether you notice it or not, your body definitely does.

I know this is something that every developer can relate to: estimating a task to take two hours. However, due to some annoying bug that's completely not your fault, it ends up taking over two days. During those two days, it seems like you are close and so you pressure yourself to get it done.

It doesn't help, when like in the previous point, we're context-switching midway or promising to do work right after the task we're currently on. You're most certainly not going to remain calm if you end up spending longer than anticipated on the current task, and the task you promised is now being delayed 🤦

Back to the point: take breaks. They help declutter your brain, realign you with your daily goals (see the point below) and keep you calm. 💪

Plan your day

This is the one thing I still do not do as well as I possibly could. 📓 ✍️

I can not stress this enough. PLAN YOUR DAY. This will not only help tremendously in life, but 100% will in dev. And, it takes no more than 10 minutes if you do it effectively and efficiently.

Here are my hot tips for planning your day:

• Be truthful to yourself about what you can achieve.
• Have two lists: one for what needs to get done and one for what would be good if it gets done.
  • You can switch between the two, where hopefully the ones on the good if it gets done list are more fun and engaging for yourself.
    • And one less thing to do tomorrow. 😉
• Add a variety of things you enjoy and things you don't enjoy.
• Do the things you don't enjoy first up in the morning.

If you have trouble creating tasks on your plan for the day, try jotting down notes in a more casual format and then create the tasks from there.

Engage in the community

I cannot stress how important this is for every junior developer out there.

This is very important. Pay attention to this one.

I'm sorry to break it to you, but you are not smarter than every other developer, and most certainly not smarter than senior developers. The first step to growing and becoming a better version of yourself is to admit this and engage in your communities.

Not only are these places an absolute wealth of content, but they have also just gained so much incredible knowledge throughout the years and have been through some real testing periods and learnt some very valuable lessons that they're usually happy to share.

I recommend joining Twitter and following a few developers!

Code is the journey, not the destination

As software developers, we tend to think of our code as art, the final masterpiece, something that needs to be perfected, admired, and so lean and clean. 💪 But that's just not the case.👇 Our code is simply a journey to the destination.

The destination 🇻🇦 is the end of the project, and a culmination of all of our code put together.

But that is not our job as developers. Our job is not to write exceptionally clean and lean code, but instead, our job is to write good quality code that solves problems.

This means: write clean, readable, expandable code.

Know what's significant, and what isn't

This is something I see as the head of development a lot. Developers have trouble separating the significant from the insignificant. They might spend hours, days, or weeks, just to refactor code so it gets the job done in two lines of code versus five.

But you need to understand that getting a solution done in two lines of code, instead of five is not by any means a significant task at hand. This is a task that you can by all means park and come back to at the end of the project if all other deadlines are met.

💯: understand the difference between significant tasks and insignificant ones.

The significant tasks are almost always the 20% effort that achieves the 80% reward. (80/20 principle)

All bugs, regardless of how scary they are, are always eventually solved

This one hits close to home. I cannot number how many times throughout my career that I have had a very scary bug reported to me and taken it as a life-or-death situation, or struggled to understand how it was possible to fix the bug.

I'd like to tell my junior self that in the eight years I've been a developer now, there has never been a bug that I didn't eventually solve. Patience and a sense of calm has always prevailed against those bugs.

This applies to all developers, and not just me. I've seen it hundreds of times throughout my career. As problems arise that seem impossible to solve, developers will always unite to fix those problems in the coming days. So, remember that!

Personal tools + scripts

One of the things that contributes the most to my productivity and efficiency is, without a shadow of a doubt, the tools and scripts I've created over the years. I've even shared some of these with my colleagues and staff to benefit them as well.

This is something that we, as developers, should appreciate about our careers. We can honestly create tools to make lives easier—including our own.

Not only does it help make your life easier, but it also is a great starting point for a side project.

Invest in a good chair

This is one of the most important pieces of advice in this post and such a simple one.

Ask yourself this: when was the last time you really invested in a great pillow, that you spend hundreds of dollars on? Never. Why not? You spend eight plus hours on it every day, and the results of that task can heavily impact your day.

Likewise, for a chair. We spend eight plus hours on it every day sitting down in front of our computers, writing code as developers. It paves the way for the rest of our lives as it could potentially be damaging our posture and muscles.

A good chair is very expensive, but the one regret I have is not investing a significant amount of money in a great ergonomic chair. It helps you stay comfortable and focused.🪑

The end

That's it. 🔥 A collection of some of my wisdom, gathered over the last eight years of being a developer.

Sadly, people are inherently stubborn, like me. So, do me a favour. Take at least one of the points out of this post and apply it to your life and mindset.

I'm curious though, what advice would you have for your junior self?

I'm excited to hear what you all have to share over on my Twitter.

Until next post! 🚀