Front-Loaded Learning: A Review

In November of 2020, I published an article describing an experiment I was running with the Learner Experience (LX) called Front-Loaded Learning. You can read the article for more details, but the general idea was to introduce concepts in a group, and then give students copious amount of lab time to build projects using those concepts. The instruction team would provide individual coaching to each student during the lab time to help each person with their particular cognitive struggles.

The experiment was both a success and a failure, and exposed a tremendous opportunity to make the LX even stronger.

Failure Story

It failed because of events - specifically custom events. The intent was to demonstrate to students how React - a modern, component-based UI library - managed to keep the state of components up to date. My hypothesis was that if a student could understand the concept, and a proficiency in the application, of custom events, it would lower the cognitive load of understanding React.

"According to cognitive load theory, short-term or working memory has a limited capacity and can only handle so much information effectively at one time. If a person’s working memory is overloaded, that person may not be able to process anything well, thus leading to poor understanding, retention, and learning (Sweller, 1988, 1994, 1999, 2011; Chandler and Sweller, 1991, 1992, 1996; Mayer and Moreno, 2003; Nguyen and Clark, 2005; van Merrienboer and Sweller, 2005)." - Cognitive Load Theory (Science Direct)

The result was that some students were able to make the connection (certainly not all), but that gain in understanding came at too high a cost in relation to other fundamental knowledge.

"There was a 2-week stretch that required significant support from the instruction staff to keep the spirits of the class up while they worked through some hard concepts..." - Front-Loaded Learning

Adam Sheaffer, a senior instructor, observed that during that two-week period, too many students spent so much of their working memory resources trying to understand how to make multiple components react to custom events dispatched from other components, that they had limited resources left to dedicate to functions, iteration, conditional logic, and data relationships.

Those four fundamental concepts are crucial for their success throughout the entire course, and in their careers. Therefore, the balance was off and the experiment did not achieve the outcomes I had anticipated.

Success Story

It succeeded because it showed that peer-based, and project-based, learning combined with instructor coaching is a highly successful model. By shifting the initial direct instruction from being the responsibility of the instructor to being the responsibility of the student, it resulted in more valuable time spent in group-based, collaborative coding sessions.

Questions shifted from the very low level - "What is X called again?" - to higher level - "I tried it this way, and it still worked, can you help me understand the difference?". The copious amounts of lab time, with plentiful resources and examples allowed students to try, fail, discuss, and try again. When obstacles arose that peers could not break down, the instructors would then step in and get that student and/or group moving again.

The main benefits of peer teaching include, but are not limited to, the following:

1. Students receive more time for individualized learning.
2. Direct interaction between students promotes active learning.
3. Peer teachers reinforce their own learning by instructing others.
4. Students feel more comfortable and open when interacting with a peer.

How Peer Teaching Improves Student Learning and 10 Ways To Encourage It

There are more benefits, but these are the main four that we observed from this model in our cohorts.

The Opportunity

Ok, so introducing students to the broker pattern and decoupled components early on in the course makes the cognitive load too high.

Got it.

Discussion with the senior instruction team about the course led to the outcomes described above, and new hypotheses I will describe below.

New Hypothesis: State

It also is not that important that students understand the inner workings of React. They are novices. What is far more important for them to understand is state expressed as HTML, and how state transitions should be handled in their code.

Also, by focusing more cognitive effort on understanding these concepts, the transfer of knowledge to different tools like Vue, Svelte, and Angular is achieved instead of focusing on how one tool does something.

New Hypothesis: Events and Other Fundamentals

The emphasis on handling browser-generated events was put on par with custom events. Since handling browser-generated events are vastly more common for developers, the course reverted back to focusing heavily on those and relegating custom events to a single case that serves a very specific purpose of understanding how state expressed as HTML is done.

By eliminating a goal of understanding and implementing decoupled components with a broker architecture, more of the students' cognitive effort can be spent on fundamental concepts.

The Result

With the new course that changes the focus of the cognitive load back to more fundamental concepts has provided good results. The level of student frustration is lower, and their performance on assessments is measurably better. Also, their assessment of the pace of the course has consistently been "just right" instead of 8+ students stating "too fast" in the previous version.

There's even a few who are voting "too slow" which never got a vote before. That means there's room for improvement. 😜