Perpetual Learning is the greatest constant in a Software Development career (at least if you do care about your career). The technology landscape changes too fast and we need to keep up. That’s just the way it is.

Although ideally the learning process should be constantly happening all the time, there are some special situations when you just need to learn a lot in very little time. This usually happens when you’re switching jobs and need to grasp the new company’s entire tech stack as soon as possible. Or maybe your current company decides it’s time to keep up with the new technologies and revolutionize their own stack. In either case, that’s usually when you need to learn tons of different new stuff in the shortest amount of time — and learn it as deeply as you can.

After being in that kind of situation for more than a few times, I’ve decided to share what have worked best for me. It all boils down to three main points:

1. Choose the best technical book (or online course) you can find on the subject
2. Create and use flashcards as you read through the content
3. Review the flashcards and do “micro-katas” in a daily basis

So let’s break it down.

Choose the best technical book (or online course) you can find on the subject

This seems to be a simple one, but in reality is not. In order to learn in the shortest time possible, you need to get the best material you can put your hands on. Besides limited time, we also have a limited amount of mental energy, so we need to make sure we are investing both in the most cost-effective asset available.

I am more of a book kind of guy, but many people seems to learn better and faster with online courses. That’s fine. Ideally, you want to mix them up to get the most out of both. But usually time is a big constraint here, so you should go primarily for whatever works best for you.

Regardless of which one you choose, the traits you are looking for in the material are the same:

– Objectivity. This one is huge. Some authors will just keep rumbling and rumbling before make a point, or give way too many examples, or simply be more prolix than they should be. Everyone has read something like this before: a book that feels weirdly heavy and tiresome to finish two simple pages. And when you finally do, you get the feeling that you didn’t even get that much information out of those pages. Stay away from those books as much as you can. Prefer the texts that offer you the most information through the least amount of words. But do that without sacrificing Technical Accuracy.

– Technical Accuracy. Although objectivity is key, it should not come at the cost of technical accuracy, correctness and completeness. Some books seem to be short and direct at first, but in reality they are shallow and superficial. The feeling you have after you finish a given section is that you didn’t really get it: You didn’t fully grasp what the author was trying to convey. Then you go back and read it again, and you still get the same feeling. And in the end, it doesn’t really matter how many times you read, the information and completeness you’re looking for are just not there. Avoid those books too. You will probably loose too much time when you have to re-study everything from a better source afterwards.

Research first

Before you effectively begin your studies, spend some time looking for the best book/course out there. Usually, just by reading/watching a few sections of one given material should give you a sense of how things are communicated on it. The critical aspect here is to find the right balance between completeness and objectivity. Some great books I can give you as an example are Martin Fowler’s Refactoring and David Flanagan’s excellent JavaScript: The Definitive Guide.

Note that both books that I mentioned are not short ones. You’re not necessarily looking for the shortest material, but instead for the one with the best accuracy/objectivity trade-off. After all, you want the deepest domain of the subject, in the shortest amount of time.

Create and use flashcards as you read

Once you have chosen the right book, don’t just read it passively. We all know that we can’t really learn a technical subject until we try and experiment with stuff. But besides that, there’s one more crucial thing that you need to manage in order to get a deep grasp about whatever you are trying to learn: your memory.

Even if you read, understand and experiment with every little peace of information you come across, you will still forget almost everything you’ve learned in no time (unless you have some kind of Eidetic Memory). That’s just the way the mind works. In order to fix this, we need to resort to spaced repetition; and the best tool out there to help us to do that, in my experience, is the infamous flashcard.

What is spaced repetition?

According to Wikipedia:

“Spaced repetition is a learning technique that incorporates increasing intervals of time between subsequent review of previously learned material in order to exploit the psychological spacing effect (…) Although the principle is useful in many contexts, spaced repetition is commonly applied in contexts in which a learner must acquire a large number of items and retain them indefinitely in memory”.

What are flashcards?

Also according to Wikipedia:

“A flashcard is a card bearing information, as words or numbers, on either or both sides, used in classroom drills or in private study. One writes a question on a side and an answer overleaf. Flashcards can bear vocabulary, historical dates, formulae or any subject matter that can be learned via a question-and-answer format. Flashcards are widely used as a learning drill to aid memorization. They are often associated with spaced repetition, i.e. reviewed at expanding time intervals”

A great (and free) software that I use to make flashcards as I read something is Quizlet. There are other options too, like Ankin. Choose whatever you like the most.

OK, but how exactly do I do it?

So, how does it look like to use flashcards and spaced repetition while reading a good software technical book?

