From my previous article you may have seen that I have got a lot of value out of ‘Make it Stick‘ in building my learning plans/confirming that I’m designing my learning in an efficient way.
In this article I’m going to review a case study from the book to suggest some tips and tricks.
Michael Young, Medical Student
In this case study, Michael Young had gone to medical school and found himself very quickly out of his depth. He had crammed for a month and scraped through the Medical College Admission Test by the skin of his teeth.
Once there, he had found himself scoring badly on his tests, thanks in no small part to him having no pre-med experience. His classmates had come from biochemistry and pharmacology backgrounds whereas he had come from a psychology background with experience as a drug addiction counsellor.
But he turned this round, or I wouldn’t be citing it.
A typical day at medical school involved around 400 slides. He knew it wasn’t practical to read each of those, and he needed a better way to retain concepts for the tests. He actually contacted the authors of ‘Make it Stick’ for empirical evidence on spaced repetition and its effect on retention.
This got me thinking about my own studies, most recently for the AWS Developer Associate Certification:
If you can’t recall it when you study, how will you recall it in an exam?
I got thinking about my own experience with cricket practice. Going to net sessions and how running up to bowl one ball and then waiting for 10 other bowlers to have a turn isn’t like a game. Nor is bowling without an umpire, or batting where you face one ball of pace, then one left-arm, then one of spin.
Ok so I didn’t study for my exam by entering my spare bedroom in silence, leaving my phone behind and take a passport for identification. But I did practice with the intent to recall without any resources other than my memory.
You slow down, because it’s an investment in being able to recall later.
Not every part of your job needs this, because you have Google and your colleagues when you get stuck. But an AWS exam was a situation where this investment was needed.
Back to Michael Young.
When he came to review his study, rather than going straight back and re-reading his notes, he tried to recall what he learned from memory. Only when he got stuck did he go back to his notes. His memory was his first port of call.
During the reading itself, he would slow down. Rather than just go through each bit saying ‘yep, got it’ to his subconscious self, he would slow down and find the meanings of things he didn’t understand.
This is a technique I have used myself. When going through AWS material, I have done the following:
Looked at the first paragraph for new terms
I figure this is the main point that page will be trying to get across. My first few flashcards are based off this so I always start with an overview.
As an example using S3 in AWS, I start out with the summary:
Clarify the terms that I can’t make sense of
For the points that don’t make sense to me on the page, Michael talks of how he slowed down and tried to visualise it. I do a similar thing with flashcards. I phrase questions in a way that force me to face what I don’t understand.
Here’s an example I’ve used with AWS Cloudformation:
Writing the flashcard in this way makes me really think about how the pieces of CloudFormation hang together.
Use extra diagrams where necessary
If I have problem with even that then I find a diagram that explains it outside of AWS (e.g. Google Images). If that makes sense to me, I’m usually able to recall it without further prompting.
I can remember having real problems conceptualising AWS API Gateway stages at one point. Something didn’t quite seem right. Eventually I found the right diagram:
And the questions followed:
I hope you get some useful ideas from these case studies. Make it Stick has students from a variety of backgrounds, so whilst I specialise in writing about development, it’s good to see that there are tips and tricks that can be transferred. We can always learn from other disciplines, after all.