3 ms·
>Use it before you know it: The first step you need to take in order to learn a new technology is to simply start using it before you understand it, which is a
by jasode 11y ago
>Use it before you know it: The first step you need to take in order to learn a new technology is to simply start using it before you understand it, which is a much better approach than trying to understand it first.
I won't dispute the strategy that works for him but that doesn't work for me.
For learning concrete languages & frameworks like his examples (React, Nodejs, Javascript), I prefer to read about motivations, architecture, and concepts, etc before downloading, experimenting, and typing any syntax. My brain needs internal "scaffolding" to strengthen the usage of unfamiliar syntax or else I'm just cargo culting. If I understand why React does what it does, it makes more sense why certain code goes in "this spot instead of that spot".
However, for learning other abstract topics such as monads, I would do the "learn it by many examples" approach the author recommends. I think the various metaphor-as-burrito tutorials for monads are not that successful for teaching. Instead, I suggest people just use monads like the Maybe Monad, Either Monad, IO Monad, etc. After a while, one will notice something in common with all those monads. That "common pattern" is the unexplainable monad. However, you can't get that understanding from reading monad metaphors -- instead, you extract that knowledge from the commonality of patterns hitting your brain at different angles.
- chubot 11y agoI think it's really about interleaving 'doing' and 'reading'. I used to be more of a reading person, but I find that I am a bit faster to learn now if I lean more towards doing. First I try to understand if something WORTH learning. For example, is R worth learning? Yes. Is React worth learning (for me)? Not sure yet but I'm keeping my eye on it. Then I try to first get a "hello world" running without too much understanding. This can actually be the hardest part... building software is sometimes harder than understanding the ideas :) And once I have hit a wall playing with things, then I need to go back and read some more to figure out the concepts. Once you've played with enough software, you can get surprisingly far just by doing things, and actually learn the concepts. Other times you can get stuck and need to go back and do some research.
- sitkack 11y agoThe doing gives context for the reading phase. Without it, there is no place for the concepts to attach in the graph of knowledge. It is similar to skimming a book to get structure, knowing the destinations allows the journey to make more sense.
- catnaroek 11y ago> After a while, one will notice something in common With two caveats: (0) There's absolutely no guarantee that you'll eventually see the pattern. Most people don't, no matter how many times they bash their heads against it. (1) If your examples aren't “diverse enough”, you risk not grasping the full generality of the abstract pattern. This makes me wonder how many Haskellers think a monad is necessarily a monad in Hask.
- shubhamjain 11y ago> I prefer to read about motivations, architecture, and concepts, etc before downloading, experimenting, and typing any syntax. Personally, it is sometime along the road of building something with the tool, the architecture starts making sense . I can hear all the conference videos and read the articles about the tool, but it won't feel awesome unless I start using it and find it better than what I did before.