Hey ,
I'm thrilled to help you learn JavaScript. Unfortunately, you've landed on a page where you cannot access with your current purchase.
Please upgrade (use this link) access this content.
I'm super eager to help you learn more!
Do you stare at a JavaScript file, unsure how to begin, when you try to build things?
If you blank out, you’re probably afraid of failing. You’re so afraid that you’d rather wait for someone to give you answers than face the possibility of failing at creating something.
Many people who get stuck here call this the “coder’s block”. It’s similar to “writer’s block”, where a writer doesn’t know what to write.
But the good news is, coder’s block is a myth. You can overcome coder’s block easily.
To break out of coder’s block, you need to accept that failure is part and parcel of building things—you’ll get stuck, you’ll write shitty code, and you may feel like you’ll never be able to make that thing.
To get out of coder’s block, put aside the fear of failure and focus on these four steps:
Answer this question: “How do you put an elephant into the fridge?”
Most people would say:
Problem solved.
This answer explains why many people get stuck when trying to code—it skips steps; lots of steps.
Many problems remain unanswered in the “model answer”. If you think about it, you’ll know what questions remain unanswered. Here are some examples of what I thought up:
“Putting the elephant in the fridge” is a huge problem, and huge problems are hard to tackle. “Build the thing” is an equally big problem too.
To tackle the huge problem, start by breaking down the problems into smaller problems, as what I have done for the elephant-in-fridge question.
Don’t worry about the “correctness” or “size” of your small problems. Just break it down as much as you can for now. Write them all down.
Pick one of your small problems—any one of them—and start trying to solve them. Be as detailed as possible. If you can code, code.
For example:
At this point, you may realize that some problems remain too big to be solved. When this happens, you break that problem down into even smaller problems.
In the example above, answers #3 and #4 are still too vague. So, let’s break it down further and get some answers.
Once you have the answers to all your small problems, you’ve effectively solved the big problem. What’s left is to piece them together so your solution works.
In the put-elephant-in-fridge example, you can probably follow the following steps:
Problem solved. Sounds logical, yeah? (But as interesting as the elephant example sounds, you probably won’t be flying to Africa to capture elephants anytime soon).
It’s important to get practice breaking down big problems and then solving small problems; you’ll naturally come to an answer when you solve all your small problems. It might not be the best solution, but at least it works!
Once you get a solution that works, it might be time to improve the solution. If you want to improve your solution, proceed to step 4.
When you piece your solution together, you’ll probably end up with spaghetti code; it’s messy, ugly, and goes all over the place.
If you can spare some time, you might want to refactor your solution—improve it so the code doesn’t feel hacky and messy.
We’ll go through the refactoring process together in the best practices module.
Don’t worry about the quality of the code. If you don’t mind writing shitty code, you won’t have problems with your blank screen. Everyone starts somewhere. I started by writing shit too.
Break down your problems, find solutions and assemble them. That’s the nature of code. It either works or it doesn’t. Once it works, it works.
Don’t worry about improving your code now. We’ll do it together in a later module.