Essays

On Teaching: A Few Useful Analogies

A Deconstruction of Learning Methodologies

If asked what the most important qualities great teachers share, I would not say mental acuity, mastery of a subject, or experience... but rather empathy and patience. And while the best teachers often do possess these first three, if they cannot communicate with their students the others are all for naught.

Over the years I have been teaching (and learning), I have often used a few analogies to help me organize my thoughts when approaching a new subject or curriculum. I have been very fortunate while building Zipfian Academy to work with great students and teachers alike from whom I have learned immensely, and many of the formalisms contained here are borne out of that time. I would love to hear in the comments any methodologies others have used!

Three Analogies Walk into a Bar

Analogies for Teaching

Each of the analogies in the diagram above touch on a unique aspect of the educational narrative. There are multiple levels of design that an educator often interacts with (from coarse to fine) that each have their own set of challenges:

  1. Program: Well
  2. Module: Soil
  3. Lesson: Sandwich

Typically instructors need concern themselves with each of these, possibly with the exception of an entire academic program: in traditional academia, the department chair typically heads up the design of their department's program and what classes/requirements are necessary for satisfactory completion of a degree (which a committee then approves).

You can think of these levels as something of a hierarchal Matryoshka doll: a program comprises many classes and each class is composed of multiple lessons.

Before explaining how each of the analogies applies to each of these four levels, I think some clarification on the levels themselves (and their unique challenges) is in order. If you want to fast forward to the juicy examples, feel free to do so.

Program

When I say program, I am referring to a cohesive educational offering. Whether it is a Computer Science Undergraduate Degree or 6 month Fullstack Developer Immersive does not matter, these approaches are generally applicable to any program.

In designing an effective program, the difficultly is one of motivation and validation. A student must be encouraged to learn as well as understand why the material they have dedicated time to learn is valuable. We will see later how The Well addresses these.

Module

Defining what constitutes a module across different types of programs (immersive or traditional) is a little bit less well defined. In a traditional academic program usually it refers to a single class offering (Structure and Interpretation of Computer Programs) whereas in an immersive program I will use it to refer to a week's unit.

The challenge of creating an effective course is one of breadth vs. depth (especially if the course is interdisciplinary). These two however can be at odds (given a fixed time): the more advanced the material of a given topic you want to teach, the fewer topics you can cover (to that depth). But the nature of a broad (interdisciplinary) topic like web application development is that you do not have the luxury of choosing to forgo breadth, much like the P in the CAP theorem. So to teach an adequate depth of a myriad of interconnected topics we can look to The Soil for guidance.

Lesson

A lesson slips even further down the spectrum and can mean many things to many people. In the Galvanize Fullstack Immersive, a lesson typically spans a day and covers a single topic: Active Record, ReSTful APIs, Prototypal inheritance in Javascript, etc.

The challenge of creating an effective lesson is one of content and context. The nature and scope of a lesson leads to inherently specific topics (we are after all at the smallest of the Matryoshka). Also, it is important to remember that your students most likely are learning this material for the first time, they don't have the hindsight of someone who already knows the content. And the more advanced/specialized a topic covered, the harder it becomes for the student to know how it relates to every other concepts they have learned. The two forces at work are the forest and the trees, The Sandwich is how we can see both.

A Parable: On teaching fullstack web development

To make all of the abstract commentary on methodologies so far much more concrete, I want to show how these abstractions might apply to the challenge of effectively teaching fulllstack web development. Since web development is inherently technology focused, we must decide on what technologies (backend and frontend) to teach.

In this post we will use Ruby, Ruby on Rails, Javascript, HTML, and CSS but these principles apply regardless of which technology stack you choose.

The Challenge of the Fullstack

In the evolution of the software industry, we have seen the rise and fall of the fullstack developer but contrary to what trends we may be seeing in industry, I believe that we can still have our cake and eat it too (at least when it comes to education). And how we do that is what I consider the greatest contribution of computer science: abstraction.

Whenever I find myself asking why or how, I often look to history to find answers. This being no exception let us take a short diversion to look at how other fields have handled this challenge of multidisciplinary education.

Mitigating Complexity

