>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.
I 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.
The 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.
> 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.
> 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.
I like this technique, only thing I'll really disagree with is the usage of videos. I really hate videos as a medium for learning computer-related stuff. Just write down your explanation, maybe throw some images or gists in there, so I can go back without having to guess how far to go back if I need to.
Or if it's a "how-to" just make it a list. For example, I was trying to figure out how to do something in Windows the other day and all I could find were Youtube videos. Now I have to sit through someone's excessive intro for their channel with 382 subscribers and wait for them to get to the point.
It depends on the video. Some video courses are truly excellent (Shout out to https://egghead.io/series/getting-started-with-redux ), others are close to useless (so many "intermediate/advanced" pluralsight courses where the first 30m-1hr is installing visual studio!)
This is a good point I hadn't really thought about. For most tech stuff I've always got my head in a book, but when it came time to learn how to lift, my copy of Starting Strength only got me so far. It wasn't until I watched videos of others' lifting technique that I could really grasp some of the concepts.
I think videos are really helpful for absolute beginners. Technical blog posts are usually really dizzying if you haven't the slightest clue what's going on
On the contrary I find videos to be incredibly valuable. Humans can far more easily bring across the emphasis where it is needed and can far more quickly articulate key points to understand as opposed to reading lots of material and not necessarily grasping the perhaps small amount of information that really matters.
Agree, watching videos accelerates learning of swimming, skating or playing of golf; taking videos to grab programming stuff? Maybe, when you jog or you loose sleep, you can use couple of those courses.
looks like you're the 1 person in the world who is able to follow poorly written numbered howto's on technologies you don't know without getting stuck when it skips a step without mentioning it or properly describing it. you should go be a patent clerk!
My trick for getting through people's videos is 1.5x playback speed. use it. yeah I agree people ramble on and on and on.
This is the kind of advice that's too general to be useful. Actually, anything in the vein of "being more effective" is really difficult to effectively teach. The reason, I believe, is that productivity techniques always rest on previously-learned productivity techniques, and those are always practically inextricable from general life stuff.
You can't learn how to write like Stephen King by aping his methods. You're just never going to get there, doesn't matter how much effort you put in. Stephen King is uniquely suited to writing because he made himself uniquely suited for writing, and his method of writing is the product of decades of intensely personal iteration on not just "how he writes books", but also "how he lives life".
I think I accidentally down voted your post instead of up voted, being on mobile. Your point is so fundamental and profound. I hate to admit it, because it seems a bit defeatest, but far too many people ignore the role of the individual and their decades of built up experience.
This is really interesting to me. I used to do the strategy the author illustrates: follow along with tutorials and google when something doesn't work.
It didn't work for me at all. I found myself having gone through many, many tutorials (video and text) only to remember none of it when I came back to the subject months or years later. I never had any understanding because I was always following along and just googling when I ran into snags.
These days I do the complete opposite. I try to learn as much as I can. I never follow along with the learning material. Instead, I go through a section, taking notes, and then try to recreate it all from memory. Rather than focusing on what I need to know right now, I've learned to appreciate all of the little details. I try to do as much as I can with pencils and paper because it's slower, which forces me to spend more time with the information.
Indeed, I am very jealous of the author. It took me years before I learned how I learn. I wish that I was smart enough to use the author's strategy. Instead I found myself not knowing how any of my stuff worked, running into hours of frustration whenever I ran into a problem or a bug that StackOverflow couldn't answer. So if you've used the author's strategy and it didn't work, don't worry! We're not all geniuses! You will find out how you learn if you keep trying different things.
This is similar to how I had learned to play the drums, which I started few months ago. I didn't want to spend hours and hours of practicing the rudiment strokes (aka single/double strokes, paradiddles, etc). Instead, I had learned just the basic on playing of drums via Youtube and internet, and then off I went playing the drums to the beat of my favorite songs, trying to imitate the grooves and fills. "Playing" was equivalent to "building" stuff. It made the learning all too fun, no matter how badly I played.
Also, the best thing to speed up the learning process was to play "live" in front of an audience! It's equivalent to building an actual product (such as a website or an app) that you can show off to your family and friends, and the feedback was invaluable.
This parallels how I try to approach learning. For me, the "meta" idea is that I need some kind of mental model / framework before I can learn many details. Once that framework is there I can hang new knowledge on it without much trouble. So steps 1 and 2 are geared toward building that framework. Step 3 is about making things, which is where you'll spend a lot of time acquiring a lot of in-depth knowledge.
Seems like this approach fits a rather narrow band of stuff that is not really that hard. Learning programming, or even programming in general (the middle of that bell curve is your typical line of business app written in Java/C#) is in my opinion several orders of magnitude easier compared to say, developing reliable vaccines or building a modern reliable car engine. Also, this kind of technique is biased towards "building stuff" rather than holding off on building stuff till you can release software with zero bugs - which I would definitely categorize as hard. (Sure, for a hobby project, we don't really care about that kind of quality)
Its a shame that even top tier true-blue software companies like Google/IBM/Oracle/Apple/Microsoft continue to hire below average programmers who churn out code that needs to be constantly patched and fixed. It seems like nobody teaches people to value code that can run for a year without crashing or leaking memory.
So what's an effective way to learn to develop well engineered code? I'm at the point currently where I would not be able to predict how well a program will do running continuously.
It might seem weak to not have a good alternate solution when criticizing someones attempt at one, but I don't have a ready answer.
Well, okay so I'll try and give you advice anyway :P What kind of program is it? Is it a library, console/gui app? Does it have a variable workload? What are the ways in which people interact with the code? Is it primarily a desktop or server side application? What kind of test framework do you have in place? Do you have any instrumentation that would allow you to generate code coverage numbers? Can you run fault injection/fuzzing/etc type testing on it? Is the program resource limited? If so, do you have a CPU/Mem budget that you regularly check against? How many libraries does your program interact with? Do you keep track and test those libraries for failures? Do you try to freeze third party library/SDKs to minimize external bugs harming your own software's reliability? Do you always hard-crash at every bug or do you need to keep the software limping along till shit really hits the fan? Do you regularly (when there is no bug to track) run your software under a debugger to get a good feel for what the call stack, arguments, etc look like in a practical scenario (so that you can train yourself to catch it when things seem out of place). Its a lot about asking yourself what your blind spots are. Sometimes you have to think super-practically and just "look at the bits" and sometimes you have to try to see the forest. It all depends on what you're doing. And sure experience is a mean teacher. Nothing like getting a call at midnight and someone asking you why your embedded code running on-site in another state isn't working right after 5 months of no issues :P
* simple machines
* highly regular, not littered with corner cases
* state isolation, fast and easy to restart
* linguistically and semantically simple
The affordances of Erlang are a good starting point, as they encourage simple machines with isolated state while the language lacks the ability paint oneself into a corner semantically.
I've had the pleasure of working with Per (mrborgen) for a couple of years when he was the non-technical founder of our startup. Seeing him transform himself from a bizdev guy to a skilled developer in practically no time is truly inspirational. If I were looking for a coder I'd choose Per before most of my friends with comp sci masters and 3+ years of consulting experience. Hats off!
>Expect around 10 minutes of video to take an hour to get through.
As someone that's started to put together video instructions, it also takes an hour to put together 5 minutes of content. Because, while the first time it seems fine, it takes countless revisions to iron out assumptions of the audience and thoroughly explain things.
This techique seems to be similar to what you'd do to learn a foreign language. Start by trying to say simple things/phrases, hopefully from a native speaker. You may not understand any sentence structure or grammar, or have any actual idea about the individualness of each word. It's just a black box. But as you learn more black boxes, you start to notice small patterns that appear, and you can relate them together, and after a critical amount of memorization, the language slowly clicks. At this point, you start learning the theory/grammar structure, whilst adding to your vocabulary.
But, i don't believe this can be applied to subjects that have a lot of pre-requisites (a language, by definition, has no pre-requisits, if an infant can start learning it!). For example, you cannot learn calculus this way. You must learn the prerequisits (algebra in this case), otherwise it's too confusing and too complex.
To add something to the topic: I find that I usually don't use algorithms that I don't understand even if they are available. So, before firing up that convolutional neural network in mxnet, I need to be really comfortable with the theory.
I don't think searching for and showcasing someone's old, exploratory code really demonstrates much. A lot of my initial code for studying new concepts is atrocious — inefficient, memory-wasting, overly verbose; the point is to just get something that works and then later it can be refined, packaged up into modules, decoupled, optimized, etc.
Particularly for numerical and scientific work, there is a huge tradeoff between code cleanliness/readability and performance. I normally start by just copying the "demo algorithm" from a research paper straight into whatever language I'm using. The goal is to simply get the code working properly, and then I begin tweaking it for speed. Once it's optimized though, the result usually looks nothing like the original algorithm and it is difficult to tell what the code is doing just by looking at it.
Yeah, that was my very first one. I have since started with vectorized implementations instead of that clumsy way I did it the first time. However I found vectorization a bit tricky at first.
I'm actually planning to try and learn convolutional nets soon, and will try to setup a small study group online (basically just a repo with materials and a Slack/Gitter chat room), where people can help each other with learning it. Do you think that would help you to learn it?
Interesting how you haven't used any machine learning framework :) Did you do it purposely to get a better understanding of neural nets? Are you going to move to frameworks to speed up your iteration speed? Or are you more interested in maybe refactoring your code into a reusable framework? :)
Yeah, I wanted to understand how they worked, so I stayed away from any framework.
I have since moved over to using Theano, Lasagne & nolearn. However, I almost find it just as hard, because it's so easy to step wrong and get errors, and so hard to debug. In addition, Lasagne & nolearn doesn't exactly have great documentation of tutorials available (they have some, but I like to try out many tutorials to get perspective and get a proper understanding).
I'm far from good enough to turn my implementations into frameworks :p
>To add something to the topic: I find that I usually don't use algorithms that I don't understand even if they are available.
On the contrary, as everybody else does, you too do it all the time. There are thousands of algorithms hidden behind higher level APIs you use, which you don't understand.
Actually I learn trumpet for like a year and I got demotivated in part because with my teacher we were only doing exercises and learning music theory, but almost never playing a piece of music. I was able to play many notes and scales with the trumpet, but I didn't knew how to play a song (just a part of "When The Saints Go Marching In"). As I read above in the comments, replace "building" by "playing".
I liked the suggestions, but they only make sense if you know what you want to learn.
To figure out what to learn next you have to have some kind of filtering criteria or you will just be randomly jumping between technologies (which isn't a terrible idea for beginners, but would get highly wasteful for experts).
I find that learning in a project-based fashion solves this fairly well. Just focus on building something interesting, and in each case look for new technology that might help make the project better. Try to stretch your skill set when possible.
If something offers me an immediate concrete benefit, that provides a lot more motivation to learn it.
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.