
An Easy Way to Learn Hard Stuff - mrborgen
https://medium.com/learning-new-stuff/a-simple-technique-to-learn-hard-stuff-ffaa7879bf7c#.lubnbmj5y
======
jasode
_> 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
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.

~~~
sitkack
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.

------
jgh
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.

~~~
xiaoma
I think videos are horrible for learning things like Math, CS, languages,
psychology, economics, etc.

But they're great for learning how to use an IDE, graphic design, music,
athletic movements, etc.

~~~
marpstar
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.

------
vinceguidry
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".

~~~
d23
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.

------
such_a_casual
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.

------
otterpro
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.

------
dwc
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.

------
ksk
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.

~~~
chris11
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.

~~~
ksk
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

------
habiteer
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!

------
zhte415
>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.

But the end result is definitely worth it.

------
chii
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.

------
nitwit005
Would not recommend starting out in civil engineering by going ahead and
building a bridge after watching some YouTube tutorial videos.

This advice can only really be applied in areas where there are no legal,
safety, cost or time barriers.

~~~
sitkack
That isn't charitable. My take is that the op would advocate building a
Popsicle bridge per day, each able to take increasingly excessive loads.

A civil engineer should have many fully understood failure modes under their
belt.

------
visarga
Funny implementation of a neural net from the author. I guess it teaches you
how it works.

[https://github.com/perborgen/NeuralNetworkNoob/blob/master/n...](https://github.com/perborgen/NeuralNetworkNoob/blob/master/net.py)

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.

~~~
mrborgen
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?

~~~
ratsimihah
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? :)

~~~
mrborgen
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

------
WWKong
I just started out learning to build iOS apps. Along the way I'm creating
video tutorials, sharing sourcecode etc., that is mentioned here.

If you want have been on the fence about learning app development, this should
get you started right now.

[http://buildanappwithme.blogspot.com](http://buildanappwithme.blogspot.com)

~~~
potatote
Thanks for sharing your journey like that. I have added your channel to my
watchlist on Youtube and will be learning from it very soon.

------
swehner
At first glance, it doesn't help much for learning trumpet.

~~~
ratsimihah
You don't understand trumpet until you build something with it.

------
jeffdavis
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).

~~~
CuriouslyC
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.

------
LinuxBender
This probably works for most things, but I will likely still watch training
videos and get some lessons before parachuting.

