How we craft a learner experience to be as Adaptive, and as LEAN as possible (A/LEAN).
Adaptive
In the traditional education model, Adaptive Learning is where testing and content is customized for each student. The student is constantly barraged with questions, and the answers direct which content is delivered next. It's still based on a teacher telling a student what to do and the student being asked to regurgitate information on a test. It's just that machine learning algorithms are the teacher.
In our learner experience, multiple projects are available to be worked on at any time. Each helps a student achieve a particular learning objective. The student can choose which one is to be worked on, with the instruction team coaching alongside.
We are training professionals, not teaching students.
These nascent professionals are expected to be adaptive on the job, and be able to prioritize their time, and their learning, to be the most curious and productive teammates possible, and provide the most value to the team and the customer.
What is LEAN?
"The key fundamental to LEAN methodology is the elimination of waste - this includes time, processes, inventory, and more." - Steve Mullen
I'll adapt that quote for our goals.
"The key fundamental to LEAN learning is the elimination of noise - this includes tools, processes, distractions, and more." - Steve Brownlee 🥚
We use that definition to make the following determination in our learner experience: A task either helps the students understand how to apply knowledge during the creation process, or it doesn't. If it doesn't, it's gone. No exceptions.
Definition: Noise
From the field of signal processing, the word noise can be used to define signals that are random and carry no useful information. In a learning environment, noise is work done by a student that does not help them achieve a learning objective, and, therefore, not useful.
Signal::Noise Ratio
Simple is hard, y'all.
For us, simple required figuring out exactly what works and what doesn't for learning software patterns and practices. It was uncharted territory. Sure there were lots of other bootcamps trying to figure it out, but after looking at their curricula, it was clear they were stumbling around trying to figure things out as well.
Now that we have 45 daytime cohorts and 13 evening cohorts under our belts, and a team filled with veteran instructors who constantly experiment with improving our experience, I can say that we've been lucky enough to wander aimlessly into the Perimeter of Wisdom just enough times to finally feel like we know a few things.
For me, the biggest thing I learned is that coaching people into becoming successful software developers has very little to do with the technology. Because of that realization, I dedicated some serious time to building a course/experience that had the highest signal::noise ratio possible. Anything that does not have context, or data supporting that the students are achieving the learning objectives has been eliminated ☠️ from the course.
This mean that there are no "exercises" in the standard course that don't relate directly to a feature they need to build in an application.
Everything is in context.
Noise was eliminated.
Conclusion
I now look at other schools' curricula that attempt to have students learn 12 tools and libraries in three months and am left with concern for those students. We focus on 3 tools and libraries in the first three months. In the final three months, we focus on a different 3.
More is worse in an accelerated learning environment. Less is better.
Not only do we have a laser focus on the core learning objectives that the community wants us to hit, but our students have a delightful learning experience while they are with us.
We could not have arrived at this destination without experimentation and listening intently to student feedback over the years.