Oct 28 2017: Advice to learners - Test-drive your learning

Every four weeks a new cohort of beginner developers comes through the doors of Makers Academy. Our students come from all manner of backgrounds and walks of life which makes working here an enriching experience. However, as diverse as their backgrounds are, for the most part, they have all been subjected to traditional education in a system designed to give information and then assess them according to criteria decided by others.

It is with this expectation most students start the course: they will be given lots of information about how to code and at regular intervals they will be told how they are doing.

Naturally, we disappoint them utterly.

Forget what you think you know about learning

The intensity of learning at a 12 week bootcamp such as Makers Academy requires relearning how to learn. Generally, we try to enable students to actively participate in their learning by

• pursuing a challenge-based curriculum focused on training behaviours
• mixing in project work and workshops focused on practicing skills
• offering daily meditation and twice-weekly yoga
• encouraging daily reflection

This different approach to learning allows students to begin to feel in charge of their learning and so common statements from the cohorts in the first week or two follow along the lines of:

• "I haven't learnt so much before, or felt so engaged in my learning"
• "I wish all education was like this."
• "I feel like everything up to now has been a waste of learning time"

However, as the complexity scales, for a majority of the cohort the rawness of their learning techniques shows through:

• "I am overwhelmed, how am I meant to learn all of this?
• "I feel like I'm behind."
• "Am I doing it correctly?"
• "I need you to check my work each week to tell me how I'm doing."
• "I've spent the past day struggling on this error."
• "I just don't get RSpec doubles."

As a coach, there is a familiar sense of déjà vu giving advice throughout the first six weeks. This post focuses on a core part of that advice.

Students learn differently and at different rates. If you're in one of our cohorts, you have a rich source of data to mine for new learning habits; everyone around you is trying to learn.

My advice? Test-drive your learning.

Be as rigorous with deciding how to learn as a programmer would be TDDing a feature. This may seem a little odd, but essentially, if the objective is to learn something, then the approach needs to involve a (frequently) testable hypothesis 'I have learnt that thing' with corrections to the approach. The more objective and efficient your feedback loop is, the better you will learn.

It requires a few things:

• Small prioritised targets
• Reflection
• Fail fast, fail often
• Self assessment
• Small Prioritised Targets
• Thinking in small steps is the quickest and crudest way to tell a good beginner from a less good one.

Whatever the problem is, it can be solved if broken down into small pieces. Beginner developers tend to overreach and bite off more than they can chew and end up overwhelmed.

For example:

I am going to learn node.js

It's a great ambition, but 'I know node' is a useless hypothesis to test.

In the context of learning, it's the same as programming: write small unit tests. So choose small bits of learning to focus on. The typical follow up question is how small is small?

My usual answer is to say whatever is the easiest simplest thing to do. If it feels hard, break it down into more steps. This weekend I set myself the task to "learn how to build a middleman static site" I broke it down into a bunch of smaller topics that I prioritised:

• Find an easy middleman tutorial
• document things I learn for later reference
• find some open source example sites
• explain how they work
• build the simplest version I can
• This is a fairly trivial example, but for each one of these steps I can keep breaking down into smaller steps or removing/changing the steps if they're not valuable. The important thing is to plan a route to your objective, consisting of small achievable targets

Reflection

Reflection means serious thought or consideration. It's worth noting this definition because reflection is a serious skill in itself that needs practice and feedback as much as it helps to learn other skills.

In the context of active learning, reflection is the glue that holds this technique together. Taking a step back from an activity to be able to judge how effectively it is going allows for efficient and targeted improvements to accelerate the learning process. With poor reflection, when you try to learn something you're pretty much bound to the course you start on which beginner developers either don't actively choose a course or judge inappropriately.

Instead, ask yourself a set of questions at regular timed intervals to start training a reflective habit:

• What is my immediate objective for the next 45mins?
• Why is it my objective?
• What am I doing to get there?
• How is it going?
• What is going well?
• What isn't going well?
• How can I make it better?
• Slowly you'll get better and better at asking and answering these questions quickly.

Fail fast fail often

There is a tendency for beginner developers to not try different approaches. If something is working, or an approach demonstrated works 'well enough' they'll stick to it.

Instead, try as many different approaches as you can and rely on your reflection to continue new approaches, discard some, and improve others.

Self assessment

Taking responsibility for the direction of your learning is half the battle, the other half is to know how to evaluate yourself.

Usually because of the lack of summative assessment we give them as coaches, the developers who begin at Makers Academy compare themselves to each other and any other metric they can get their hands on. One typical metric is the number of challenges they have completed in a day or in a week. I've heard a number of times a developer say something along the lines of "I'm only on challenge -number-, I don't want to slow you down".

Instead find your own criteria tailored to your own learning

Being able to find criteria of assessment tailored to your own learning requires knowing both what your objective is and how you learn. If you know those two things you can start simply by giving yourself the testable hypothesis of for example 'I can explain both how to stub methods using RSpec and why it is helpful'

Think TDD

If that is a good enough test you can start to break out smaller unit tests for learning: 'I can implement two different ways to stub', 'I can explain how stubbing works', 'I can evaluate the different scenarios in which you would stub behaviour', 'I can tell the difference between stubs and mocks'

And potentially break each one of those down still further. The important part here is to always think test first, which helps drive learning towards a goal.