Monday, 23 October 2017

Learning To Learn

I love learning. Even when not successful at applying it all, I generally get at least something out of it.

Recently, I’ve been learning a new language. Rather than a new programming language, though, I’ve been trying to learn Russian. It’s something I’ve attempted in the past, using Rosetta stone and Pimseleur CDs (none of which were pirated copies, I swear…). It helped but ultimately didn’t provide any sort of lasting success.

As I researched different ways to tackle it this time around, though, I stumbled upon Gabriel Wyner. My inner-geek really enjoyed the way his methods all tend to have evidence-based researching supporting why and how they work. Things like spaced repetition systems, using the International Phonetic Alphabet to help properly learn pronunciation early on in the process, learning concepts in the other language rather than simply ‘translating’, etc.

I found podcasts he had been interviewed on, read his book (Fluent Forever), and decided to back his Kickstarter campaign.

All of this was interesting to me, but at the time I didn’t think there were any obvious tie-ins with software development. I recently watched a talk by Edward Kmett called “Stop Treading Water: Learning to Learn“, which changed my thinking on that…

It covered similar topics as Wyner, but from a computer science and mathematics perspective. Definitely an interesting talk.

By the time I had finished watching it, I was able to see how some of the techniques I’ve been using for learning Russian can also be applied to learning other development languages or even just solving problems in languages I already know.

Of the takeaways from the talk, there were two concepts that stood out the most as being applicable for me. The first bit of advice is to dive deeper whenever returning to a topic. That way, concepts and methodologies remain fresh and are easily-accessed when needed. It’s sometimes easy to just go for the ‘quick win’ of solving a specific and moving on without spending much time understanding how that solution is working behind the scenes at a lower level. The second takeaway is that even though you should be willing to abandon things once a solution is determined not to be appropriate, it shouldn’t be abandoned simply because it is hard. I know that’s some I sometimes struggle with…