If you’re further along in your journey, though, here’s what you can do next.
1. Get functional
At the very least, you should understand the following concepts:
2. Keep up with the latest specs
First off, you better not be using
var anymore. At the very least, you should be familiar with all the features from ES6 (also known as ES 2015), including declaring variables with
const. You might not use ES6 maps and sets much, but promises are another need-to-know feature. ES6 also makes modularizing your code easier with import and export statements.
And just being up-to-date with ES6, which came out in 2015, is a low bar to clear. Here are just a few examples of features you should know from later specs:
Don’t worry about trying to memorize everything—that’s what documentation is for. Just familiarizing yourself with the specs is a great start.
Promise.allSettled() method, a nifty addition to the Promise prototype. And the more you know about promises, the better.
3. Embrace asynchrony
Yes, asynchrony is hard, but it’s not as hard as it used to be. If you’re still in callback hell (stuck in ES5), you probably aren’t using promises and async functions enough. In addition to understanding how to write callbacks (if you started as a developer after the olden days of callback hell), you should know how to use the following tools for asynchrony:
- Promises, including the Fetch API for making HTTP requests
- Async/await, which is syntactic sugar for promises
4. Know where the language ends and the framework begins
5. Learn about prototypal inheritance
6. Bling out your code editor
When I first started coding, I wanted to learn to code the old-fashioned way—without help from my code editor. That was silly! Your code editor can make it a lot easier for you to code. I use Visual Studio Code and take advantage of extensions wherever possible. If you’re not happy with your code editor or aren’t sure which one you want to use, I highly recommend VS Code, which is free.
So which extensions should you add? Well, there are a lot of good ones, and you might want to start with a curated list of recommendations to help you get started.
I also really like colorizing my code, which can really help me see where curly brackets begin and end. It makes code easier to read and indent. For VS Code, I use Bracket Pair Colorizer 2.
Finally, for testing, I’ve used the Jest extension and had a lot of success with it. This extension makes it really easy to continuously run tests in your code editor and debug your code. Not testing? Well, that leads me to my next tip.
7. Test your code, even if you are just coding to learn
Sometimes it’s fun to hack together a project as quickly as you can. In those cases, it might seem like testing your code is boring, takes more time, and isn’t necessary. However, that’s plain wrong. If you are choosing not to test your code, or, gasp, don’t know how to write good tests, you need to start testing now.
There are a lot of reasons to test code beyond just making sure it works. I’m a big fan of test-driven development (TDD) for writing code. TDD encourages you to start small and break a big problem into many smaller parts. You write the test first, then write just enough code to get it passing. Before you know it, all the little problems you’ve solved add up to a much bigger problem that would’ve been much more difficult to solve all at once.
TDD reduces frustration, especially further down the line when your projects become more complex. You know what works because you’ve already tested it. If new code breaks an old test, you’ll see that right away, instead of having a bug coming back to bite you later. There’s also the little dopamine rush that comes with getting a test passing and feeling you are on solid ground.
And yes, use a Jest extension with your code editor if you can!
8. Build an environment from scratch
9. Teach others what you’ve learned
When I taught coding, I realized I didn’t really understand concepts deeply until I could explain them. The better you understand something, the more simply you should be able to explain it. That means you aren’t just regurgitating complex information—you actually understand the concept deeply enough to break it down.
Just be careful that you’re not ‘splaining—if you’re explaining prototypal inheritance to someone that didn’t ask, that’s a red flag. Sharing information has to be a two-way street, which means checking in and making sure that the person you are sharing with actually wants to learn what you have to say.
10. Be humble and ask questions
It’s okay if you don’t know all of the answers, even about basic concepts. The more you learn, the more you realize you don’t know. Be curious and ask questions.
Want to expand your learning journey to include DevOps? Take the next steps towards careers in DevOps and observability:
If you want to try a more hands-on approach and learn how to use observability in your own applications, sign up for a forever free New Relic One account.
The views expressed on this blog are those of the author and do not necessarily reflect the views of New Relic. Any solutions offered by the author are environment-specific and not part of the commercial solutions or support offered by New Relic. Please join us exclusively at the Explorers Hub (discuss.newrelic.com) for questions and support related to this blog post. This blog may contain links to content on third-party sites. By providing such links, New Relic does not adopt, guarantee, approve or endorse the information, views or products available on such sites.