Figuring out where to start with a new programming language or framework can be challenging. Searching for advice can inundate you with long lists of prerequisites and concepts to learn. Forums will turn up tech veterans that demand newcomers "start from the ground up".
The newcomers should know the fundamentals before they even begin to touch that framework or library. For them to do so would be to meddle with things beyond their comprehension. Heavens! It could lead to their breaking the fabric of the Internet. Or something.
I'm sorry to say I opened Pandora's box and it worked out just fine.
I didn't know Ruby before I started learning Ruby on Rails. I learnt the two in tandem. Sometimes it was confusing what was Ruby, and, what was Rails. I had a decent grasp of desktop software development, but not web application development. I didn't have a clear knowledge of REST architecture.
Regardless, I ended up proficient in Rails because I took on personal projects, and was keen to see my ideas realised.
Start with a vision
"Come up with a project idea you'll enjoy and try to build it" has been a mainstay of advice to anyone I've met learning to code over the years.
There's a terrific post from Ian Johnson called 'How do you learn d3.js?'. In it he asks several well-regarded information and visualisation designers about their respective journies. All of them mention a vision of telling a story with data or creating something that didn't exist before.
It's reassuring to know this approach works for others and not just me.
Why projects?
Getting excited and remaining engaged is one of the main reasons I advocate taking on a personal project. That motivation will provide the fuel for you to continue.
Motivation isn't the only reason. When you try to realise an idea you'll be required to overcome equally unique challenges. There may be examples and libraries to help, but you'll need to adapt any prior content to the context of your project. This process of creative synthesis is of a higher order of thinking and problem solving.
You might find it ambitious to set to work on a passion project on day 1 of learning a new technology. Still, it's definitely worth thinking about. Contemplating your project vision is a way to set your mind in motion.
Carrying that vision with you while you're learning will predispose you to notice important details that crop up in lessons or in your own reading. You can think of this as a net, deployed subsconsciously to gather valuable nuggets of insight.
Constraints can guide
Building a project may sound unstructured compared to following a set syllabus or roadmap, however, choosing a project provides constraints. Constraints are your friend because learning any technology can be overwhelming. There are heaps of resources on the web. This should make things easier but unfortunately it can make life hard when you're unsure where to start.
If you're able to break down the component requirements of your project, you'll have a roadmap to guide you.
Let's say your aim is to create your first data visualisation using d3.js. It doesn't involve any interactivity or fetches of remote data. That's fine. You can dispense with chapters on event handling and asynchronous programming. You've just saved yourself a lot of energy and time!
Caveats for project based learning
I believe those are the strongest reasons to value a project-based approach to learning. There are some other benefits too such as building up a portfolio of projects for demonstration and providing a sense of achievement. That said, I'd like to add a few caveats.
Caveat 1: Don't bite off more than you can chew
This sounds a fairly obvious point to make. Taking on something too complex will lead to frustration. You knew that part. The thing is, experienced developers occasionally underestimate how complex projects or features may be. You will do the same. I recommend choosing projects that you can add to and enhance over time.
Caveat 2: Recognising when to step back
At some point working on your project you'll get stuck. Most of the time (hopefully) you'll be able to debug or Stackoverflow your way out of it.
There may come a point where you're really stuck. Not only that, you're not sure what to search for, or even how to articulate a request for help. This is a sign you need to learn more about an underlying technology or a fundamental concept. Step away from the project and pick up a book.
Alternatively, this could also be a sign that you're not getting all the information you need to diagnose the problem. You may need to learn more about the ways you can make use of your IDE or developer-tools to set breakpoints, read, or output logs.