One of the most difficult aspects of learning to code is deciding what to learn. A quick Google search will yield thousands of tutorials on hundreds of technologies. They'll all make a compelling case for why you should learn the technology they're teaching. They are, of course, convincing because learning new things is always beneficial! Except when you want to prioritise and learn the most important material first.

But there is good news! I've compiled a list of tasks that you can safely defer until later in your coding career.

Testing

It is critical to test your code if you want to build scalable and maintainable software. When you have a large codebase that is designed to last for many years and many engineers making frequent changes, the only way to ensure that there are no constant regressions is to add tests.

I like to think of testing as a way of offloading system knowledge. If you start building a large codebase, it will eventually become so complex that it will not fit in your head. At this point, you'll be concerned about making changes to your codebase that inadvertently break some functionality you'd forgotten about. If you had written tests, you would not have needed to remember the state of the entire system because the tests would have saved you. As more engineers are added to the codebase, the situation becomes even more complicated.

However, you probably don't need to learn testing (yet!).

You already have a lot on your plate with building projects that work. Setting up your IDE, working with git, hosting your app somewhere, linting, styling, working with APIs, and so on. That's a lot!

Adding tests is a good habit to develop and something to be aware of before beginning your first software engineering role, but it's not something to be concerned about when learning JavaScript fundamentals or building your first projects.

TypeScript

TypeScript has taken over the frontend world, and for good reason. It helps with a number of things:

Code readability — setting your intention for the type of a variable can make it easier for readers of your code to understand
App stability — If you have ever had your web app break because of cannot read property of undefined, then you know this one!
Catch errors quickly — Even if you have tests that will catch errors like the one mentioned above, there is value in catching the errors immediately, before your tests even run

TypeScript, on the other hand, is another one to add to the "to learn later" list. While many startups are building their apps from the ground up with TypeScript, there are still many great companies that use plain old JavaScript.

One cool feature of TypeScript is that it is becoming increasingly simple to migrate apps to TypeScript file by file. Maybe after you've completed 3-5 projects, you could learn TypeScript by converting one of your apps to TypeScript!

State Management Libraries

My experience with Redux is best described with this graph:

While the concepts can be difficult to grasp, Redux and other state management libraries are useful when developing web apps that require a global, easily accessible state. They are yet another tool that will become more useful as your codebase grows in size and complexity.

Adding state management libraries to your apps early in your coding journey can make an already difficult challenge even more difficult. If you don't understand the code flow in your React apps, adding a state management library on top will be too much.

Having said that, it can be beneficial to listen to podcasts or casually watch videos about state management libraries in order to become acquainted with the jargon and concepts. So that when the time comes to incorporate it into your projects, the task will feel less daunting.

I have heard people say the following:

“If you don’t know you need <insert state management library>, then you don’t need <insert state management library>”

I disagree with this quite strongly for beginners because it’s hard to know if your struggles building your projects can be fixed with tooling or if you are just missing key concepts. It is best to become comfortable with building some frontend apps before venturing off to state management library land.

Code Architecture

While it is good to be always thinking about how you can improve the quality of your code for maintainability, readability, cleanliness: you don’t need to worry about how your code is architected (yet!). I love this common software quote:

“Make it work, make it right, make it fast”

While it felt bad and embarrassing at the time, this was the right move. You can always refactor the code later or just move on to another project where you learn from the mistakes of the previous project. The purpose of that project was not for me to learn how to architect a React project. It was for me to make something that actually works with React.

So what should I learn?

Of course, you should learn HTML, CSS, and JavaScript. But there are some other things that you maybe aren’t sure if they are worth doing or not, and I am here to tell you that they are worth it!

Building projects without a tutorial

While I am generally opposed to tutorials, I recognise that they have their uses. If you're not sure where to begin when starting a new project, watching a tutorial can help you understand the general steps needed to get started. I used a tutorial for one of my projects because I wanted to use (very basic) machine learning for a project but didn't care about learning and understanding the code I was writing.

The harsh reality of learning is that it is painful. If it's too easy, you're probably not learning anything. Building a project from a tutorial gives the impression that you are starting from scratch and learning how to do it, when in reality you are not.

The only way to truly test your end-to-end knowledge of the frontend is to create your own project. The project idea does not have to be interesting to others or even your own; it simply needs to be something that pushes you and that you can complete.

Developing with a team

I know it can be hard (or even scary) to find other developers to work with on a team, but it is worth it!

Working with others on a single code base helps you in many ways:

Learn Git — Sure you can learn git basics on your own, but you haven’t learned git until you have struggled through rebasing your local branch on top of someone else’s changes 😂
Code Reviews — When coding with others, I highly recommend that you review each others’ code. Learning to read others’ code is a great skill to build as well as learning to take constructive criticism 😬
Build Complex Projects — You can build more complex projects when you have multiple people working together. This means that you learn the challenges of complicated software and larger codebases. An added bonus is that your portfolio looks more impressive (better projects + team experience, it’s a win-win!) 🤯

Contributing to Open Source

This is another one that can seem scary, maybe even impossible at first. I assure you that most of the concerns you may have about contributing to open source can be dismissed if you find the right open source project with the right Github issue to work on.

There are plenty of open-source projects out there that have “good first issues”. These are issues with their codebase that are good for someone’s first open-source contribution. The maintainers will often be willing to help you work through the challenges of learning the codebase and maybe even with the git workflow.

Ok, but why should I care about contributing to open source?

Many of the reasons are similar to that of starting a group project:

Learning to read other people’s code is a valuable skill that you will be doing a lot of once you get a job
Learning to take constructive criticism about your code, separating your code from you as a person, will help you to learn and grow
It is fun and motivating. Working with others to add value to a project is exciting and can give you an extra boost of confidence!

Closing Thoughts

Everyone is at a different point in their coding journey, so keep that in mind as you read this (or any other post for that matter). If you've created 3-5 projects on your own, it's probably time to start adding tests, experimenting with TypeScript, and/or refactoring to include a state management library.

The goal is to constantly challenge and push yourself to learn new things without becoming overwhelmed and giving up. If you've been following a lot of tutorials, I'd challenge you to try something new on your own. If you've built some things on your own, I'd challenge you to contribute to open source or find a project partner. And, if you're feeling overwhelmed by the number of tools and technologies to learn, take a step back and try to focus on one thing at a time. Learning is an ongoing process.