5 Simple Tips for Junior Software Developers
Handy hints that will serve you well in your programming journey
It’s easy to get overwhelmed when you’re learning to code. The road to finding your first job and then growing out of it is full of obstacles and dead ends. Here are some tricks that will help you navigate the programming jungle, find a job, and develop as a junior programmer.
Go Deeper, Not Broader
You may think a junior developer needs to know lots of languages and technologies. I don’t blame you. These are some of the requirements I found lately on job advertisements:
- React Native
That’s crazy. You don’t need to know all of that to find a job. Actually, you can’t know all of that at the beginning of your career.
Job requirements are at best “good to have” and at worst a wishlist.
Typically, the process of creating a job advertisement consists of a senior developer listing everything he knows and muttering that it’s useful. Then the HR manager makes that list a prerequisite.
In a real job, nobody expects a junior developer to have in-depth knowledge of many programming subjects. And if someone does expect that, they shouldn’t be allowed near the recruitment process or be working with juniors.
What you need to know
The most common mistake junior front-end developers make is trying to learn several frameworks at the same time. Trying to bite off more than they can chew leaves them confused and discouraged.
This approach will benefit you in the short-run (it’s easier to find a job when you’re good at something) and in the long term (if you understand core concepts deeply, you’ll learn new things more rapidly in the future). And employers know that.
Look Under the Hood
Almost every problem you encounter has already been solved. Thousands of libraries are waiting for you to use them in projects. Take advantage of that, as they are often well-tested, take care of tricky edge cases, and create abstractions to help you code.
Libraries are useful to accelerate your programming, but they’re also a great learning tool. Looking at the code written by accomplished developers will open your eyes to new ideas and ways to approach programming. I’ve learned tons of tricks just by looking at git repositories of popular libraries.
What’s even better, you’ll often discover that core concepts behind many libraries are simple. As a junior developer, I frequently used a library to create tabs. When I finally decided to take a peek at the code, it turned out that it was pretty simple to follow. So when I needed to tweak tabs behavior in the project, I could do it in a few minutes.
As a bonus exercise, you can try to recreate the basic capabilities of a library without looking at its code. Later, compare your code with the original and try to understand the decisions made by the library’s author.
Embrace the Failure
The web is full of promises: Learning to code is easy. You just need to pay us $2,000 and take 200 hours of online classes. In two months, you’ll become a software developer!
No, it’s not. And no, you won’t.
Programming is hard, and you’ll get confused time and time again. Some bugs will take days to fix. Unraveling some concepts can take weeks. You need to be ready for countless frustrations.
It may sound gloomy, but in reality, failure is OK. If you’re failing, it means you’re trying to do new and challenging things. The only way to grow is to extend beyond your limits. Failure is an essential part of the process. Befriend it, and you’ll see the benefits rapidly.
Also, there is a silver lining. On many occasions, you’ll look at your old code and think, “How could I have been so stupid?” This feeling is a testament to the progress you’ve made, and it’s an excellent moment to take some pride in your development.
Focus on the Process
Be aware of the perils of the learning checklist. It’s good to have priorities. You need to define what you need to learn. But setting goals that are too rigid can easily backfire.
Imagine you decided to learn closures this week and higher-order functions next week. You learn a lot, but after two weeks, you discover that you don’t understand either subject. You feel like a failure and begin to wonder if you’ll ever become good enough to be a programmer. In reality, though, you were too ambitious with your goals.
When you start, you don’t know what’s difficult and what’s not. Additionally, people vary in their ability to grasp different subjects. Some things will be harder for you than others, and it’s OK. You don’t have control over that, so don’t get discouraged.
When you push yourself too hard, you set yourself up for failure.
Instead of setting learning goals, you should focus on the process. For example, decide to learn for one hour a day. It’s a better approach because you have greater control over your process than over your outcomes. So every day when you learn, it’s a success. And if you’re learning every day, the results are sure to follow.
I’m sure you’re not taking enough notes. We all overestimate our ability to remember things. You’ll have to solve these same problems all over again. If you don’t save solutions, you’ll have to reinvent them.
So don’t trust your memory and document everything — the ways you solved problems, useful algorithms and functions, and good learning materials. You’ll need them along the way, so create a personal library.
It’s easy to get lost in the sea of hyperlinks and other resources, so take some time to pick the optimal way to keep your notes. I use the app that allows you to add tags to resources and find them easily, but stick to whatever works for you.