These are both great points.
Let me reply one-by-one.
- I fear at some point some longer explanation of some sort would be required.
The challenge is to break concepts down into small enough bits that a sentence or two will suffice. Show instead of tell - and do this through painstakingly designed tests.
Think about all of the complexity in a modern video game like Starcraft or Civilization. And yet, all the teaching is done just-in-time. People don’t generally read manuals, and video games have stopped even including manuals. Instead they have single sentence explanations peppered throughout the experience.
“Don’t shoot the food.” Why not? Oh, I shot the food and it disappeared, so I couldn’t eat it. With coding, these kinds of “teachable moments” are everywhere, and the consequences of mistakes are negligable - just hit the “reset my code” button and you’re right back “on the rails” where the tests want you to be.
Why should you generally use
=== instead of
Learning to roll up my sleeves, do my own research, being frustrated, waste days (that always in retrospection are never a waste but experience gained regardless) of time only to do what seems basic, but ultimately overcome them, is what made me the developer I am.
Same here! But I almost quit many times. And I was focused on learning full time.
Imagine if I had just come home from a full day of work, put my kids to bed, and finally sat down at the kitchen table. That’s most people who use freeCodeCamp. And these people tend to give up and then restart several times before they are able to successfully get a developer job. By keeping people on a “golden path” - at least initially - we are are able to keep more people progressing with their skills.
There will still be plenty of head-scratching once they get to the Required Projects. We can gradually ramp up the difficulty leading up to those, so it’s not such a steep learning curve.
That said I’ll see If I can contribute more concretely… looking at you flappy-bird-react
We would welcome your help with this. See whether you can build a bare-bones implementation for starters. Then we can work backward to break it down into a series of tests.