DEV Community: Carl Anderson

Break out of Tutorial Hell - What to Do When You're Going Nowhere

Carl Anderson — Mon, 26 Jun 2023 09:18:44 +0000

When you first start learning JavaScript, there is a clear path for you to follow.

Do an online course
Read Detailed JavaScript Book / Course (e.g. You Don't Know JS)
Follow a To-Do App Tutorial
Start your own project
Profit

This path makes sense - The courses, books, and tutorials will teach you all you need to know about writing JavaScript. You even write an actual app!

Surely if you follow this path, you'll reach the pot of gold at the end.

You start dedicating your evenings to this path, and after several months, and hundreds of hours of painful struggle and work, you're finally ready to set out on your own.

You fire up a text editor, ready to code your great idea - but you have no idea how to code. All the knowledge is in your head, but when it comes to how to string it all together, nothing comes.

What went wrong? You did the work. It all made sense in the tutorials.

Maybe you started too soon? Perhaps you need to spend more time doing courses? You struggled with generators, after all. You definitely have more to learn. You pick up another course...

You have now entered what is affectionately known as tutorial hell.

Why courses don't work

Okay, courses do work, but lots of JavaScript courses only teach you half of what you need to know.

Courses and books teach you the separate building blocks of JavaScript - and a lot of them will teach you all of the building blocks, regardless of how useful they are.

Courses focus on reference material. The big secret of JavaScript (and coding in general) is that you will always have access to reference material. You can learn about new pieces of JavaScript when you're faced with a problem that needs it.

Far more important than learning and memorizing everything there is to know about JavaScript developing an instinct for how pieces are used and fit together.

You need to build up the skill part of coding.

What you should do instead

It seems really stupid to say this, but you need to code on your own.

It sounds stupid because this is exactly what you have difficulty doing, and why you're going back for more tutorial hell.

The trap you (and most beginners) have actually fallen into is that you've picked a project that is far too difficult for your current ability.

You need to start with a tiny project that is solely to help you learn. These practice projects differ from regular projects in several key ways.

It should have one clear goal
It should be small (even smaller than what you're thinking)
You should be prepared to throw it out at the end

I think the part worth highlighting here is that a practice project doesn't have to be useful or even good. In fact, it's better if it's not.

I'm a fan of pointless projects when practicing. It can provide fun and novel ways to learn about parts of JavaScript while highlighting their limits in ways that may take much longer to discover if you solely explore through pragmatic projects.

You'd be surprised at what you can learn by making a button chase a user's mouse around the page... or run away from it.

Set a small, achievable aim, and then commit whatever coding crimes you need to get there.

Right now, it's more important that you're able to code anything. You're building a muscle. It will take time and consistency to grow.

You'll get there one day. For now, do what you can do.

Are you stuck on JavaScript Tutorials?

Download my ebook on how to succeed as a self-taught JavaScript Developer, and how to find projects that you'll actually finish.

No, People Aren't Learning to Code in 3 Months

Carl Anderson — Thu, 22 Jun 2023 11:07:33 +0000

At the start of your programming journey, it's natural to wonder how long you need before you're up to scratch and ready to strike it rich in the big, wide world as a bonafide programmer.

After all, after you've spent 1 month, 3 months, or a year on your journey, it can feel like you aren't making much progress. It's natural to want to compare yourself to others and see where you should be on your journey.

A quick Google would suggest the magic number to learn programming is 3 months. This is backed up by stories online about hot-shots who buckled down, ignored their children, gave up their entire lives, and programmed for 24 hours a day.

If you've been programming longer than that, it's easy to feel like you're falling behind, you're not cut out for programming, or you're just not hardcore enough in your approach.

Except these stories have a gaping hole they never address: When have you finished learning programming?

As a question, it has no answer. You never finish learning programming, and that's okay. It's an endlessly complex world with amazing breadth, depth, and nuance.

Programming is a skill, so when I hear someone say they "learned" it in a month, I treat it with the same skepticism as if someone has confidently walked up to me claiming they learned to paint or French.

I'm sure they made amazing progress in that time, but take these stories with less a grain and more a boulder of salt. They're more likely to be click-bait or a victim of Dunning-Kreuger than a legitimate story that you can learn from.

If you've spent 3 months, or 6 months, or 10 years programming, and don't feel like you've learned how to program, you're completely right. There is always more to learn, so the best path to success is consistent, sustainable growth.

Have faith in yourself. You're building a muscle. It takes time, and it can be very difficult to notice a difference from one day to the next. Sometimes, it's worth looking back to appreciate how far you've come.

When I first started programming, I'd look back on code that I'd written only a few months before, and be shocked by how bad it was compared to what I could do now.

You're building a muscle. The most important thing is that you keep at it.

Are you stuck on JavaScript Tutorials?

Download my ebook on how to succeed as a self-taught JavaScript Developer, and how to find projects that you'll actually finish.

3 Methods to Actually Remember What You Learn in Coding Tutorials

Carl Anderson — Wed, 30 Sep 2020 07:16:00 +0000

When you first deal with a new topic, coding tutorials are great. Rather than continually grasping at straws and struggling your way through a project, the instructor conveniently shortcuts all this pain - all you have to do is follow along.

After several hours of painstaking copying, you have a working app - an app that you built... right? Something to be proud of!

But then the thought creeps in... did you build it?

You couldn't do it again (at least on your own). You have no idea how it was built. After all that work, have you really learned anything?...

Let's be honest: you probably didn't learn much - but there is gold in those tutorials. I've espoused the benefits of copying people to learn code, and that's what you've just been doing.

The reason nothing is sticking is that when you're busy copying the instructor, there's no space to engage with the content. It's not your fault, that's just the reality of being human.

The real value is in what you do after the tutorial.

To make the content stick, you need to spend some time working with the code. Below are three effective strategies about how to do that:

#3: Refactor the code

This is the most direct way of engaging with the tutorial content - go through the code and look for ways to change it.

The questions you want to ask yourself are:

Is there some other way of structuring the code? (Different functions, classes, etc.)
Are there better names for things?
Are there any other language features I could use to replace this? (Arrow functions, Ternary statements, etc.)

For the sake of learning, these changes do not need to be improvements - you're only trying to engage with the code. In fact, if you can't think of a way to improve the code, look for ways to make it worse (while making sure it still works).

This approach is the best for learning how the tutorial code works and has the lowest barrier for entry. It is also the easiest (but least effective) of these methods, as it doesn't require you to solve many new problems.

#2: Change, or add a new feature

For my money, this is my favourite way of learning from a tutorial. Take the code you have, and use it as the basis for a practice project.

In a todo-list app (because there's no shortage of tutorials for those...), you could:

Add due dates for tasks
Add sub-tasks
Add comments to tasks
Add a "Clear all" button

All of these are valuable opportunities to practice the concepts you've learned and to engage with the tutorial.

This approach is best for practising building features (and projects) from scratch and is the approach I'd recommend most of the time.

The downside is you may not spend much time directly working on what the tutorial was trying to teach (but you'll still learn plenty!).

#1: Create a similar (but different) project

Of the methods I've outlined, this is probably the most difficult to get right, since it's hard to find the correct balance. Still, if you get it right, it can be an effective approach.

The goal is to create a project that is different from the tutorial but is similar enough that you're able to use the tutorial to help you.

For instance, you might use a Todo app tutorial to create a Notetaking or a Flash Card app.

This approach is the best way to practice the core principles that the tutorial is trying to teach. You'll continuously be readdressing and changing things to fit your new project.

The downside, as I said, is that it's challenging to strike the correct balance of "similar but different". It's easy to accidentally bite off more than you can chew.

Are you stuck on JavaScript Tutorials?

Download my ebook on how to succeed as a self-taught JavaScript Developer, and how to find projects that you'll actually finish.

The Danger of Specializing Too Early

Carl Anderson — Mon, 21 Sep 2020 10:24:36 +0000

I want to become a Full-stack dev, but I'm not very good at Front-end. Should I just become a back-end dev?

- A total beginner

When you're learning to code, you're working with a goal in mind. You're not trying to learn to code, you're trying to become a developer.

Maybe you're more specific than that - you want to be a front-end or a full-stack developer. Perhaps you've taken it that step further and decided to become a React developer.

This approach can work wonders in your later career. However, if you're still a junior (or pre-junior), it has two significant flaws:

You should learn skills outside of your specialisation. Learning a broad range of things makes learning new skills easier. If you box yourself in, you'll slow your growth.
As a Junior, your experience with particular technologies isn't nearly as important to employers as your general programming experience.*

*Take this with a grain of salt. There are no rules when it comes to hiring, so anything is possible. I'm just trying to make things easier for you.

Ideally, you would refrain from specialising until several years into your career. I can appreciate the reality isn't that simple, and that it's easier if you work towards one of these specialisations from the beginning.

As a compromise, what I want you to do is to find something adjacent to what you're learning, and make that your next project.

If you're consuming an API, can you create your own endpoints with Express and Node?
If you're learning React/Vue, can you learn to serve the files from a web server?
Find out what a browser does when it fetches a webpage.

Be curious. Work on a range of projects. Your future self will thank you.

Are you stuck on JavaScript Tutorials?

Download my ebook on how to succeed as a self-taught JavaScript Developer, and how to find projects that you'll actually finish.

How to self-teach JavaScript

Carl Anderson — Thu, 02 Jan 2020 11:04:34 +0000

There's no denying that self-teaching JavaScript is difficult - although you have the benefit of always working on areas that interest you, it can be difficult to find direction in your learning.

You're continually asking yourself: are you're doing the right thing? Is there something important you're missing? What are you meant to do next?

Not all learning methods are equal: the time you spend glancing over yet-another explanation of prototypal inheritance (that you still don't understand) isn't as beneficial as when you're 20 chrome tabs into solving an inheritance problem.

If you're looking to make the most of your time, there's a simple cycle that you should be underpinning your learning:

Write, Research, Repeat

The key takeaway here is that your entire learning path should be driven by writing code. It's a skill you have to develop, so there's no substitute for practice. The trick is finding a constant stream of ideas.

The ultimate process is straightforward, however. Write code until you get stuck, and then research your problem until you get unstuck. Over time, you'll need to research less and less.

Of course, if you can't write any code, then this advice isn't useful to you, so I've divided up this strategy into various learning stages to give you a more granular approach.

You have three phases of learning, where the strategy differs slightly:

Introduction Phase
Growth Phase
Honing Phase

Introduction Phase

This phase is the simplest to grasp - you don't know anything. The best thing to do is to take a course that introduces you to the basics of JavaScript. Most people do an entire, in-depth course during this phase – after all, more is better right?

No, not at this stage.

The challenge most people have with the introduction phase is that they try to learn far too much before attempting to apply their knowledge. They try to run before they can walk.

Courses will teach you a language, but they won't teach you how to build software – that's something that you can only learn from practising. You want to keep the period where you are only working from a course as short as possible.

In short, you want to learn absolute basics. I recommend completing the Basic JavaScript section of FreeCodeCamp. It covers all the core building blocks you'll need to work on your own, then you can come back.

Growth Phase

This phase is the point where you have enough knowledge to write code, but everything's clunky, and you're still missing significant amounts of knowledge.

Initially, I recommend you completely stop your course for a while, and spend some time creating several practice projects to solidify what you learned during the introduction phase.

When you're more confident in the basics, you should re-incorporate your course back into your learning. Doing a section in between projects is a good approach.

When you've finished your course, it's a good chance to stretch yourself and try new things. Experiment, and work on the areas that interest you: Frameworks, CSS drawings, WebGL, Node. Have fun with it. It's all valuable.

Honing Phase

This phase isn't clear-cut like the other two. The honing phase is an extension of the growth phase, but we start working on more ambitious projects. Chances are you are still missing significant amounts of knowledge, but coding is comfortable now.

You're ready to start the honing phase when you aren't lost when working on code. You're able to imagine your own solutions to problems (even if you have to google the specifics). This article might help you.

This is the time to practice softer aspects of programming, like the code quality and structure. Start learning best-practices, like testing, commenting your code, and (if necessary) writing docs.

You can now also assemble and refine your portfolio, and use it to apply for Junior roles. It can take a long time, though, so I wouldn't make it a priority. You can also start on interview prep through sites like HackerRank.

Although it sounds cheesy, the most critical part of this entire process is to make sure you're having fun. Learning to code is a slow process, and it's going to be much easier to keep your motivation if you're enjoying yourself.

// Detect dark theme var iframe = document.getElementById('tweet-1212372164520955904-487'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1212372164520955904&theme=dark" }

I've linked this article multiple times already, but I strongly recommend you check out this guide on choosing ideas for practice projects. Get out there and write. some. damn. code.

Are you stuck on JavaScript Tutorials? Sign up to my newsletter for more helpful articles to get you moving again

When Are You Ready to Freelance as a Front-End Developer?

Carl Anderson — Thu, 05 Dec 2019 12:45:22 +0000

When can I take a full front-end web project and start working as a freelancer, and how much knowledge do I need?

A newbie developer asked this in the JavaScript Facebook group – and it's a good question. After all, when you've been grinding out several months of online courses, a big question is when do I start getting paid for this?

Many of the responses from other beginners were suggesting new technologies to learn or concepts you need to know, but the answer is much more straightforward:

You're ready to freelance when you can find people to pay you for your work.

Your development skills, while helpful for landing contracts, are secondary to your ability to sell yourself to clients, close deals, and build a successful sales funnel. As long as you can repeatedly find clients, you're able to freelance.

Should you freelance?

The thing is, as a freelancer, you're a small business. It comes with a lot of extra non-development work, like marketing yourself, negotiating contracts, creating invoices, and doing your taxes.

Take a moment to think about your reasons for wanting to freelance. Almost any reason will do, so long as you acknowledge that:

Freelancing is a significant time investment
Becoming a freelancer isn't easier than finding a job

You'll also want to check that your current situation can survive the instability that freelancing brings. It's not uncommon to hit patches where you aren't getting paid for several months at a time, which may be a killer if you're pay-check to pay-check.

Once you've decided that freelancing is for you, I highly recommend checking out Brennan Dunn's Double Your Freelancing - it has excellent articles for freelancers of all levels. It will get you started on the right foot.

Are you stuck on JavaScript Tutorials? Sign up to my newsletter for more helpful articles to get you moving again

How to Get Past JavaScript Tutorials: Copy & Paste

Carl Anderson — Tue, 12 Nov 2019 10:24:00 +0000

"I can follow the tutorial perfectly, but when I try to do it by myself, I have no idea I'm doing."

Sound Familiar?

It's one of the most frustrating situations you can experience as a developer because... what do you do? You were trying to learn how to create projects, and the tutorial was supposed to teach you that... but it didn't work. What are you meant to do now?

You're almost on the right path – you need to work on your own projects. You just need some help in working out how.

Let me ask you this: why do you think that you're able to understand the tutorial perfectly? Because you're copying someone else - and there's a lot of value in it.

In an ideal world, you'd have an expert sitting next to you all day telling you precisely what to do - but that's a luxury very few people have. Fortunately, you don't need one. Others like you have asked the same questions thousands of times, all you have to do is copy the answer.

The issue is that with a tutorial, you copy everything. You don't get the opportunity to make the decisions that you need to make to code by yourself. Instead, focus on copying small sections of code and composing them into a broader application.

Why you should Copy & Paste

Programmers are absolutely shameless about copying each others code. We joke about it regularly - and it's our most important skill. Sharing and copying solutions are how we grow as individuals and as a community.

Liquid error: internal

Despite this, it's not uncommon to see advice that you, as a beginner, shouldn't copy code. The thinking is you won't learn anything by copying. This advice, however, ignores the actual difficulty of copying code.

Make no mistake, copying and pasting code isn't easy. If it were, programmers would be minimum wage workers. It can often take a lot of work and knowledge just to know which code to copy, let alone how to fit it all together.

What you need to learn at this point is how to solve problems - you need to work on build projects with JavaScript. Copying code is a perfect way for you to fill the gaps in your knowledge while you're learning that.

How to code with Copy & Paste

Before we begin: you need a project. It's hard to write code if your code doesn't have anything to do. You want to start simple and progressively get more ambitious with your projects as time goes on.

Coding with copy and paste is all about breaking your project down. This is the hard step - you need to take your project and deconstruct it.

Can you divide your project into distinct parts? Can you divide those parts further?
What does each part do (it's behaviour)?
What actions do you need for each behaviour? Can you divide those actions into smaller actions?

This step isn't easy. It can be hard to know what actions to take when you haven't encountered the problem before. Your list might be incomplete, or wrong. It doesn't matter all that much - if what you have doesn't work, you can just update the list.

With these actions, there are two golden rules to keep in mind:

The more specific an action, the easier it's going to be to find code for it
The less complete the portion of code you copy, the better it is for learning. This is why tutorials don't work.

Translate actions into code

Before you start googling how to do each action in your list, take a moment to see if you can do any of them by yourself. This is an excellent way to check what you've learned. As you get better, you'll find yourself needing to copy less and less.

Write down your answers directly into the code. It doesn't matter if you leave sections incomplete. Put a comment in indicating that you intend to put more code in.

/**
* Function that changes fields based on a dropdown value
*/
function updateFields(event) {
    let value = 0; // TODO: Get the value from the dropdown

    if (value === 1) {
        // TODO: Set value of form field
    }
}

//TODO: Add event listener to dropdown

Now what you're left with is a big pile of actions that you don't know how to do – This could be most of your project, or this could be a single step. Either way, it's time to look them up in Google.

Finding code snippets can be surprisingly challenging. How easy it is to find a snippet depends on the words you've used in your search. While you're looking at answers, it's a good idea to search for other keywords that people use. For instance, I've used dropdown in the snippet above, but it's represented by <select> in HTML. Calling it "select" may return more relevant results.

There's also one final problem: You can't put distinct pieces of code together, and expect it to work. More often than not, you'll need to change code you've copied to make it fit.

/**
* Function that changes fields based on a dropdown value
*/
function updateFields(event) {
    let value = event.target.querySelector(':selected').text;

    if (value === 1) {
        document.querySelector('#lastname').value = '';
    }
}

let dropdown = document.querySelector('#dropdown');
dropdown.addEventListener('change', updateFields);

Once your project is working, you can consider this step done. You can stop any point from now, fully satisfied that you succeeded. However, it's a good idea to review your code and see if there's anything you can improve.

You've made it work, now make it good

Once you've copied and pasted a bunch of code together, chances are it's a mess. It's no surprise – your code is Frankenstein's monster, sewn together from unrelated parts.

If your project isn't a throwaway, it's a good idea to go through again and look for any improvements you can make. This can include renaming variables, using newer APIs, etc. At a minimum, you should aim to make the code readable.

This is a chance to make the code your own. You need to make it presentable in case you decide to revisit it, or if it becomes a part of your portfolio.

What to do next

Growing as a programmer is an iterative process - you can't expect to be an expert after a single project. You should get into the habit of doing dozens of small projects, both to learn and to form a portfolio.

The trick here is to keep your projects small so that you can finish what you start, and to consistently set aside time to work on them. Finishing a project is much harder than starting one, and it's a valuable skill that employers will be looking for.

Are you stuck on JavaScript Tutorials? Sign up to my newsletter for more helpful articles to get you moving again

Practice JavaScript by Breaking Things Down

Carl Anderson — Thu, 31 Oct 2019 16:58:22 +0000

The most important skill you can have as a developer is knowing how to break tasks down - and it's a skill you can practice without a computer.

As a beginner developer, one of the most frustrating situations you'll encounter is attempting to complete a simple task, but you have no idea where to begin.

I've said it before, but learning JavaScript isn't enough. Hundreds of pieces of JavaScript can be rattling around in your head, but unless you can break down tasks into code, you'll struggle to get a single line out.

The thing is programmers are constantly breaking things down and exploring systems around them. A question that regularly floats in our mind is 'how does that work?', or 'how would that work?'.

This kind exploration is in this clip from the first season of Silicon Valley (warning: incoming dick references).

Yes, it's hyperbole, but I've had discussions with programmer friends where we break down ridiculous ideas like this. It's a lot of fun – and it's a valuable programming exercise.

Exercise: Breaking down Processes

When you're starting programming, the best thing for you to look for and break down are processes_._ A process is anything that boils down into a series of actions or decisions.

Our life is full of processes - how you drive, how the bartender serves you, how you tie your shoes. When you're exploring a process, the first step is to define the actions or decisions in the process.

Here's a high-level pass at a process that a bartender might follow.

1. Decision: Choose the hottest person at the bar
2. Action: Take their order
3. Action: Make their drink
4. Action: Take their money

Although this explanation is enough for a human to follow, we want to explore this more thoroughly and add more detail by asking two more questions:

What criteria impact the decisions?
Are any of the steps also processes?

In this example, all the steps are processes. How do you tell who the hottest person at the bar is? If you add some more detail, it could turn out to be something like this:

1. Choose the hottest person at the bar
    1. Take a thermometer
    2. Go around every person at the bar, and take their temperature
    3. Choose the person with the highest thermometer reading
2. Take their order
    1. If you're not next to the person, walk over to them
    2. If it's loud, yell the next step
    3. Ask for their order
    4. Wait for response
3. Make their drink
    1. Get a glass
    2. Go over to the beer tap
    3. Pull the tap's handle
    4. Wait until the glass is full
    5. Stop pulling the tap's handle
    6. Place the full glass on the bar
4. Take their money
    1. Put hand out, expectantly
    2. If they didn't order beer, wait until yelling stops then apologise
    3. Else, when money has been placed in your hand, put it in the till

Compared to our last attempt, this is a far more detailed (and revealing) version of a bartender's process. There are still details missing, but exploring this any further wouldn't be very fun.

When you're doing this in the world, you can be as detailed, or as thorough as you like. The point of the exercise is breaking down tasks into its component pieces, not creating something you can actually code. Have fun with it.

If you haven't seen it already, you can also check out my other article on breaking down programming problems via pseudo-code.

Are you stuck on JavaScript Tutorials? Sign up to my newsletter for more helpful articles to get you moving again

4 Mistakes That Are Getting You Stuck Learning JavaScript

Carl Anderson — Tue, 24 Sep 2019 15:22:52 +0000

When learning to code, you expect to struggle. There's a lot to learn, and it won't all come easily. All you need to do is put your head down, work hard, and chip away at the difficult places bit by bit.

But what if you've been "chipping away" for weeks with no results? Every time you try to grind through the next chapter or work out how to write that first line of code, you get nowhere! You don't get it.

You're stuck - and you have no idea what to do.

Did you miss something important? Do you need to start over, and pay more attention to the basics? What are you doing wrong?

The good news is that you're not the first person to ever get stuck. I'm going to cover four common mistakes and provide advice on how to get past your sticking point.

#1: You're not writing code

Not writing code is the number one mistake beginners make - and it's by far the most damaging in this list. JavaScript is a tool, so the best way to learn it is to use it - You can't learn to swing a hammer by looking at nails.

I've covered it before in this article - solving problems with code is different from knowing the language. You're going to have to learn this skill eventually, and the sooner you start, the better.

Courses will often include some programming exercises, but these aren't enough. You should aim to make your own programming decisions, instead of finding a predetermined solution. With that said, exercises are better than nothing.

You can check out this article if you want help thinking up project ideas.

#2: You're trying to complete topics before moving on

Learning paths in JavaScript are presented linearly. You have to learn all about variables before you learn all about arrays. You need to learn vanilla JavaScript before you learn React/Angular/Vue.

This linearity isn't what learning JavaScript is really like. We only teach it that way because we have to introduce you to concepts one at a time. It needs to be done in some order.

Learning JavaScript is not linear. Concepts flow into each other, and later material provides insight into earlier thoughts. Trying to "finish" arrays or vanilla JavaScript before moving on is a waste of time.

Instead, you should gain a shallow knowledge of a breadth of topics, and look it up again when you need more depth:

You should know what each concept is
You should vaguely understand when/how to use it (so you know when to look it up again)

That's it. When you're writing code (see #1), that's your chance to revisit these concepts and understand it more.

If you're stuck with a particular concept, move on and come back to it when you need it. There's a good chance that more advanced ideas will provide the insight you need.

#3: You're starting over again

This is the mistake with the highest casualty count for would-be JavaScript developers. In the biz call, we call this "Tutorial Hell".

When you're completely stuck on a concept, it's tempting to find a new resource and start over. Maybe this one will teach you in a way you understand?

Don't do this.

JavaScript's core principles are concrete, so beginner resources are relatively interchangeable. A variable is a variable, and that doesn't change. It's unlikely that you're going to get much value by scrapping what you've done, and trying again.

What you should do instead is practise writing code with what you already know (#1). Rather than spending more time with a concept, move on and go back when you need (as in #2).

#4: You're focussing on JavaScript too much

This may seem silly, but your end goal isn't to learn JavaScript. You're learning to program; JavaScript is a means to an end - and you don't even need that much.

A large part of JavaScript consists of what we call syntactic sugar. These are features that make JavaScript more pleasant to use but don't add any new functionality.

Once you account for this syntactic sugar, you only need about 20% of JavaScript.

If you spend too much time learning JavaScript, you'll eventually be re-learning things you already know. Your time is much better spent studying general programming concepts.

Here are some concepts to get you started:

Boolean algebra (truth tables)
Graph/Set Theory. See this article too (Warning: Mathematics)
Dijkstra's Algorithm
A* Algorithm
Sorting Algorithms
Data Structures

Some JavaScript courses cover these topics. If that's the case, you can try skipping forward.

Disclaimer

In this article, I've told you to skip over concepts and ignore large swaths of the language. This doesn't mean you shouldn't expect to learn these concepts eventually.

The reason for skipping concepts is that we, as individuals, don't use most of JavaScript most of the time.

Rather than focus on learning a specific concept, you should be writing code. Try to create situations where you need that concept - then revisit it.

This creates a basic virtuous cycle:

Write code until you find something you don't know
Learn the thing you don't know
Repeat

The crucial part is that you're out there writing code. I recommend checking out my post on how to write JavaScript and finding project ideas to get you started.

Are you stuck on JavaScript Tutorials? Sign up to my newsletter for more helpful articles to get you moving again

How to Write JavaScript When You Don’t Know Where to Begin

Carl Anderson — Mon, 12 Aug 2019 15:06:55 +0000

Have you ever tried a coding problem, but ended up staring at a blank editor? Maybe you tried to write a simple function, but didn't even know where to begin?

It's frustrating.

After all, you've spent months working to understand JavaScript's basics. You've learned all there is to know about variables, arrays and functions... but when it comes to coding on your own, you struggle to write a single line.

It's not that you don't know JavaScript -- You're fully capable of reading code. It's just when it comes time to putting pen to paper, something is missing.

How do you get past the blank editor?

Firstly, it's important that you don't get discouraged. Starting another course is not the answer. What you do need is a method for breaking down your ideas so that you know what code to write.

I've broken down the system that I use to solve coding problems and provided a step-by-step guide on how to go from idea to code. I'll take you through an example using the Fibonacci sequence to show how it works in action.

How to break down problems

(N.B. I refer to "English" a lot here, but you should use whatever language you're most comfortable with)

A flaw in the way beginners try to approach coding is that they try to solve the problem in JavaScript. This seems like a stupid statement, so I'll say it another way: you need to solve the problem in English first.

When we teach JavaScript, we show you the building blocks of the language. What we don't do is explain how to express ideas in JavaScript.

You need to express your ideas in English first, and then translate into JavaScript. This is done in the following four steps:

Define your problem in English
Define a solution in English
Write your solution in pseudo-code
Translate your solution to JavaScript

This still might not be very easy the first time you do it - it can take some getting used to. Spoken languages don't force you to clarify your ideas at the level required for coding.

As you do it more, you'll gain an understanding of what you can and can't do with code, and gain an innate sense for how to express your ideas in a way that translates easily.

Writing in Pseudo-code

Pseudo-code is an amalgamation of code and English. There's no correct way to write pseudo-code - you make it up as you go along. So long as it looks a little bit like code, you're doing well.

The reason we write pseudo-code is that it allows us to write in a language-agnostic way. We use it to skip over unnecessary details in a way that we can easily convert into code.

The beauty of pseudo-code over simply writing JavaScript is we can choose whatever level of detail we like. We can use "magic" statements to sketch our ideas without having to worry about implementation details. If it's helpful, we can even write pseudo-code in full sentences.

//Both of these functions are perfectly valid pseudo-code
printSortedArray(array):
    sort array
    print each item in array

printSortedArray(array):
    // Bubble sort
    while array is not sorted:
        for each item in array:
            if item+1 is less than item
                swap item and item+1

    for each item in array:
        print item

Example: The Fibonacci sequence

I'm going to run through an example of breaking down a problem and writing pseudo-code. We're going to create a function which returns the nth value of the Fibonacci sequence.

There are two things to note throughout this process:

It is highly personal. What I come up with may be different from you.
It takes longer than it looks. This is a blog post - you skip straight to the end result. You don't get to see the time spent thinking about the problem.

Plain English

Our main goal into this step is to clarify everything. The more concrete and specific we can be, the better. Initially, it's a good idea to simply define everything, and then start stating facts about your definitions.

If we define the Fibonacci sequence problem:

The Fibonacci sequence is the sequence 1, 1, 2, 3, 5, 8 etc.
To calculate any value of the Fibonacci sequence, I have to know the two previous values in the series.
If I want to know a specific value in the sequence, I need to know every prior value in the chain.

This may not seem like much, but it does give us enough to define a simple solution:

To get the value for n, I need to generate the entire Fibonacci sequence up to n.

If you're able to (and the problem allows for it), you can think up multiple solutions, and choose one. If it doesn't work out, it's good to be able to come back and try a different path.

Pseudo-code

Alright. We now have a specific way to get the nth value of the Fibonacci series: create all the numbers up until n. At this stage, we want to broadly think about how we're going to code this.

As I mentioned, the beauty of pseudo-code is that it lets me solve the problem at different levels of detail. It can often pay to solve the problem using "magic" the first time around and add detail as we need it.

This is how I'd devise a "magic" solution:

fibonacci (n):
    loop between 0 and n
        sum two previous fibonacci numbers
        when n, return value

It isn't detailed enough to turn directly into code because of the magic "two previous Fibonacci numbers", but the basic approach is solid. We could absolutely use this as a blueprint to start coding from, filling in the blanks as we go.

Since this is a demonstration, we're going to do one more round of pseudo-code to add some more detail.

In this round, we want a little less magic: How do we get the two previous Fibonacci numbers?

function fibonacci(n):
    // We can't get n-2 for 0 and 1, so return them directly
    if n is 0 or 1, return 1

    // Set these to the first two numbers of the fibonacci sequence
    prev1 = 1
    prev2 = 1

    // use 2 here because we've already done when n is 0 and 1
    loop from 2 until n:
        current = prev1 + prev2

        // Update the previous numbers, so we're ready for the next loop
        prev2 = prev1
        prev1 = current

   return current

At a glance, this looks completely different from our previous solution, but it's exactly the same. We've just clarified how we're going to store the previous Fibonacci values inside of variables.

This is now a complete solution. While there are some minor details that I may need to add when coding, it will translate into JavaScript almost 1:1.

JavaScript

This step should be self-explanatory. Take the pseudo-code code you have, and turn it into the final JavaScript.

You'll likely need to make some final clarifying decisions (like choosing to use <= inside of the for loop), but this should look very similar to your pseudo-code.

function fibonacci(n) {
    // We can't get n-2 for 0 and 1, so return them directly
    if (n === 0 || n === 1) { return 1; }

    let prev1 = 1;
    let prev2 = 1;
    let current;

    // use 2 here because we've already done when n is 0 and 1
    for (let i = 2; i <= n; i++) {
        current = prev1 + prev2;

        // Update the previous numbers, so we're ready for the next loop
        prev2 = prev1;
        prev1 = current;
    }

    return current;
}

This isn't the most concise solution to the Fibonacci sequence, but it is a perfectly valid one. It will definitely pass a coding interview.

As I said before, this may not come naturally to you at the beginning. The next step for you to take is to practice. You can go over to sites like HackerRank to try some of their coding problems, or you can start working on your own practice projects.

Are you stuck on JavaScript Tutorials? Sign up to my newsletter for articles to get you over the hump and working on the things you want

7 Pieces of Bad Advice for JavaScript Beginners

Carl Anderson — Mon, 29 Jul 2019 13:17:13 +0000

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"?

Having a hard time learning JavaScript? Sign up to my newsletter for articles like this straight to your inbox.

3 Techniques for Maintaining Your Sanity Using "This" in JavaScript

Carl Anderson — Wed, 17 Jul 2019 14:28:32 +0000

Of JavaScript's many confusing aspects, the keyword this can be one of the most complicated -- Here's a joke about the troublesome keyword:

// Detect dark theme var iframe = document.getElementById('tweet-578925947245633536-298'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=578925947245633536&theme=dark" }

this is frustrating. Every time you think you have it, another weird case shows up - it should be simple, so why does it never seem to work how you want it to?

Why "this" is confusing

In other programming languages, this always refers to the current instance of an object. It's a very consistent keyword which will only ever hold two values: the current object, or nothing.

In JavaScript, this refers to what is known as the execution context. In practical contexts, this is deceptively similar to other languages version of this, but contains a fundament difference: the execution context is different based on how a function is called_._

This means that JavaScript's version of this may have different values depending on how you called the function.

class Foo {
    text = "string";

    trigger() {
        // Because of how the function is being called, `this` can have
        // several different values
        this.text = this.text + "a";
    }

    brokenTrigger() {
        // `this` will refer to the current object, so it will act as we expect
        this.trigger();

        // setTimeout resets `this` to the global context object - in web
        // browsers, it is the Window object
        setTimeout(this.trigger, 500);

        // When we refer to the function directly (without the object)
        // `this` refers to the global context object (window)
        const unboundFunction = this.trigger;
        unboundFunction();

        // Event listeners replace "this" with the target element 
        // `this` will refer to the clicked ".triggerButton"
        let button = document.querySelector(".triggerButton");
        button.addEventListener('click', this.trigger);
    }
}

How to use `this` safely

When you see all the ways that this can go wrong, it seems like the easiest option is to throw your hands in the air, become a hermit and start a small potato farm.

In practice, this tends to be far less problematic than these examples make it appear. Most of the weird behaviours of this are easy to avoid by restricting your use of this to object functions, where it is the most consistent

As I said in the intro, using this with an object is almost always going to refer the object instance, but you do have to watch for two major exceptions:

setTimeout
addEventListener

In these cases, we have several techniques at our disposal to control the value of this, and to make sure that it works how we want.

Technique 1: Use Fat Arrow Functions

Fat Arrow Functions, aside from being a quick way of declaring functions, differ slightly from other function declarations in that they won't allow anything to overwrite this. Instead, it keeps the value from where the function is declared (its lexical scope).

What this means is that we can use them as wrappers, or directly as event listener function calls to preserve our this reference.

class Foo {
    listen() {
        // `this` still refers to Foo
        document.querySelector('.class').addEventListener('click', (e) => {
            this.handler(e); 
            // or
            this.val = 1;
        });
    }

    handler(e) {
        this.val = 1;
    }
}

Technique 2: Assign `this` to a variable

Before ES6, a popular pattern was to copy the value of this when we knew it referred to our object and used the new variable instead.

var foo = {
    listen: function() {
        // These are both common names for our new `this`
        var that = this;
        var self = this;

        document.querySelector('.class').addEventListener('click', function() {
            self.val = 1;
        });
    }
}

Technique 3: Explicitly set `this` with `Function.bind`

Functions come with several tools to set the value of this explicitly so you can guarantee the value of this.

Function.bind
Function.apply
Function.call

In practice, Function.bind is the most useful of the three, since it doesn't immediately call the function, instead returning a new version with a pre-set this, and any parameters you pass - you can use this new function directly in setTimeout or addEventListener function and keep your value of this.

class Foo {
    listen() {
        // The first paramter of `bind` is the new `this` value
        document.querySelector('.class').addEventListener('click', this.handleEvent.bind(this));
    }

    handleEvent() {
        this.val = 1;
    }
}

Bonus Technique: Use Strict Mode

JavaScript's Strict Mode slightly changes the behaviour of this. Instead of implicitly setting this to the global context outsides of objects, it causes it to be undefined instead.

In practical terms, this is a fairly minor change, but it prevents several incorrect usages of this, and cause a would-be-hidden bug to throw an error instead:

'use strict';
let obj = {
    update(val) {
        // Normally this will create an `x` property on the global object and
        // continue running, but in strict mode this will throw an error
        this.x = val;
    }
}

// Breaking the reference to `obj` causes `this` to be undefined instead
// of referring to the global object
let func = obj.update;
func();

Don't overcomplicate it

If you regularly read my blog, you'll know this is basically my slogan.

There's no denying that this is strange, but that doesn't mean that you need to worry about all the edge cases that it presents - More often than not, they don't come up.

I've been a Web Developer for coming on eight years now, and I learned some new edge cases about this when preparing this post that I have never encountered before.

If you're interested in learning more about JavaScript, you can check out this guide to closures, or read this article about what you need to know to start learning a front-end framework.

Having a hard time learning JavaScript? Sign up to my newsletter for articles like this straight to your inbox.

DEV Community: Carl Anderson

Break out of Tutorial Hell - What to Do When You're Going Nowhere

Why courses don't work

What you should do instead

No, People Aren't Learning to Code in 3 Months

3 Methods to Actually Remember What You Learn in Coding Tutorials

#3: Refactor the code

#2: Change, or add a new feature

#1: Create a similar (but different) project

The Danger of Specializing Too Early

How to self-teach JavaScript

Introduction Phase

Growth Phase

Honing Phase

When Are You Ready to Freelance as a Front-End Developer?

Should you freelance?

How to Get Past JavaScript Tutorials: Copy & Paste

Why you should Copy & Paste

How to code with Copy & Paste

Translate actions into code

You've made it work, now make it good

What to do next

Practice JavaScript by Breaking Things Down

Exercise: Breaking down Processes

4 Mistakes That Are Getting You Stuck Learning JavaScript

#1: You're not writing code

#2: You're trying to complete topics before moving on

#3: You're starting over again

#4: You're focussing on JavaScript too much

Disclaimer

How to Write JavaScript When You Don’t Know Where to Begin

How to break down problems

Writing in Pseudo-code

Example: The Fibonacci sequence

Plain English

Pseudo-code

JavaScript

7 Pieces of Bad Advice for JavaScript Beginners

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

#2: You should use this framework/library instead

#3: You have to be passionate to learn JavaScript

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

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

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

#7: You should learn this other language instead

Afterword

3 Techniques for Maintaining Your Sanity Using "This" in JavaScript

Why "this" is confusing

How to use this safely

Technique 1: Use Fat Arrow Functions

Technique 2: Assign this to a variable

Technique 3: Explicitly set this with Function.bind

Bonus Technique: Use Strict Mode

Don't overcomplicate it

How to use `this` safely

Technique 2: Assign `this` to a variable

Technique 3: Explicitly set `this` with `Function.bind`