Back in 2015, the first year I was an instructor at Nashville Software School, I was in heavy research mode. I read books, magazine articles, and online resources about anything to do with adult education. This then led me to books about cognitive science, and what modern experiments and studies show us about how the human brain actually learns something.
It was after I read the book, Make It Stick, that I came up with a framework I use to build, and improve, our courses over time. I call it the RIVERS framework.
These are the techniques that stood out amongst all the research that had a significant effect on the human brain's ability to comprehend a new skill or concept.
Five of those six techniques were easy enough to implement, but variation eluded me. I coach students through a six-month course in web application development, and every time I tried to conceive of a way to vary the instruction - in any way - on a concept, I always ran violently into the brick wall of Time. In order to implement those other five techniques, time is at a premium as we lead the students through the fundamental concepts in an elaborative manner.
With the most recent cohort, I've finally figured out a good approach.
Start with Why
I've found that the best place to start is with context. Before I write a single line of example code, I spend 5-15 talking about the history of the concept, the context in which it is used in modern programming, and whiteboarding processes or diagrams (if needed). Adults need to know why they are about to learn something.
If I drop straight to the terminal, or a code editor and start with, "Ok, we're going to write
for loops this morning," then their comprehension is already stunted. A better way to start the conversation is to talk about how modern software development is a team sport. They won't be getting tech jobs as they are portrayed by Hollywood - where they sit in a dark room, by themselves, and code all day.
That may seem like a strange place to start the conversation about
for loops, but it's necessary to provide a rich, complete context.
After that discussion, I give them a simple problem that needs to be solved in code: I need to display all 27 of their names in the browser document. What's the simplest way to solve that?
const firstName = "Maureen" const lastName = "Wilkerson" document.getElementById("output").innerHTML += firstName + lastName const firstName = "Richard" const lastName = "McConnell" document.getElementById("output").innerHTML += firstName + lastName const firstName = "Rachel" const lastName = "Miller" document.getElementById("output").innerHTML += firstName + lastName // etc...
While that gets the job done, consider another developer (remember the team sport thing from above?) has to come in and change all the variable names from camel case to lower case. Now imagine there are 120 of these code sections. What are the chances that the developer will make a mistake when typing out the new variable names? Considering that humans are notoriously bad at focus and consistency, fairly high.
Let's take all that repetitive code and make it DRY. This leads to a discussion about DRY, and how that makes the code more maintainable in a team environment. See what I did there?
To make it DRY, we put it in a function. Then I discuss functions, and then build up, and up, and up, from there.
Once I've talked and coded at the students for 20-45 minutes, I send them off to work on a practice exercise. They aren't simple, repetitive exercises either. Each exercise in the course has them solving a problem with the concept I just introduced.
This is the second variation of how they experience the code and concept.
Updating Personal Site
Once they have worked on the exercise(s) for a few hours, I send them all Github tickets for them to put in their backlog. The tickets are for their personal site, which is the long-running project that lasts the entire first three months of the course.
Another discovery I've made is that providing a long-running, complex project that they can really dig their hands into deepens their comprehension of individual concepts, and how they all fit together in an application. Just having exercises isn't enough.
This is the third variation of how they experience the code and concept.
On every Friday morning, I take as long as is needed to review fundamental concepts with students who still have gaps. I provide laser-focused tasks that a student can complete in less than 2 minutes. Then I review by writing the code myself and answering questions.
We do this rapid-fire workout until questions are exhausted.
This is the fourth variation of how they experience the code and concept.
Then we put them in groups and give them a very complex application that they need to use the concepts they've learned to build. The focus is on comprehension, and I need to ensure that students understand that my expectation is that they learn the concepts in the context of this project - not to complete the project.
This is where they put all the pieces of the puzzle together. Group projects are PFM, which is an acronym that my wife taught me while we were still dating back in 2004.
Pure. Fucking. Magic.
We give students a series of feature tickets for a complex application that seems far too daunting for them when they start. However, as they design, communicate, break it down, and focus on learning the concepts instead of stressing about completion, comprehension inundates each of their brains.
This is the fifth variation of how they experience the code and concept.
This is the optional sixth variation of how students experience the code and concept. Only students who excel at a particular concept make it to the variation, and it's different students for every concept.
Some students catch on quickly to iteration. Others to functions. Others to objects, and their behavior. Others to event listeners.
When I see a student excelling at a particular concept, I provide them a link to a more advanced exercise intended to stretch their comprehension and use it in a much broader context.