Any topic that covers multiple levels of abstraction is inherently difficult to teach (or rather teach well) and historically we have split each of these into a separate field. What once was natural philosophy has evolved over time into the branches of natural science as we have learned more about each of the respective domains (i.e. Astronomy, Biology, Chemistry, etc.). And not coincidentally the divisions happened at the boundaries of different scales of abstraction:

  • Astronomy concerns itself with celestial objects (light years)
  • Biology studies living matter (grams and meters)
  • Chemistry seeks to understand molecules (moles and nanometers)

Now there are always exceptions within each field and some (Physics) are fundamentally cross scale, but we have made such divisions to push our understanding of each much further than we could if everyone tried to understand everything. The biologist does not concern herself with proving the laws of thermodynamics but trusts the Physicist since there is substantial overhead to learning the theory of a new discipline.

Levels

A scientist often lives at one level of abstraction, understands most of what that level (and its borders) contains, and takes a leap of faith by trusting everything outside of her level (and how it relates) without proving it herself. And this is what is necessary given the complexity of the universe and all the information contained within it.

But the more a learner can understand about the nearest other levels and how they relate, the more complete of an understanding they will have of their own level.

the well of learning

The Irreducibility of the Web

Some fields however are much harder to separate while still maintaining understanding. While many people specialize in one aspect of web development in profession, this often is either necessitated by the size of a team/company or a personal want of deeper mastery. But in many of these cases, an individual window shops across the levels of abstraction learning a little bit of everything before deciding the topic to dig deep on (otherwise it is not quite a decision, now is it).

And this knowledge of how the other levels of abstraction (machine structures, memory management, web server architectures, client-server model, HTML specification, client-side Javascript, etc.) relate to the level someone decides to settle at, give a deeper context to it all.


The Well of Abstraction

And this brings us to our first analogy: The Well. The well serves to structure our thinking about how the different levels of abstraction for a given domain relate to one another (and is the broadest of the three abstractions). And because of this, it is useful when thinking about the entirety of an educational program — in which a course might encompass one (or multiple) levels of the well — as well as a given cross-level topic (like data modeling).

By starting a student at the top of the well and slowly lowering them, you can provide the high level context of a given topic's application and why it may be useful. Also, when descending the well we can motivate lower levels with a top down approach. But this is only half of the story. When you bring them back up you can prompt the context of the higher levels from a bottom up perspective.

Just as this type of exploration can help an individual understand complex systems, we can use a similar methodology as a teacher presenting material to a student.

Top down vs. Bottom up Education

Here we will use the well to structure our approach in teaching data modeling (just a subset of web development) for the sake of example. Remember, in the example of a traditional academic program the well comes into play when deciding the order/structure of classes within the program. In the Immersive context it represents the arrangement of modules (weeks).

We start with Rails generators at the highest level, and to provide context for this approach let us assume that the students we are teaching have very little prior knowledge about programming and web development.

By starting from the top, a teacher can provide the context around why a student is learning to interact with a database and how it relates to building web applications. If we approached this topic from the bottom and started directly with SQL and creating a schema, the student will have difficulty putting the pieces together and knowing how each concept relates to the big picture.

Once a student sees the power of using something like Rails Generators to enable them to create models and store data, they will be curious to explore more! And it is here that we can more easily motivate the need for direct model interaction/programming as we need more custom interaction with our database. And it is in such a manner that we descend the Well until we eventually SQL, how a database itself is programmed, and File I/O.

But the Well would be nothing if we did not go back up, and reconstruct the processes we have deconstructed on the way down. The second part of effective planning using the Well is to show the student how each of the levels can be used to construct the level above it. And in doing so provide much greater insight into not only the internal mechanics of each (enabling easier debugging), but also the motivation behind needing another abstraction.

  • How does a database read/write to a computers hard disk?
  • What power/flexibility does a declarative database language (SQL) provide us?
  • Why is the Active Record pattern most commonly encountered in web development?

The Well does not solve all of our problems however, only those at the broadest level of abstraction. When considering how to teach an individual class (or week) and how to properly arrange individual days the Soil is a much more apt abstraction.

Stratified Complexity

The problem of teaching any interdisciplinary course is often one of breadth vs. depth (given finite time to teach). If we had unlimited time, we could of course teach every topic we want in as much depth as we desire, but alas we are mortal being and must choose how to spend our time to ensure our students have the best outcomes.

What we can do however is teach more effectively given the time we have, and the Soil will help us navigate the breadth vs. depth trade-off more effectively.

HTML Rails Javascript
<p> Generators getElementById() Complexity 1
<form> Associations addEventListener() Complexity 2
createElement() Authentication Cookies Complexity 3
Web Components #method_missing Object.observe() Complexity 4

As you can see above, we have four layers of complexity, each with three different topics: HTML, Ruby on Rails, and (client-side) Javascript. Think of each individual cell (<p>, <form>, getElementById(), etc.) as a given lesson that we will use the Sandwich to plan in the next section. And each layer (Complexity 1) as a set of self-contained topics that form a complete module.

Each layer in this case corresponds to:

  • Complexity 1: a basic static web application
  • Complexity 2: a CRUD application with dynamic web pages
  • Complexity 3: a web application with user accounts/profiles
  • Complexity 4: a single page app with reactive templating

Each layer should contain topics that are complementary, have some relation to each other (i.e. Rails generators create <p> tags), and do not require mastery of topics in deeper layers.

This last point is quite important, it enables students to feel ownership of their learning and a sense of accomplishment/empowerment once they have completed a layer. It also allows students who may be more advanced that the rest of the class to not have a "glass ceiling", they can learn topics from deeper layers without disrupting their own learning trajectory or the class on a whole.

The last piece to our puzzle is what most people consider the fundamental unit of learning: the lesson. In this case it might be a lecture, workshop, or exercise and each can be seen as an atom of instruction: the smallest indivisible unit (yes... I know about quarks too).

One of the challenges with creating individual lessons is that of context: how do we present specific content without isolating it from the larger concept. Enter the Sandwich.

Context Sandwich

Often when I see other teachers present complex and technical material, they start with (and focus on) the theory or implementation details of a topic and finish with an example application (hopefully). This is the natural way to present technical concepts and is often a very good way to present material given one assumption: your audience already knows about the concept (or is familiar with very similar concepts).

This makes a lot of sense, since the naive way to plan a lesson is to think how you would want someone to present the given material to yourself (a knowledgeable audience). But the most effective educators are those that can empathize best with their students and remember the time when they themselves did not know.

When confronted with new material, students need to know the place to put that content: in my internal knowledge graph what nodes does the concept you are about to present connect to. Does Angular.js belong in the neighborhood of Frameworks (with Rails) or is it more related to the Client-side Web (next to Javascript).

In order to give students a plot of mental land with which to build up a concept house, we look to the Context Sandwich. Here we will deconstruct this analogy as it applies to a lesson on Angular.js (and client-side Javascript Frameworks).

To set the stage for a lesson, I often start with the larger context of the problems the topic solves: How do we build Rich Internet Applications in a more sustainable manner.

I then motivate the technology by the specific features that help solve our larger problem: why do we even have complex client side Javascript frameworks? In this case Angular.js provides a structured way to manage data on the client, synchronize with a server, handle user events, etc.

context sandwich

Motivating the need for client side MV* frameworks

And the last piece of the Sandwich is a concrete example that effectively illustrates each of the features of the technology that solves the larger problem. In our example here, we conclude by showing how Angular.js could help use build Gmail through its use of AJAX data synchronization to alleviate the need to reload the browser to see new emails, client-side templating to have a consistent interface, etc.

Putting it All Together

And that concludes the tour of these analogies that I use to structure my thought around creating content and delivering that content. While I have covered how each of the individual analogies can help a teacher plan, the true power comes from using all of these in concert!

Just like you do not ever teach in a vacuum, you should not plan in a vacuum. This mental framework becomes quite powerful if combined, think of each level of the Well as a layer of Soil, and each individual cell of the Soil as a context Sandwich in and of itself.

These are the techniques that I find most helpful when approaching a new topic or course to create, but I would love to hear in the comments what techniques others find most useful.

And remember, to most effectively teach a new subject I believe that a person who has recently gone through the material is best. Why? Well empathy of course. OR rather someone who knows what it feels like to not know.

Posted on Jan 14, 2015
Tags education, web