To help illustrate this I’m gonna provide a personal example of mine. I Recently made my mind to learn the Clojure functional programming language. I wanted to learn it in less than two months, and I wanted to learn it as deeply as I could during that time (not up to a specialist level or the like, but certainly beyond the “beginner” level).

The first thing that I did was a quick Google search with the words “Best Clojure books”. After browsing through the first-page results, I noticed a few books that were always mentioned by the crowd: “Clojure For The Brave And True”, “The Joy Of Clojure”, “Clojure Programming”, among a few others.

After reaching out for samples that I could read and skim, and do a little bit more research about the books, I decided to go with the “Clojure For The Brave And True” — mostly because it’s online (and free) and it seemed to be very practical, accurate, and direct to the point — as long as I could tell at the time. If my expectations were proved wrong after a few pages in, I would just have to go back and try another one.

Before starting the reading itself, I created a folder on my Quizlet account named “Clojure_For_The_Brave_And_True”, and inside such folder I created a flashcard deck named after the book’s first chapter (“Building, Running, and the REPL”). Then, while I was reading the chapter, I captured all the relevant pieces of information in a flashcard-question format, storing them all into the aforementioned deck.

For example, this first chapter explains how to create a new Clojure project using the Leiningen project management tool. So, I created a flashcard with the following content:

<Question>: How can I create a Clojure project named “clojure-noob” using Leiningen through the command-line?

<Answer>: lein new app clojure-noob

Always try to formulate the card either as an objective question, or alternatively as an exercise proposition. The latter has proved to be specially useful for code-requiring questions. For example, the first chapter also contains the ol’ good Hello World example in Clojure, so I made the following card:

<Question>: Write a Clojure program that prints “Hello, World!” to the console

<Answer>:(ns hello.core
(:gen-class))(defn -main [& args]
(println “Hello, World!”))

You can also make cards for more abstract and vague conceptual ideas, if you feel that’s something you really want to internalize and be able to spell out. For example, I made a card with the following question:

<Question>: Why is the REPL (Read Evaluate Print Loop) important in Clojure development?

<Answer>: The REPL allows you to interact with a running program and quickly try out ideas, improving overall productivity

Review, Review, Review

The most important thing about using flashcards is constantly reviewing them. In my daily study routine, the first thing I would do before moving forward on the book’s content was to review all the flashcards that I had built so far.

This is pretty easy to do in the beginning, because there are only a handful of flashcards. But very soon you’ll end up with hundreds of flashcards in several decks, and it starts to get very time-consuming to go through all of them every day.

When this begins to happen, I start to skip the oldest flashcards — the ones that I have probably already memorized anyway. My rule of thumb is, if the daily review session is taking more than 30–40 minutes, I start to skip the oldest cards.

Your specific time threshold can be shorter than this — only make sure that you have really assimilated the flashcards that you are skipping (reorder them if you need to). And make sure to review them again from time to time — say, once a week.

Code flashcards or “micro-katas”

I can’t stress enough how the “code” flashcards are important. I’m talking about the cards whose answers are small code implementations — like small coding exercises or code katas.

Every time the textbook presents you with a new code construct or concept— like a new library function you didn’t know before — try to capture that as a code exercise (as opposed to a “memorable concept”).

For example, at some point in any Clojure book it presents you the important map function. Instead of creating a flashcard like “What does the map function do?” try to state it as an exercise:

“Given the sequence [1 2 3], generate a new sequence that consists of all previous elements incremented by one”

Notice that I don’t even mention the map function here — give yourself a chance to remember the way to the solution.

By the way, the answer to the previous question is the following single line of code (sweet, huh?) :(map inc [1 2 3])

What to expect from this

When you review and re-do these little exercises over and over again, you’ll notice that sometimes you answer/implement them in several different ways — and that’s OK. The objective here is not to memorize a specific solution, but to learn how to solve the problem (unless you want to memorize a specific solution).

The more you review, the more your brain will be familiarized with the given constructs and solutions. That’s the kind of thing that you easily forget when you don’t practice frequently enough.

If you’re willing to give this a try, I can assure you’re going to see interesting results in less than a week. It’s not uncommon for me during a flashcard review to surprise myself with the amount of information that I have already forgot just from the day before — it’s amazing how the mind just let it go!

But with flashcards, you get the feeling that your knowledge is “safe” somewhere — that you’re not gonna lose it in a blink of an eye. All you need to do is go back to the flashcards and review it again.

At some point in your learning process, you’ll want to switch to some “bigger” practice sessions — maybe implementing regular code katas or building your own small personal projects. These are much more time-consuming than simple flashcards, but are also a vital part of learning anything in a “deep” way.