Legitimate Peripheral Participation

LegitimatePeripheralParticipation is a term for how a member of a CommunityOfPractice learns. It is from this book:

Situated Learning: Legitimate Peripheral Participation, by Jean Lave and Etienne Wenger

ISBN 0521423740 Here is the blurb at the front of the book. The style is scary (to me) because the jargon is different from what I'm used to. My book review follows.

: In this volume, Lave and Wenger undertake a radical and important rethinking and reformulation of our conception of learning. By placing emphasis on the whole person, and by viewing agent, activity, and world as mutually constitutive, they give us the opportunity to escape from the tyranny of the assumption that learning is the reception of factual knowledge or information. The authors argue that most accounts of learning have ignored its quintessentially social character. To make the crucial step away from a solely epistemological account of the person, they propose that learning is a process of participation in communities of practice, participation that is at first legitimately peripheral but that increases gradually in engagement and complexity.

My review:

If you're a caricatured "hard AI" person, knowledge consists of statements in some formal language, such as:

(if (bird ?x) (flies ?x))

The learning process consists of transferring those statements from one mind to another.

The authors argue that learning is a property that emerges from certain social interactions, and that learning is more a learning to do than a learning of things. They further claim that this learning is done in a particular way, which they call "legitimate peripheral participation". Here are its key elements.

The novice begins to learn by doing "peripheral" simple activities. For example, a novice Vai or Gola tailor begins by adding buttons or hemming cuffs. Note that this is not "make work" or practice: it's a real participation in the task. The novice always produces value.

Over time, novices take on more central tasks. The tailor learns to sew, then to cut.

Learning is ordered in a way that makes it easy to progress. Novice tailors start at the last step of production and learn their way backward:

: Reversing production steps has the effect of focusing the apprentices' attention first on the broad outlines of garment construction as they handle garments while attaching buttons and hemming cuffs. Next, sewing turns their attention to the logic (order, orientation) by which different pieces are sewn together, which in turn explains why they are cut out as they are. (p. 72)

In contrast, navy quartermasters learn their task forward, in the order in which information flows through the system. They start by taking measurements, and learn next to perform each of the steps by which a position fix is determined. Still, as is the case with the tailors, each learning step causes the next one to make more sense.

Throughout this process, "there is very little observable teaching; the more basic phenomena is learning." (p. 92) What that means is that there's no "special form of discourse" directed at apprentices or intended to bring them more toward the center of the practice. There aren't lectures or courses. There are people doing things and other people commenting on them.

The learning process is one of conversation, both between novices and masters, and also between novices. Especially important are "stories about problematic and especially difficult cases." (p. 108) Learning is a social experience.

The end result of this learning is that one becomes a member of a CommunityOfPractice, one transforms one's identity, one comes to speak and act in ways that mark you as a community member, one learns actions that match task-relevant situations, and - perhaps - one gets predicate-logic-like statements about birds into one's head.

Their analysis of learning rings true to me. I, like so many others, really learned to program by latching onto a big project. Two at once, actually, but I'll only talk about GNU Emacs. I started out peripheral - local customizations using the surface features. I moved closer to the center, fixing a few bugs and adding some features to shell mode, then adding a whole RCS interface mode, then working on the low-level unexec code. I learned by watching what Stallman did from version to version. I learned by seeing which patches he rejected, which he modified and how, which he took unchanged. Design principles that never made particular sense to me when I heard about them or applied them to toy classroom programs made sense in the context of this big program.

And, yes, it did change my identity. I was an Emacs user, in contrast to the benighted vi users. I sneered at their pathetic pipes-and-filters monomania. (Imagine! Forking a separate shell just to format a paragraph!) They sneered back and made comments about "kitchen sinks", which did not faze me - or others: note that ntemacs's icon is a kitchen sink. Emacs helped me make the transition from a hedgehog to a fox. (See HedgehogAndFox.)

Because this book rings true, I think it's worth reading. Many will find it frustrating. It uses social science jargon, not ours. The authors are in a different CommunityOfPractice, and they are speaking and acting in ways that send appropriate messages to their community and neighboring communities. Some of those messages seemed completely off-topic to me, but I'm not a member of their intended audience.

