Efficient and Effective Learning (Or: How to Study Code?)


Something I’ve really been struggling with in regards to learning to code is how to do so efficiently and effectively. I think that not knowing if I understand something “well enough” and whether I should be taking notes (and on what?) and whether I’m ready to move on is a real hinderance to my progress.

I’m beginning to understand that being able to research solutions and learn quickly are both important skills. I question all strategies I’ve previously employed, such as reading textbooks and taking notes. If I am to learn Ruby and then find a job which requires Go, I suppose I’d want to be able to learn Go efficiently and effectively as opposed to deeply internalizing the language principles. So shouldn’t I practice learning Ruby in the same way?

I know I’m rambling a bit, but I’m really just at odds with regards to building a very strong foundation, but practicing the appropriate learning skills, considering I don’t seem to know what those skills are. Any guidance on the topic is appreciated!


Here’s what I’ve learned about myself, re: studying code:

  • Reading/taking notes works only to a certain extent.
    The best test of my mastery is whether I’m able to explain the concept in writing or out loud to someone, aka teach.
  • Reading code/watching someone code is also only good to the extent that I can then recreate it from scratch afterwards.
    Sometimes I’ll watch a video, think I understood it completely, then blank on how to write the syntax (or make a syntax mistake) when it was my turn to practice. Also, I spent too much time reading through the Eloquent Javascript and You Don’t Know JS series in study groups, and not enough time just writing functions and solving basic algorithm problems on leetcode or codewars, which in some cases does a better job refreshing the fundamentals of a language.
  • Build a project from scratch in a language I’m learning.
    I think this has also helped unveil concepts I thought I understood but didn’t really understand until I had to try to implement it via code. But also, it’s just plain fun to build something and have it out in the world.
  • Ask questions early, and ask someone more experienced to review my code.
    I’ve gotten stuck countless times and wish I’d asked for help earlier from someone who was simply more experienced. Right now it’s my mentor at work.

Typed this out in a very rambling way just now late at night, so apologies if it’s not all entirely coherent. I hope these thoughts about the lessons I’ve learned over the years help.


I’m really interested in the various paths people take to learning something. I’ve been working on a proposal for a talk that explores how I went about learning Go. I think I know what I want to say, but am struggling to make it something I can sell to a room full of Go ‘experts’ so am not sure I’ll get to give the talk.

Work in progress slides are here:

It has been interesting to look back over my journey and try and extract the key things that made a difference to the path I took. I found that the more blog posts I read and talks that I watched, the more I became aware of topics but the more I struggled to understand why any of these were useful. I’d never faced any of the challenges that led to the solutions or approaches being discussed.

So, I set out to work on projects and see where it led. I’m quite good at inventing projects to work on that strike a balance between what I want to learn, a personal interest, and work relevance. This has been key to staying motivated as I’ve gone on.

The solitude of individual projects is something I’d love to address. I haven’t yet found something/someone that forms the start of something collaborative. It’ll come though.

So, back to your original question… people could preach all they wanted about the language principles behind Go, canonical this, canonical that, it was all interesting but it just didn’t stick and it didn’t help me write anything meaningful. The only way that I felt as if I was making effective progress was to bit off something a little more complex than I was ready for and then to see where I got stuck.