Yes. Simply reading the official documentation (not the raw api-reference) is often underrated. Doing this avoids getting trapped in some third party blog or tutorial where the author completely misunderstood the topic, explains some old version, adds more dependencies than needed, or don't use best practices of the tool (W3Schools anyone?). Offical docs often have more explanation of the internal architecture and not just a cookie-cutter template to follow. Finally it eventually helps you get more acquainted with the official api reference which you are more likely to need in the future.
It can be quite daunting at first though. My strategy lately for this is
1) Accept that the documentation is big and will require some dedicated time for reading, not just a 10min elevator-pitch-tutorial between two meetings.
2) Skim through the table of contents, then continue reading the first paragraph of ALL pages and give each page glance. Write notes on which pages that you need to read and now and which ones you can save until you are web-scale. This step is important before you really start reading. It will teach you which topics that are important and give you a sense of exactly how much you need to learn, see it as some kind of internal progress-bar. You will also categorize which topics requires trying things out hands-on vs which topics you can bring to the tablet and read on the bus.
This step also helps you avoid traps you might end up in when reading things in order like "Congratulations for finishing tutorial 1, this was actually the old deprecated way of doing things, in tutorial 2 we will show the new better way of doing things and you will now truly understand the beauty of this improved design., or missing the last page on important security differences between debug and production mode.
3) Read. Now that you know the important topics and you've allow yourself to just sit down and just read them top to bottom. Allow jumping between topics if you get stuck somewhere. Set up a local environment to try things out on the way, confirm your assumptions, otherwise read more about that topic. Check the api reference if there are classes not described in the topics and figure out why.
From here you can transition more and more into innovative exploration and implementation of what you want to create, only reaching for the docs when you get stuck.
It can be quite daunting at first though. My strategy lately for this is
1) Accept that the documentation is big and will require some dedicated time for reading, not just a 10min elevator-pitch-tutorial between two meetings.
2) Skim through the table of contents, then continue reading the first paragraph of ALL pages and give each page glance. Write notes on which pages that you need to read and now and which ones you can save until you are web-scale. This step is important before you really start reading. It will teach you which topics that are important and give you a sense of exactly how much you need to learn, see it as some kind of internal progress-bar. You will also categorize which topics requires trying things out hands-on vs which topics you can bring to the tablet and read on the bus.
This step also helps you avoid traps you might end up in when reading things in order like "Congratulations for finishing tutorial 1, this was actually the old deprecated way of doing things, in tutorial 2 we will show the new better way of doing things and you will now truly understand the beauty of this improved design., or missing the last page on important security differences between debug and production mode.
3) Read. Now that you know the important topics and you've allow yourself to just sit down and just read them top to bottom. Allow jumping between topics if you get stuck somewhere. Set up a local environment to try things out on the way, confirm your assumptions, otherwise read more about that topic. Check the api reference if there are classes not described in the topics and figure out why.
From here you can transition more and more into innovative exploration and implementation of what you want to create, only reaching for the docs when you get stuck.