Applied Learning
Trying to learn things without being able to apply them can be very ineffective.
I’ve "learned" at least half a dozen programming languages I never ended up using on a regular basis. I did not retain what I learned (and I suspect my understanding was mostly surface-level since I didn’t write programs beyond the exercises).
(But the languages I use on a regular basis are practically muscle memory for me.)
I also struggled to learn mathematics on my own until I started writing a ray tracer. Now I had a reason to deeply understand the math. And that reason makes all the difference for me. I don’t find the math itself interesting enough on its own. (Though I often wonder if that would be true if we didn’t have computers at all.)
This also ties into The Phenomena of the Game Manual.
Sean Cribbs on implementing what you’ve learned
In his 2015 talk "The Refreshingly Rewarding Realm of Research Papers", Sean Cribbs (seancribbs.com) describes an 'ideal' process of reading a (computer science) research paper and how after reading comes implementation. But he admits that he doesn’t work that way. Instead, he does what I always do. Sean says:
"I don’t usually do an orderly step-by-step process… I usually start writing the code while I’m reading the paper… Coding it helps me understand. I don’t think I’m the only one who does this."
I couldn’t agree more. My learning process for a new subject is super messy, but it looks roughly like this:
-
Read until my eyes glaze over, think maybe I got it
-
Try to implement it, realize I didn’t even understand enough to start
-
Read more carefully, knowing what I don’t know
-
Pretty sure I understand it now
-
Try to implement it, immediate failure
-
Read even more carefully. Say, "ohhhhhh!" a lot. Slap my forehead.
-
Get the program working, often by deviating from the suggested implementation, but with a whole new understanding of the suggestion that enables me to do my own thing.
Sean lists this advice for implementing what you’ve learned from a research paper:
"Use familiar tools… If the paper describes something in Lisp but you really know Python, maybe you should use Python the first time around. (That said, some reasearch does depend on a certain programming paradigm and outside that paradigm it doesn’t make sense.)"
(Note that I’m quoting both his slides and his spoken words in the talk.)
I completely agree. In fact, I think that even has advantages because I think porting software is an awesome way to learn even more deeply.
"Beware psuedocode and reference implementations… Don’t worry about the individual steps [the author] takes… There may be one key place where…Handwave! Be keenly aware of what they leave out of the code samples… A similar warning for reference implementations: there is a trend lately that research papers are trying to become more repeatable… (This is old hat for the hard sciences…) For most reference implementations, think of them like the most minimum of MVPs. They’re like the weekend hack you use to prove the concept before you throw it out and write it for real.
(MVP is Minimum Viable Product)
"Prepare to write and rewrite (and rewrite). Especially if you’re like me and you like to code as soon as possible. Be prepared to throw it away multiple times."
Ha, exactly like my list above!
"Test early, test often. These are great sources for writing tests… My code does what the research paper says. I love using QuickCheck (?) for this."
At first, I thought he was saying "quicktype" and I found a software thing by that name that didn’t look right.
But then a Youtube commenter heard "quick check" and that turned up:
QuickCheck is a tool for testing Haskell programs automatically. The programmer provides a specification of the program, in the form of properties which functions should satisfy, and QuickCheck then tests that the properties hold in a large number of randomly generated cases. Specifications are expressed in Haskell, using combinators defined in the QuickCheck library. QuickCheck provides combinators to define properties, observe the distribution of test data, and define test data generators.
And that sounds right.
And sure enough, if you do a Web search for "quickcheck for <popular language>", results come right up.
Sean ends the talk with:
"Read papers! Write code! Meet people! Improve your craft!"
See also: