An Education Engineer’s Approach to Teaching
Why Focusing on Process and Pedagogy Produce Superior Results
In my years as a software engineer, I’ve tackled a lot of difficult problems. Systems that had to be built from the ground up. Bugs that were buried so deep in a legacy codebase as to require days of tracking. Algorithms that mystified me even after I had solved them. Software development is hard, but in the years since we started Launch School, I have learned that software challenges pale in comparison to those in education. Effective teaching is, without doubt, one of the hardest things I have done in my life. That’s the reality — but there is good news as well: effective teaching is hard, but it can be done. Today I want to talk about our instructional model and why I think it produces better results than traditional conceptions of great teaching.
First, a brief aside about why this matters. I love teaching — watching students grow from relative beginners into accomplished engineers is incredibly satisfying — but in some ways, teaching is also a bit terrifying. In education, the stakes are high. This is absolutely true in our broader education system, where teachers are tasked with transforming young minds into successful members of society, but it’s true in the narrower coding industry as well. When someone comes to Launch School to learn to code, they are in effect putting their careers in our hands. It’s a lofty responsibility and making sure that we provide the absolute best instruction possible is something that keeps me up at night. We feel that we owe it to our students to constantly improve how, and why, we teach the way we do. And that gets to the core of our instructional philosophy: just as in good software development, good teaching requires constant iteration. Call it not just an educator’s approach to teaching, or an engineer’s approach to problem-solving, but a combination of the two — an education engineer’s approach.
Heroic Teaching
A system that relies on heroic teaching is neither fair to the students, nor to the teachers.
When we, as a society, think about great teaching we tend to conjure up images of heroic teachers laboring day and night for their students. And there can be no doubt, such teachers are heroic, and they deserve every bit of admiration that they get (and more). There is, however, a problem with this model: it’s not sustainable. Heroic teaching, though praise-worthy, is both highly localized and dependent on scarce resources (time, energy, money). If a student is lucky enough to be put under the tutelage of a heroic teacher, they will certainly benefit from it. But what about the students who aren’t so lucky? Moreover, what about teachers who are unfairly maligned for not having the means to devote every second of their lives to their students? (Teachers are, after all, human, and face all the same trials and tribulations as the rest of us.) Put another way, a system that relies on heroic teaching is neither fair to the students, nor to the teachers. There has to be a better way — and at Launch School, we believe that a process-driven approach offers a more effective and sustainable alternative.
If heroic teaching is an approach that relies on teachers putting in extraordinary individual effort (as so many of them do), then a process-driven approach is one that develops a system that supports teachers and raises the number of students who benefit from those teachers’ efforts. I hesitate to extrapolate this position too much into the general education sphere, which is concerned not just with academic education but also social and cultural development; however, I am certain that this philosophy is the right one for coding education.
An Engineer’s Approach to Curriculum Design
One of the things that I love about software engineering is that it’s flexible. Compare this to say, civil engineering, where changing a product is a monumental effort once you have already completed it (imagine redesigning a bridge that you’ve already built!) In contrast, changing software is absolutely possible, so long as you adopt an outlook upfront that is experimental rather than dogmatic. If you discover that there is a better way to do something, you can and should change it. This mindset has been absolutely vital to our development of an educational methodology at Launch School. Since the beginning, we have been experimenting and iterating on our model, and I firmly believe that that’s the reason we have the highly-effective program that we have today.
So, what does a process-driven approach to education look like? First off, as noted above, it’s flexible and values experimentation. If you’re not willing to experiment with a new way of doing things, then your product will stagnate. However, experimentation is only useful if it results in feedback, which is a necessary part of making improvements. We are lucky to have a passionate user base that is highly invested in the quality of our program. As a result we get a ton of feedback from our students. We then match it with our own observations and are thus able to make constant updates to our curriculum. This is why our curriculum today is not only different from our curriculum two years ago, but better.
Another way of describing the feedback-improvement loop is continuous deployment. In order to get the most out of this practice, it’s important that both feedback and improvement be immediate. Compare this to a static product like a book. Certainly book authors and publishers receive feedback on the content they produce, and use that feedback to iterate in the form of updated editions; however, their pace of iteration is far too slow to generate useful compounding effects. With continuous deployment we receive feedback, make a change, then receive feedback on the change we made, and so on. In this fashion we can ensure that the benefits of the feedback-improvement loop compound over time.
Taken together, our experimental mindset, our use of feedback, and our continuous deployment of improvements is an Agile approach to curriculum development rather than a waterfall approach.
If our students aren’t seeing better education outcomes based on the improvements that we are making, then they aren’t improvements at all.
All of this gets at the most important element of our philosophy as education engineers: stay oriented towards results. And by “results” I don’t mean the number of students enrolled in our program or the number of lessons that we produce — I mean educational outcomes. If our students aren’t seeing better education outcomes based on the improvements that we are making, then they aren’t improvements at all. This philosophy goes into everything we do. Furthermore, it stands in direct contrast to the approach found in many books, which is not only static, as we have discussed, but which also tends to focus on content rather than outcomes. Most books and courses are built to expose people to a list of topics, and not built to drive people to some educational outcome.
Processes that Drive to Results
The other necessary element of effective teaching is a consistent pedagogy. At Launch School, our pedagogy is centered around mastery-based learning (MBL). But how do we take a pedagogy like MBL, develop processes that reflect it, and then iterate on those processes to maximize educational outcomes? This isn’t an easy thing to do, but in our experience, the most effective way of doing it is to work backwards. Instead of starting with low-level processes and pointing them towards our intended results, it’s best to start with the results first and then consider processes that align with them.
When we set out to develop an MBL-based curriculum the first thing we did was agree on a set of non-negotiable end goals. We wanted our students to finish the program with a deep understanding of programming fundamentals. We wanted our students to learn how to learn effectively. And, we wanted our students to be well-positioned to acquire high-quality jobs and launch careers in software development. I say these items are non-negotiable because they aren’t processes — they’re the end results that everything else builds towards. Changing them would be to fundamentally alter what we’re doing at Launch School. Compare this to the vast majority of existing educational content and curricula, which are designed to cover as many topics as possible without much focus on how well students actually understand the material.
Ultimately, the goal of setting students up to land high paying jobs and launch careers is inextricably tied to the goal of helping them acquire a deep understanding of fundamentals. For this reason, and in consideration of our MBL-based pedagogy, mastery of fundamentals is our principle aim. With mastery as the defining characteristic of our program, the next step is to enforce it. We do this through rigorous assessments where we evaluate each student’s proficiency in each fundamental topic before allowing them to move on to the next one. And because of our career-oriented goals, our assessments are modeled after real-life interview situations. This means that we have to develop one-on-one live coding, essay, and take-home project assessments that both mimic real-world job interviews and demand mastery. With the assessments in place, we’re able to focus on driving students past them. In order to do this, we look at the content in each assessment and then build a curriculum that targets that content.
The goal of setting students up to land high paying jobs and launch careers is inextricably tied to the goal of helping them acquire a deep understanding of fundamentals.
High-quality assessments are an important part of MBL, but as a results-oriented program we have to do more than just assess students — we have to assess the right things. Our goal is to help students launch careers, and to do this, we have to consider factors beyond technical skill because that’s what real-world companies require. For example, we know from our experience in the software world (including mine as a hiring manager), and from job listings at top companies, that communication skills are just as important as technical skills — sometimes more so. In order to help students practice communication skills and identify associated problems early on we introduced a “Non-Technical Grade” to each assessment. Further, we require that every assessment includes 1-on-1 interaction in either live-coding or written form (just as in a real job), during which we evaluate students’ ability to communicate on a technical level clearly. If we were writing books or producing courses and nothing else, then evaluating students’ communication skills wouldn’t be possible, but because we are results-driven, we recognized this as a critical part of the assessment process and addressed it accordingly.
The above is a simplified version of how we went from envisioning our desired end result (helping students master fundamental skills), to determining how we would move towards that end result (assessments), to building an actual path to reach the end result (curriculum). All content at Launch School was developed in this fashion, and the only things that are truly static are the results we are pushing towards. Everything down the chain is open for revision if warranted. The fact that we have assessments is very unlikely to change, but the assessments themselves can and do change. We observe how students are moving through the process, see what is challenging them, and design our assessments to fill in gaps. And if there is something in the assessments that students are consistently having trouble with, then we look at the curriculum to see why students are having trouble. And this leads to the lowest and most dynamic level of our content — the lessons, which we are constantly updating so that everything further up the chain works more effectively.
Processes and pedagogy are important, but they only work if applied consistently. I like to think of this in the same way you might think of a Michelin-starred restaurant. It may very well be true that the head chef is immensely talented, but the restaurant does not depend on the heroic efforts of the head chef alone — cooking every last meal by herself. Rather, it depends on an entire team that is working together in a shared rhythm of carefully-crafted processes. The chef certainly has a role in designing those processes, but the team experiments and iterates on them together. And as a result, they are able to create incredible experiences for their patrons. And most importantly, they do it night after night. No one earns a Michelin star based on a single night of great food. Consistency matters, and the same is true in education. If you want your students to achieve great educational outcomes, then you have to do it through consistent application of effective processes.
Launch School has been around for a few years now, but by no means have we settled into “the answer” for how to teach coding. We firmly believe in what we’ve built, but we know that it’s going to change. Launch School is the result of years of experimentation and we’re still learning. We are making incremental quality improvements every day, and that means that our already high-quality content is only going to get better. What is not going to change, however, are the results that we’re driving towards, and we do that through our commitment to a flexible, sustainable, iterative process of continual improvement, which is guided by our career-oriented goals.
Chris Lee is an instructor at Launch School, an online school for software engineers. He has over 16 years of software engineering experience ranging from large enterprise to startups. He enjoys programming, teaching and talking about Mastery Based Learning.
