On Teaching: A Few Useful Analogies
Jan 14, 2015 · 2859 words

Techniques and Abstractions for Learning

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 @psychothan any approaches that others find useful!

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: Sandwich1
1🙏 to Ryan Orban for introducing me to The Context Sandwich (and generally just being a great friend and collaborator).

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.


When I say program, I am referring to a cohesive educational offering. Whether it is a Computer Science Undergraduate Degree or Software Engineering Bootcamp 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.


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 month/week’s unit.

The challenge of creating an effective course is often 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.


A lesson slips even further down the spectrum and can mean many things to many people. In the Galvanize Software Engineering Bootcamp, 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 concept they have learned. The two forces at work are the forest and the trees, The Sandwich is how we can see both.

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:

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.


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 abstraction

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, gives 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 reach 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.

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

Let’s return to the breadth vs. depth problem of teaching an interdisciplinary course (given finite time). 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.

<p>GeneratorsgetElementById()Complexity 1
<form>AssociationsaddEventListener()Complexity 2
createElement()AuthenticationCookiesComplexity 3
Web Components#method_missingObject.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:

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 the 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 a 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).

It 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 that the topic solves: How do we build Rich Internet Applications in a more sustainable manner.

Then I 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 the front-end with the server, handle user events, etc. the context sandwich analogy

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 us 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.

Like what you've read so far?? Jonathan also makes videos! YouTube Channel Subscribers Give him a subscribe. Go ahead. Do it. I'll wait... But only if you want to 🥰

Putting it All Together

And that concludes the tour of these analogies that I use to structure my thoughts around creating and delivering 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 The Soil, and each individual cell of The Soil as a context Sandwich in and of itself. And 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.

These are the techniques that I find most helpful when approaching a new topic or course, but I would love to hear what techniques others find useful! And remember, when in doubt… plan backwards 👌

Creative Commons LicenseOn Teaching: A Few Useful Analogies by Jonathan Dinu is licensed under a Creative Commons Attribution 4.0 International License.

back · courses · consulting · blog · vita · twitter · youtube · github · colophon