Day 3: How to learn backwards (and why it will actually save you time)

This is a temporary archive of the 2015 Learn Faster bootcamp emails. After Monday, July 6th, 2015, this will be removed. If you want to get access to the other emails in this series, please sign up here.

Today is the third day in the week-long bootcamp for learning faster. Every day this week I’m sending you a new strategy that I’ve used to learn hard subjects better and in less time.

In case you missed it, here were the previous two emails:

Day 1: How to stop forgetting what you read
https://www.scotthyoung.com/blog/2015/06/22/stop-forgetting/

Day 2: What matters more: method or motivation? The answer might surprise you…
https://www.scotthyoung.com/blog/bootcamp-2015-day-2/

In today’s lesson I’m going to teach you a method of learning that originated as a way of doing software development. It may be a little strange, but I’ve found it incredibly effective for saving time when learning.

———

How often do you learn something, but when you take the test, it completely baffles you?

This is a common problem I’ve seen a lot of students face. Fortunately, it has an extremely simple fix. But it does involve you going backwards from the normal learning process, so few people take advantage of it.

Before I explain what the method is, I want to tell you how I first found out about it. Unlike many of the strategies I’ll share with you, this method didn’t actually originate as a way to solve learning problems. Instead, it was used to develop software.

The difficulty with software is that mistakes are often hard to detect. Worse, the volume of code for many projects is gigantic, very often in the millions of lines of code. Yet all it takes is a small edge case that the original programmer didn’t foresee to destroy the finished product.

As any programmer knows, a significant amount of your time is spent on debugging. Sometimes debugging will take up the majority of your time, because isolating the exact error can be difficult in a complex system. Because of the cost of debugging, many of the development methodologies programmers use aren’t for solving a problem, but for reducing the burden of debugging.

One of these debugging-reducing philosophies is known as test-driven development.

Test-driven development is the process of creating a test which your program must pass before you write the code to actually pass it. If you make the tests thorough enough, it can ensure that your code is essentially bug-free by the time you first write it.

An example of this might be writing a computer program that sorts a deck of cards. Before you write the code for sorting it, you could write code that tests the properties of the sorted card deck. You could make sure that the program didn’t lose any of the cards, duplicate them and verifies that they are actually in the correct order.

Test-driven development is like writing code backwards. You first write the code to verify that the solution you haven’t created yet actually works.

Yet its popularity amongst developers shows that doing things backwards can often save you headaches later.

So what does this have to do with learning?

The analogy here is to do test-driven learning. That means writing a (mock) final exam, before you ever attend a single lecture or open your textbook for the course.

It means doing practice problems before reading the text. It means attempting to speak a language before you’ve learned any words. It means trying to apply a skill before you’ve practiced it.

But, how do you use things you haven’t learned yet?

In most cases, you can’t. Taking a mock exam for a course you’ve never studied will more than likely result in an abysmal score.

However, by taking the test first, you can make a mental assessment of how the knowledge needs to be used before you take the class. Then, once you’re in the class, you’re already primed to think about the knowledge in the way that will help you retake the test again.

Let me explain how I used this in a class I’m taking right now: Medical Neuroscience. (For those interested, the actual class is here: https://class.coursera.org/medicalneuro-003/ )

I’ve studied a lot of different subjects. My university studies were in business. During the MIT Challenge I learned a lot of math, computer science and physics. My most recent project was all about learning languages.

But taking this class in medical neuroscience was something very different to what I had previously studied. The first section was neuroanatomy: needing to know dozens of nerves, nuclei and cortical topography by name and function. Very different and an interesting new challenge.

The difficulty whenever you take a new course like this is that it can be hard to know exactly what you should be studying. What level of detail do I need to know the information? What kinds of questions are likely to be asked?

The solution here is simple: take the test first. By attempting the quizzes before I take on a section, I can pick up important meta-knowledge about what’s important for the class.

In this class, for instance, I learned that a lot of the questions are organized by hypothetical patients who may have brain damage and you need to suggest assessments which could localize the site of injury. Knowing that was how it was organized, I knew to pay special attention to how function and location are related when I took the class.

What if you don’t have access to mock exams or questions?

The best case to apply this principle is when you have easy access to large amounts of practice questions and testing material. That means it’s invaluable for standardized tests or classes.

However, with a little bit of creativity, you can use a modified version of this principle to learn almost anything.

For practical skills you intend to use, for example, you can put yourself in a usage situation before you’ve studied anything yet.

If I’m learning a foreign language, for example, I might jump right into attempting a conversation using Google Translate as backup. This lets me see which kinds of words, expressions and features of the language matter to me so when I go to study I can hone in on the right material.

If I’m learning a new programming language, I might go straight into trying to write a simple program, again, going back and forth with example code or a guide.

Unlike normal testing situations, where you’d want to avoid referencing any help, test-first learning benefits from going back and checking source material. The goal isn’t to kill yourself trying to do something you haven’t learned yet, but to explore the problems a bit more deeply before you engage in more passive lectures or reading.

Take Action Now

If you’ve read this far, I want you to take action right now. You might not be in a position where you have time to do a mock exam or test out a skill you haven’t learned yet. But you can plan ahead so that the next thing you learn benefits from this approach.

Here’s what you need to do:

1. Pick something that you’re going to learn. It could be the next lesson for a class, a new subject or a skill.

2. Decide how you could test yourself first: are there practice questions available? If not, could you look some up online? If it’s a practical skill, can you pick a situation to expose yourself to an application of the idea first?

3. Commit to spending at least 10 minutes before your next learning session practicing before you start reading or listening.

That’s it for today. Tomorrow I’ll be back with another strategy you can use to learn better. At the end of this week, I’ll be giving an opportunity for you to join Learning on Steroids, which will build on the tactics we’re discussing in the bootcamp and give you a complete approach for learning anything more efficiently.