I recently listened to an interesting podcast on learning Python where Barbara Oakley was a guest. It answered some questions for me about how developers can remember things. By understanding how memories are formed in the first place, I got thinking about how I could apply those myself.

I wanted to use the principles from the the podcast and apply them to my own learning of Kotlin. This is a two part article – this first one sets the scene on how we recall from long term memory differently. The second will be on how I set up a training plan for Kotlin based on those insights and my own experience as a developer.

Procedural vs declarative pathways

In the podcast, Barbara explains that there are two (relevant) pathways into long term memory, the declarative and procedural pathways. The declarative memory is for recalling things consciously – as in when you remember a fact you need, or an event that happened. In the case of a software developer role, that could be recalling the need for a certain design pattern. Or maybe you know where to start looking to troubleshoot once someone starts describing a problem to you.

Picture courtesy of www.vanderbilt.edu

Conversely, the procedural memory relates to things that you are just ‘able to do’ after you’ve practiced enough times. The second nature stuff. In the non software world, maybe all the skills required to drive. For example, you don’t think about gear shifting, mirror checking, clutch control, traffic priorities etc when you drive home. You probably don’t even remember the drive at all once it’s second nature!

In the software world, some useful ‘procedural skills’ might involve recalling on demand:

  • The keyboard shortcuts to avoid losing flow (avoiding touching the mouse).
  • Application layering, so you can write packages and modules on autopilot.
  • Test framework annotations/quirks so you can focus on writing the actual test coverage.
  • The right construct or idiom of a programming language for a given situation.

It’s this last one the particularly interests me. I want to learn Kotlin better for my role. I want to get to the point where I can recall Kotlin as easily as I recall Java. But I don’t want it to take the months and years of osmosis that Java took.

How can developers remember ‘on-demand’?

The podcast went a step further and talked about the ways to learn efficiently, or as Barbara put it, ‘drill to skill’. The key is to have the links built between the associative memory and procedural. Put another way, going from “I need to do x” to “oh it’s done and I don’t even remember how”.

The basic formula I took to be:

  • Have some directed learning – in other words where you’re told the objective. This sets the faint outline or boundary of your training.
  • Play around, tread your own path, experiment. You need to generate your own experience. In other words building the procedural memories.
  • Build the associative memories between the objectives and the procedural memory.
Directed learning is the first step for developers remembering their code and constructs
Remembering things starts with directed training (picture from lumencourse.com)

This last part is key. The more ‘ways in’ to that drilled knowledge, the quicker we can execute a skill on demand. If those skills are geared towards the right objectives, we’re delivering value quicker. That value could be to ourselves (improved productivity) or ultimately our business (delivering valuable outcomes quicker).

How will this help me remember code?

So it turns out that the following of direct instruction, along with then carrying out your own practice has a two-fold benefit. You’re building and strengthening both the declarative and and the procedural memories. In other words, by testing yourself properly, you remember not only a little about the ‘when to use’ but also making your skills automatic and on-demand. Just reading the material once won’t cut it!

Techniques for building associative memories

So once we have the direct instruction (what we are trying to achieve), we need to test ourselves on it and be able to retrieve it later. For this to happen we need to have some kind of associative memory, or a way to link these memories to a cue. In the excellent “Science of Learning” Course on Listenable, Benjamin Keep gives two techniques we can use to help us retain things, generation and elaboration.


Generation is the process by which we store (encode our memories). If we take the time and effort to ‘store the memory properly’ it’s going to be easier to get it out again. I think along the lines of ‘how would future me get this information that’s obviously useful?’.

In the example below, I’m using flashcards for retrieval practice. I’ve taken the time to write a good question – namely something that prompts me that there are 3 overall models that I need to be aware of.

To retrieve, I use that question as cue to retrieve the memory, a little like a key into a map. Writing the question was the generation part – my brain got a workout building a question for ‘future me’.

Retrieval of generated answers

Retrieving the answer is a second workout – pushing myself to strengthen the association between the question and the answer.

An example of generation – the flashcard prompt helps the developer to remember the answer on the back.

Free recall of generated answers

Another technique developers can use to remember code and patterns is known as free-recall. This was also covered by Benjamin in his course on Listenable. (BTW, that’s behind a paywall, but this link plus a coupon code of ‘jamesbowen’ gets you 30% off a subscription).

With free recall, you simply try and write down all you know about a subject once you’ve learned it. The idea is to see where the gaps are in both your recollection and understanding by comparing your recollection with some trusted resources on the topic. This is definitely more challenging, after all there’s no flashcard prompt to trigger your memory, so it’s quite a working out for the memory.

I’m going to be using free recall with code more than generation with flashcards when it comes to learning Kotlin. There will be a place for both techniques, but I’ll be wanting to bias myself towards the harder workout. Not only that, I want to be ‘practicing how I play’ as my old cricket coach used to say. In other words, in my job, I’m more likely to have to recall Kotlin in a ‘free-recall’ way rather than having a prompt. I write code mostly, not flashcards!

On the other hand, when I did something like the AWS Developer associate exam, generation was perfect. Having a prompt to something was far more similar to the exam situation – multiple choice questions.


Elaboration is yet another way developers can use to remember things. Rather than strengthening the connections between memories, we add new connections. This goes back to the previous point of how to be effective as a developer – having more ways in to the same memories.

I do this all the time when I use metaphors to try and see if an idea ‘fits’ as I learn it. Usually the metaphor needs a bit of refining once I review it, but the process kicks starts the creating of the memories.


The way developers remember code, algorithms and patterns come down to practice, practice, practice. By having a faint outline as an introduction, we know what we need to start learning. Then it comes down to using techniques to actively build memories (generation, free recall and elaboration) rather than passively consuming the lessons given to us. In the next article I’m going to apply these techniques to my own learning, and see how to pick up Kotlin quicker, and recall it on demand.

Further reading

By James