As I begin trying to learn new frameworks/languages/paradigms etc., I find that rather than taking a deep dive into learning that specific thing, I...
For further actions, you may consider blocking this person and/or reporting abuse
tl;dr: make time to play and work so you don't restrict yourself, and mark the location of rabbitholes to return to later if you really do have a certain route you have to be on in the meantime
As a beginner, one thing I've noticed is that while those rabbitholes can absolutely become endless timesinks, I not infrequently do learn from them--sometimes not much, but it does often mean that I at least know what to try and where to start looking if I get stuck.
A rule of thumb that helps me is: if I have to keep looking up the same thing or keep getting stuck in a similar area, that's something I should dig deeper into, because it's either common enough to recur and/or important enough to recur. Shallow depth is OK for some things that you won't use frequently--as long as you know enough to be able to understand the solutions you look up and find when things go wrong.
If it's a particularly enticing rabbithole, I just bookmark/Pocket all the tabs and then close them--it satisfies that need to look around and poke at the edges of a topic all over, without the time commitment if something needs to be happening on a specific timeline.
But honestly, I think it does depend what stage of beginner you are to a given thing. For someone like me who is new to programming overall--rabbitholes are going to statistically be more fruitful because there's more I don't know, and while they're often important topics, they're baseline enough that delving into them is almost assuredly worth it. For any new endeavour, I think making time to let yourself dive into those rabbitholes is really important, even if you're not new to programming overall, but the field is new. Rabbitholes about Coffeescript when you're already very proficient in JS are neat, for example, but not as useful as, say, Python rabbitholes would be to someone trying to learn Python who is proficient in JS.
Thank you for the great answer! I definitely agree that you should allow more time for a completely foreign topic than something you are more familiar with. One thing I am terrible with, that you touch on here is that you can come back to things if you are on a deadline. In most cases where I am learning something completely new, I feel a need to build something quickly and to do it well. I am not sure where this feeling comes from, but in almost all cases these are side projects where the only real deadline is one that I set. Maybe I need to recognize that and allow myself more time, rather than pushing myself to learn/skip things in order to see some arbitrary result.
React tech itself isn't all that complicated. The problem is when you start needing all these other frameworks to get a decent workflow: code, build, run, debug iteration loop.
Rabbit holes are great and you should really learn how the different frameworks work, eventually.
The problem I can see is that you end up reading more than doing and that hurts retention of the knowledge. I would recommend following any tutorial to just get you up to speed on a good code, build, run, and debug cycle then deep dive into a particular topic. That would help you understand where that framework/language/paradigm fits in the scheme of building the product.
I definitely agree, I think there is a danger of reading so much and not really retaining it. It's something i have a problem with myself at times. At a point I just try to force myself to experiment with what I'm reading about which can help me wrap my brain around the new concept.
I have tried forcing my way through some things, I always find my mind wandering back to other things mentioned that I do not know about. The danger of reading too much is real, somewhat like drinking out of a fire hose.
Thank you for the response and advice!
Hey Justin,
Thanks for the advice! I will definitely do my best to avoid reading more than doing!
Follow a structured guide and stick to it. Don't derail yourself by commiting to more courses and tutorials that aren't needed. Most of the resources are the same. Also when you are following a tutorial or guide you won't accidentally learn something that you shouldn't.
Zane,
That is a really good point about courses keeping you on track. That seems to be a common theme in the responses, I will definitely have to look more into that space!
Thanks!
I've found that once you have a sufficent level of familiarity with the thing you're learning, the best way to progress is to find a problem to solve and then use the resources you've found as a means to that end. It's nice if it's some little app that would actually be useful to you, but artificial puzzles (e.g. katas) or copied app ideas are fine too. Either way it helps focus your attention on the important parts and should give you "ah-ha!" moments where you finally grok any tricky concepts.
If you find a problem that you find particularly interesting then feel free to re-use it when learning other languages or technologies. Although in some ways it's not as satisfying as solving/implementing it for the first time, having a problem you already know lets you focus on the technology you are trying to learn. Also reimplementing the same thing in another language can help you to truly appreciate its differences, so long as you are careful to use it idiomatically.
The internet is a rabbit hole.
I recommend avoiding it by having someone guide you through learning the new skill. Be it a book, a course, a mentor.
David,
Thank for you for the feedback! Maybe I am too relaxed in my learning and something like the things you recommend above would fit my learning style better than searching around the internet for any resources.
If you have unlimited time, the rabbit hole is amazing. So much to discover. But if you have restrictions (e.g. a project deadline), finding some guidance is probably the better choice.
Anyhow, it's always hard to guess how long learning a certain thing will take.