Moreover, the book deliberately doesn't aim for precision. Since it is all about how the connections between world, activities, and people generate knowledge, it spends its time talking about particular situations and particular connections and the relationships those suggest. It eschews precise definitions of what it is that is connected. They make, for example, no attempt to describe exactly what would be the difference between legitimate and illegitimate peripheral participation, and are proud of the fact.

-- BrianMarick

This is one of my all-time favorite quotes (from the book), although it has precious little to do with the main thrust of the book:

"The world carries its own structure, so that specificity always implies generality (and in this sense generality is not to be assimilated to abstractness): that is why stories can be so powerful in conveying ideas, often more so than an articulation of the idea itself."

That sentence is used to justify the authors not abstracting out their lessons, but telling the stories they encountered. --AlistairCockburn

This is about the eighth time I've read this page, and I'm afraid I still don't understand a bit of it. For me, this stuff has a very large GingerFactor.

Read ExpertInEarshot, which is one practical application of LineOfSightLearning?, and see if that helps. Legitimate Peripheral Participation means that a novice does participate (not only watches), but participates peripherally, or on low-risk or easy items while getting better. They can see the way forward to being better and getting more advanced assignments until they reach the center of their craft.

Actually the book itself is easy to read, because it is a narrative describing apprenticeships among tailors, Navy signalmen and butchers. The doubletalk is in the intro, for those among us who like that kind of doubletalk.

Thanks for the link to ExpertInEarshot -- that's one of the best patterns I've read. Beautifully written. I understood every word you said, too -- maybe they can get you to write the intro for the next version. Then I'll buy it.

Tell me and I will forget.

Show me and I may remember.

Involve me and I will understand.

I'm concerned that someone thinks this page has a high GingerFactor. BrianMarick says that the book does, and says why. But the page is very clear to me. Perhaps that is because I know Brian well. So, I'll take a crack at it.

The point of the book is that the best way to learn complex skills is to be part of a team working on a problem. If you are a novice, you should do low-level grunt work that is a necessary part of the job, not just exercises. You need to work with experts, to see them work and have them criticise your work, and to gradually build up your expertise. The reason why apprenticeships work better than classroom learning is that expertise is more than just learning a bunch of facts, it is learning a way of thinking. Learning a new way of thinking makes you a new person. Learning a new fact does not. You learn a new way of thinking by being placed in a situation where everybody thinks that way, and gradually learn to speak their language.

For example, I have friends who are farmers. Their parents were farmers, and they helped out on the farm at a very young age. Often fairly young children drive tractors. They have to learn to drive in a straight line, but they don't have to know what or where to plant, whether to attach a plow or a planter, or even which direction to make the rows go. They don't know how to fix the tractor, though they might know how to load it. Over time, they learn more and more skills, partly by watching their parents, and partly by having their father or mother deliberately teach them a new skill. By the time a young farmer is ready to graduate from high school, he or she is quite capable of running a farm. They almost all go to college to study agriculture, however, because farming is constantly changing, and they need to learn theory to make it easier to figure out which changes to make to themselves. But it is interesting to me how farmers around here tend to have similar world-views. Their parents didn't just teach them to drive a tractor, they taught them how to think about work, how to judge whether something was worthwhile, and how to organize their time.

Programming is taught backwards from this. First we stuff students' heads with facts. They get some practice in school; the better students get a lot of practice and can actually understand the facts we stuff into their heads. But the practice usually comes from summer jobs or student-run projects (writing the next great game, or building a web site for a favorite rock group) and school not only doesn't encourage this, it discourages it because of all the work placed on students. So, most students don't really learn to perform well until they graduate and start to practice and to work with experts. Students who practice but DON'T work with experts learn much more slowly, and often never reach expertise.

The way most companies deal with the fact that new programmers don't know how to program that well is to either make them "coders" or stick them in maintenance or testing. If they are "coders" then they will work under the direction of a "designer" or an "architect" who will give them fairly detailed instructions. Testers usually work with experienced programmers and can watch how they respond to bug reports or answer their questions about what the system is supposed to do. Maintenance programmers hope there is an expert around to help them learn the system, but sometimes there is none, and they won't learn as much.

Anyway, this book is a serious study of how people learn by working with experts. It won't be an easy read for us, but is probably worth reading by anybody who takes education seriously. -RalphJohnson

CategoryBook