If you're just starting out, skip down to the tabs above and start with basics.html, then variables.html, then functions.html, then loops.html. They go in that order for a reason. Come back to this page whenever — it's more of a reference than a lesson.
You will forget what "data" holds by the time you're done writing the function it's in, let alone next week when a bug shows up in it. If it's a list of users, call it users. If it's the count of failed logins, call it failedLoginCount, not counter.
Yeah, it's more typing. It's also the difference between reading a bug report and understanding it in five seconds versus having to trace the variable back through four functions to remember what it even is.
Most errors tell you exactly what's wrong and on which line. "Cannot read property 'name' of undefined" means something you expected to exist doesn't. Go to that line, print the thing right before it, and you'll usually see the problem immediately.
Pasting the whole error into a search engine before reading it means you skip the ten seconds that would've solved it yourself.
One commit that says "stuff" with 40 changed files is useless to future-you. If something breaks two days from now, you can't tell which change caused it because everything happened in one blob.
Commit each time you finish one small piece and write what actually changed, not "updates". Then git log actually tells you something.
Copy-pasting a tutorial's code feels productive but you retain almost nothing from it. Your brain isn't forced to notice syntax, indentation, or why a line is written the way it is.
Type it manually, even when you make typos. Fixing your own typos teaches you what breaks and why, which is most of what debugging skill actually is.
// increment i by 1 above a line that says i++ tells nobody anything they couldn't already read. What actually helps is explaining why a piece of code exists when the reason isn't obvious.
"// doing this because the API sometimes returns null instead of an empty array" is worth writing down. That's the kind of thing that gets forgotten and rediscovered the hard way six months later.
You don't need fifty shortcuts. Multi-cursor select, jump to definition, and rename symbol will save you more time than almost anything else, because you'll use them constantly without thinking.
Most people know these exist and never build the habit. It takes about a week of forcing yourself before your hands do it automatically.
"It doesn't work" tells nobody anything. "I expected the button to show an alert, but nothing happens when I click it, and there's no error in the console" is a question someone can actually answer.
Writing it out this way also makes you re-check your own assumptions, and a decent chunk of the time you'll spot the bug yourself before you even finish typing the question.
A finished project that's a bit messy teaches you more than an unfinished one that's perfectly architected. You learn the most in the last 20% of a project — deploying it, fixing the edge cases, dealing with real input.
It's tempting to restart from scratch once you learn a "better" way to structure something. Sometimes that's right. Often it's a way to avoid the boring parts of finishing.