MathPl.us - About Mr. K - Contact - BlogRoll -
Skip to content
>

Teach Like a Champion: A Review (Part 1)

A couple of weeks ago, there was a bit of chatter about Doug Lemov’s upcoming book Teach Like a Champion: 49 Techniques that Put Students on the Path to College.

I got my copy yesterday, and have barely put it down.

I need to start of with some history, first.

35ish years ago, an Architect name Christopher Alexander published a book called A Pattern Language.

The basic philosophy was:

A pattern is a careful description of a perennial solution to a recurring problem within a building context, describing one of the configurations which brings life to a building.

Each pattern describes a problem which occurs over and over again in our environment, and then describes the core solution to that problem, in such a way that you can use the solution a million times over, without ever doing it the same way twice.

A pattern language is a network of patterns that call upon one another. Patterns help us remember insights and knowledge about design and can be used in combination to create solutions1.

The thinking here is powerful – there are good ways of doing things, and bad ways. Without a language to talk about this, not only can in not be discussed, many people may not even know that the issues exist in the first place. Furthermore, these ideas do not come out of the abstract, but are based on the observations of existing buildings and how they affect the community around them.

I was exposed to this through software engineering, maybe 15 years after the publiation of Alexander’s work, by the seminal Gang of Four book. They applied the same methodology to software – why is some some software healthy, and other software sick? Two pieces of code could do exaclty the same thing, but one was easily maintainable and extensible, the other a terror to work with and would generate bugs seemingly spontaneously. They looked at huge amounts of code, found common patterns, and created a common language that could be used to discuss the issues. This language (such as Singletons, Bridges, Factories, and Iterators) has ingrained itself in the software world, providing a common language in which to discuss best practices.

Lemov has independently replicated this process. Many of the points from his introduction map directly to concepts from the pattern community: Identify best practices through diverse observation. Provide simple names with which to refer to those practices. Provide examples in which the practices are presented in a variety of contexts. Provide a map of connections between the practices to allow for their merging into a synergistic whole that is greater than the sum of its parts.

He has succeeded admirably at this.

I will delve into more details of the book in part 2.

1 From the Wikipedia Article, which I also strongly suggest everyone read.

{ 2 } Comments

  1. Tom Hoffman | June 21, 2010 at 10:32 am | Permalink

    Lemov’s book does not define a pattern language. In your next post you explain that these are “techniques.” Patterns aren’t techniques. They aren’t prescriptive. It is a much more complex and profound system.

    Even the best writing on software patterns is a fairly hackneyed application of Alexander’s work.

    On a deeper level, Lemov’s approach is completely antithetical to Alexander’s. Lemov is driven by data; Alexander values human feeling.

  2. Mr. K | June 21, 2010 at 4:04 pm | Permalink

    Thank you for that response. I can’t disagree with anything you’ve said. (Well, except that I think Alexander used both data and emotion to find his patterns – they were mined from existing best practices, not some ideals that he felt would satisfy human needs without ever having been put into practice.)

    Yet, yet –

    I think we need the ability to have a language to discuss what constitutes good teaching. We don’t have that, yet. And whatever it is, it will involve a number of interdependent ideas. And I think that, whatever language we end up with, it will look something like this, a way of pinpointing common situations that lead to unsatisfactory results, and simple methods for changing that situation, often in conjunction with something else.