How I Learned to Learn
Every week I come into contact with over 20 programming languages, frameworks, APIs and other things I need to know. This is not remarkable for someone in the business of software development; there are many web technologies available - each regularly expanding its capabilities - and they may be connected in countless ways. However, there are common rules and patterns shared amongst them all.
As an applier of these technologies, it is important to have a process for spotting the commonalities and being able to efficiently learn (or relearn) what you need to know and recognise the things you do not.
The realisation
I initially thought the road to mastery was through rote memorisation. My reasoning was if I got faster at mentally retrieving syntax to make my thoughts a reality, I would reduce the cognitive barrier to truly efficient expression. In their book, Made to Stick, Dan and Chip Heath explain this is common for novices. People inexperienced in an area see concrete details as suitable to build a greater understanding upon, but lack knowledge of the larger context. Experts instead see the same details as examples of greater patterns and appreciate that by themselves, these details have limited applicability outside the context that they were encountered. Their experience causes them to focus on recognising and remembering those larger patterns, which have a much wider applicability.
I came to see this myself. The languages I used changed; my understanding of what paradigms and constructs were important shifted; and APIs and interfaces evolved. It turns out that most of software development is understanding and adapting code, not long periods of synthesis. It’s more like editing than writing, and although an understanding of the proper grammar and vocabulary remain essential, its not the bottleneck in taking the code that you have and making it the code that you need.
When writing new code, a responsible developer will use well-established modules already written and tested by many contributors, whenever possible. So development often involves connecting components together, placing them within a larger architecture and wrapping them in logic to serve your needs. Each module has its own interface and must be adapted to work in harmony with the rest of your system, so you must learn its capabilities and limitations.
However, a developer’s job is often not to learn a software tool or component deeply and completely, but to establish a working understanding as quickly as possible: to see the utility of a tool, it’s limitations, stability and how it compares to its alternatives. It also helps to learn compatible design patterns, paradigms and conventions to ensure you are using the tool as intended. This process involves holding a great many things in your mind at once, just long enough to make the necessary design decisions or implementations before moving on and establishing an entirely new mental context with different requirements and options.
I realised it wasn’t an effective use of my time to memorise the minutiae of the components I was using. It was slow and the value was often more short-lived than I anticipated. It was better to leave this to the syntax highlighting and auto completion of a good IDE and linter. Instead I found it more efficient to memorise where to retrieve important information when I needed it: valuable resources, search terms and people that I could consult. Eventually I grew comfortable with knowing I knew where to find something, but couldn’t recall it immediately - even if it made me sound less intelligent in conversation.
The system
I maintain a collection of bookmarks, carefully organised and labelled by the value it offers to help find what I am looking for when I need it. I drew inspiration from David Allen’s description of a reference system in his book, Getting Things Done. In particular, there are no time-sensitive or actionable items included (these go into a separate system). There are no front pages of news outlets or blogs, or any other site that favours new content over the valuable - direct links to articles are fine. This is also in accordance with the idea of Just In Time Information as opposed to Just In Case Information, I first encountered listening to the Tim Ferris Show podcast. I do not want to be distracted by the bleeding edge of a technology I do not currently need. I review the collection to prune links no longer of use and to maintain an awareness of what sort of information is available.
Bookmarks are quick to create and maintain, but they point to entire documents and don’t help with digesting the information they contain. Each time I read something, I want it to be easier to retrieve the information I need or I am not much better off than using a good search engine. I use highlighting and virtual sticky notes for this.
For a while I worked with this combination of bookmarks and annotations with measured success. I organised the bookmarks by situations and each document was annotated so it was trivial to locate what I was looking for. But the list of bookmarks quickly grew and I began to realise a problem. I discovered I would often need several bookmarks to provide an adequate explanation complete with all important caveats or limitations. It became harder to organise these similar bookmarks as they each provided part of a larger truth and were incomplete without the others.
In Peter Sim’s book, Little Bets, he writes of how innovation more closely resembles gathering insights rather than isolated acts of inspiration. He challenges the notion that these insights are siloed within a small number of resources and argues they are instead far more distributed across domains, and experts and novices alike. I was having a hard time connecting these insights from different sources as they were modelled as separate links, with no relationship information between them. So I started using Evernote to create summaries of the highlights and notes I was making on some of the more important documents I was linking to. This allowed me to rephrase, reorder, compare and juxtapose ideas and information and organise them in ways that best served me and my needs.
These notes are like living documentation and are constantly updated with additions and modifications as with each revisit of a subject I strengthen my understanding and I want this reflected in my notes for the next time around. Occasionally, they cover a subject that changes regularly and the information must be updated to avoid being out of date.
This system has worked well, helping me to reach a better understanding of many concepts in a shorter period of time. And whenever I need to revisit a subject, I have a handy set of cheatsheets to get me back up to speed quickly without having to consult the source material once more.
The process
I annotate almost every page that I read when I am looking for particular information. It helps me keep track of where I am and makes me more resilient against disruptions. It also gives me the freedom to skim a document without losing track of where I have and have not read in-depth. If the document is a concise summary of a particular concept or piece of information that I believe I will need again, I add it to my bookmarks, labelled as what was useful about it. If the page forms part of a larger series of documents I have consulted on the subject that have yielded useful information, I start a new set of notes in Evernote to summarise and reorganise the information. If I end up doing this, I save a link to the original document in the notes for further reference.
I try not to copy information verbatim from the source material. This is not conducive to deeper learning and is an indication of time poorly spent. Unless I know I need information from a document available offline, it is better to simply link the original document rather than copy it out exactly, as little is gained in doing so.
When faced with a new library or language, I attempt to gain an understanding of what the entire documentation covers. I apply the 80/20 rule and spend a relatively large amount of time learning a relatively small amount: the fundamentals. It is here that I am looking for the patterns and the similarities and differences with the things I already know. I am not concerned with the details, as these are often unimportant until I have a better idea of what I need to know. I make highlights and annotations and then notes which I perform multiple parses on to make more concise. I then spend a little time getting to know what the rest of the documentation covers, so I know where to find this information when I need it. I may create some further bookmarks at this point to help remind me of what resources are available and what they contain.
In hindsight, taking notes on what is important and not wasting resources committing irrelevant details to memory seems obvious, but I wish someone had explained to me when I was starting out the dynamic nature of full stack development. Or perhaps warned me that mastering a single area of expertise and then expanding radially was likely to be costly in time and effort, as much of what I learned was rendered inapplicable when external requirements inevitably changed. Or that no matter how dedicated I was towards learning and remembering new information, the rate I would forget things - especially when switching between similar contexts - would barely be outpaced by the rate at which I learnt new information, so I needed a way of externally recording it to be able to quickly refresh my memory. But above all, that learning how to learn and re-learn things quickly would be the most valuable skill I could attain.