Let's face it - not all advice is helpful, even if it is well-meaning.

As a beginner, you're especially vulnerable. It's hard for you to tell the difference between the advice which will save you months, or cost you years.

You could avoid taking any advice, but the reality of a self-taught developer is you rely on online advice when you get stuck. How do you tell which advice to follow? How do you progress?

I've seen all sorts of bad advice - the worst of which make repeat appearances. I've compiled a list of some common bad advice, why you shouldn't follow it, and what you should do instead.

#1: You should switch to this course/book/resource

I see this crop up when someone has already completed a course but struggles to write code by themselves. They still need the aid of a tutorial or guide handing them the answers.

This piece of advice hurts because it suggests that there is a "perfect" course out there. One that will solve all your problems, all you have to do is find it.

This is a core contributor to "tutorial hell". Beginners get caught in a cycle of following new tutorials and never addressing the underlying problem. They never learn how to move past the tutorials. Instead, they start over again, hoping this time, it'll be different.

Beginner resources don't differ by enough to make it worth starting over.

You didn't screw up early on. You don't need to start over with a clean slate. You need to spend some more time with the material you've already learned.

I've elaborated on this more in this article. There are two parts to software development: syntax, and learning how to build software.

Instead of throwing in the towel and re-rolling, start building tiny projects. What do you already know? Try to think up some small project ideas that you can create with the knowledge you already have.

#2: You should use this framework/library instead

This isn't "every time you see this, walk the other way" advice. I'm specifically talking about cases where an answer without any real thought.

Hey, How do I change the colour of a div using a button?
It's way easier if you use React

There's nothing wrong with suggesting frameworks and libraries. The issue comes when the framework is suggested blindly.

React doesn't help you change the colour of a div at all. The effort it would take to include React would far outstrip the time it takes to solve it some other way. The commenter just likes React.

That doesn't mean all suggested tech is bad. The important thing here is that you do your research, and make an informed decision.

Each time you include a new tool, you have to learn how to use it. You may have to rewrite large portions of code. It's up to you to decide whether that cost is worth solving the problem you have.

Do your research. If it doesn't make sense, move on and find something else. Don't take anyone else's word for it.

#3: You have to be passionate to learn JavaScript

I hate seeing this advice.

This one can rear its ugly head in any thread about JavaScript. Someone comes along with a story about how they learned JavaScript in 6 months... by spending 12 hours a day living, breathing and consuming nothing but code.

And if you want to succeed, you need to do it too.

It's too extreme. It glorifies an approach that involves destroying your lifestyle. It suggests that if you have a full-time job, a partner, a young child, or any other hobby, you can't learn JS.

You don't need to spend 12 hours a day on JavaScript. You don't need to find 3-6 hours every night to code. You don't even need to be having fun.

You need to focus on consistently spending time learning JavaScript.

You're learning to code. This is a skill you'll develop over the rest of your life, so there's no rush. You're going to be more successful if you can find time in a way that you can sustain forever.

There's nothing wrong with learning to code in 1-hour chunks, so long as you can keep doing it.

#4: You need X days/months/years to learn JavaScript

I can understand the desire to know how long things take. Unfortunately, it doesn't work like that.

There is no set point where you have "learned JavaScript". Any effort to say how long it takes is inherently flawed.

The damage here is the implication that there is a point where you'll feel "done". You can work your butt off trying to reach that point, and get more and more disillusioned when it never comes.

Ignore anyone when they say how long it took them. It's more likely to be the Dunning-Kruger Effect than actual anecdotal evidence.

Instead, focus on tangible goals:

• Starting your first solo project
• Creating a fun SVG Animation
• Getting your first job

#5: You need to know about X before you start Y

This one often comes when someone wants to try something new, like React. About half the time, it includes a very long list for X.

You couldn't possibly start using React until you've learned everything about:

• Classes
• Functional JavaScript
• Kubernetes
• Quantum Computing
• Crochet

/sarcasm

These lists tend to cover everything the new framework etc. uses (and then some). They're a result of the "waterfall" approach that we seem to love when guiding beginners. "You have to learn all the basics before trying anything advanced."

I've talked about this in other articles like When to start learning a Front-end Framework. You often need far less knowledge to move into advanced concepts than you'd think.

These lists are useful though: They are a syllabus for the framework. It's a list of what you will learn if you choose to learn React.

The important thing here: Don't let it stop you. Don't worry about having to look stuff up.

Motivation is hard. It's easier if you're spending time working on things that you want to work on.

#6: If you can't even do X, you don't deserve to be a programmer

Okay. You've got me. This isn't exactly advice. It's the programming version of schoolyard bullying. While infrequent, this can show up anywhere.

The reason this is here is that it preys on insecurity present in a lot of struggling beginners. "I don't get it - maybe I'm not meant to be a programmer?".

Any time you see this, you're not seeing an actual critique of "what it takes to be a programmer". You're seeing someone posturing - someone who is insecure about their own programming.

Notice how it is never accompanied by an actual answer?

Are you willing to put in the time to learn to code? You deserve to be a programmer.

Learn things at your own pace. For every dickhead comment like this, there are plenty of others that will actually help.

#7: You should learn this other language instead

It may seem strange that this advice is around. This often finds its way into discussions about how to break out of tutorial hell.

Learning another language is weird advice in that can kind of work. It provides a new perspective on programming, which may be what you need to break out of tutorial hell.

The issue is that tutorial hell exists no matter what language you're in. Learning C or Ruby isn't going to fix your problem. It provides a different set of tutorials to keep you in hell.

Your time is better spent addressing the problems you're having with writing JavaScript. Write some small projects, do some coding exercises, write all the sorting algorithms. Practice.

Afterword

I'm sure you've noticed a trend in my suggestions: Be consistent in your learning, and write code, damn it.

If you're struggling with what to build, I recommend reading this article about finding project ideas.

If you want to read more about tutorial hell, you can check out this article: "Can you Actually Learn JavaScript from an Online Course"?