eXtreme Education

I feel like I’m slowly converging on some good ideas that have been floating around long before I noticed them. Again, in the book I’ve been reading, Standards for Our Schools, I came across some good material. The authors were discussing “instructional technology” and noticed that much educational software is rather bland. It aims to reproduce the instructors job. Remember from my last post on the cultural differences between math instruction in the U.S. vs. a popular technique used in Japan, that we have come to expect the instructor to demonstrate how to solve a problem, before the student is asked to run some practice exercises. The authors note that our educational software attempts to fulfill this role, with rather disastrous consequences: “Nothing could be more emblematic of the mass production classroom than the glassy-eyed stare of young people doing the same drill-and-practice exercises that they used to do in the workbook.”

But learning doesn’t happen this way. Rather, the authors acutely observe:

Think of the humble word processor. Earlier in this chapter, we pointed out that writing is a craft that one gets better at when one has to do the same writing task repeatedly and is critiqued and coached between tries by a more experienced writer and editor (in this case, one’s teacher). No tool could be more brilliantly conceived to support this process than the word processor. … The physical task of editing and printing the text has been made effortless, leaving only the intellectual task of improving the quality of the writing.
[and earlier in the same chapter…]
Writing is just as much of a craft as carpentry, but consider what we do. We ask a student to write a paper. We grade it. We may put some comments on it and then hand out another assignment. This house will never stand. If we were as serious about student writing as we are about the carpenter-to-be, we would ask a student to write a paper, give the student extensive comments on the paper, and ask the student to write it again and again until it meets a high standard for a paper of that type — and then do it again with a more complex and ambitious assignment.

This observation meshes with a bullet I caught in Jim Stiegler’s talk: practice, but not repetition. Fundamentally, as a neural network, our brains train effectively when seeing variations on a theme. The theme needs to be practiced so that neural pathways are reinforced. But repetition is boring, tedious, and awful. Fortunately, it can be avoided by varying the problem details. The most effective variations will be things that require following the same analysis, but which have a different outcome. That is, we don’t get good variation by simple variable substitution. Instead, we must force a re-analysis of the problem by challenging embedded assumptions, examining corner cases to weed out erroneous mental models, etc. Coming up with these variations is a clearly difficult exercise in itself, which only goes to prove that you really understand something only if you can explain it to others.

So, now that we know how we learn effectively, how do we organize the classroom to support this kind of activity? For computer education, the most closely related coding discipline I can think of is eXtreme Programming.

I’ve only just begun to look at XP, via Kent Beck’s book, Extreme Programming Explained: Embrace Change, but so far, some key items stand out:

1. Communication: In the pair programming model, you have to be able to communicate to your partner (and by extension in the real-world, your fellow teammates) what it is you are doing and why.
2. Code Review: Your partner is there checking the quality of the code you’re producing as a team. You also check your partner’s suggestions. In this manner, you’re challenging each other’s approach, and subjecting each other’s arguments to some analysis.
3. Testing: Integrating a test suite is the best, most effective way to directly challenge any hidden assumptions in lurking in the code.

Although there are plenty more benefits, that I’m sure I’ll get to later, I only need these items to make my point, and integrate the two topics introduced so far. If we learn in the way observed above, then using the practices of XP seems like a clear technique to improve student performance and understanding.

1. By requiring communication, students will learn to use the vocabulary of our field, and come to understand the important issues that connect this vocabulary together. Forcing the student to communicate the issue clarifies their thinking, and helps them to refine their mental model.
2. By continuously performing code review, the student learns that getting things correct the first time is practically impossible. Rather, we expect continuous improvement. Hard work and effort pay off. Secondly, the review consistently challenges the student’s mental model. Together, the pair must agree on expected behavior of the code changes.
3. By testing the code, incorrect or incomplete analysis is readily identified. The students also increase their ability to become their own coach.

Because the practices and principles of XP have build-in mechanisms to continuously reinforce neural pathways by variations on a theme, I think it makes for an effective educational technique. Searching Google Scholar for ‘education extreme programming’ shows that I’m about 10 years late coming to this conclusion.