Feasted on Chang Sho last night with Thatcher, a fellow 40-year-old, a college bud who programs for Google. He described a "U" in the history of programming. I paraphrase b/c I was too busy with the moo-shi to take notes:
"In the early days of programming, time on the mainframe was hard to get. You wrote code on paper. Then waited your turn. If you had an obvious glitch, the program would fail, and you'd lose your turn. So programmers would check each other's work before they actually ran it on the computer.
That changed. The personal computer eliminated wait time. So in the 1980s and 1990s, the tag-team waned. As a young programmer, I never had anyone check my code. I'd just try it out, fix, try it out, fix, etc.
But at Google, and many other companies, checking the code for someone else is a ritual. Our rookies are often not used to it. For every X time spent programming, another .3X is spent by a peer who checks, and another .3X is spent by revisions. We do this for every single thing we write. At first, the rookie is kind of defensive. Then you get used to it.
Also, here's what doesn't work. A weekly or monthly meeting to check samples of each other's code. Because then it's an extra. The only way this works is if checking is part of the daily work, the real work, and not an extra.
Intriguing. Our charter school, over the years, has had Teacher Rounds stop and start. That is, a group of teachers would commit "checking each other's work" by observing. Then meeting once a week to discuss a single teacher.
But as the year wears on, with all the competing demands on a teacher's time, often the Rounds sputter. Per Thatcher, this cycle of feedback feels like "an extra."
Since January, our middle school has launched an effort where every teacher is supposed to do one peer observation, maybe 10 minutes or so, each day. And write it up. I know it was still rolling in February. I need to check if it's still humming along, and what value teachers believe they get.
One thing that rarely happens, however, is teachers reviewing each other's lesson plans in advance, like Google programmers reviewing code. The theoretical upside is that improvements can happen before kids are on the receiving end.
A few charters, I believe, actually manage to get principals to review lesson plans in advance. Others, like ours, have tried it but haven't been able to stick with it. One aspect is the just-in-time nature of lesson plans. Another is principal bandwidth: because of the crisis-du-jour, our principals have found it tough to really "check the code" each weekend, and therefore (appropriately) felt bad about enforcing a rule that teachers needed to submit lesson plans in advance, because teachers never got value back.
What can rookie teachers do? Many skilled teachers are eminently bribable with kindness, coffee, and cookies. So arrange your own feedback loop if your school hasn't done it for you.
Through bribes and gratitude, you lock a mentor teacher into giving you 15 minutes a day, so it's part of the regular work, not an extra. 5 minutes to watch a snippet of your class. 5 minutes to talk to you after with concrete feedback. 5 minutes to scan your lesson plans or tests or quizzes or classwork or homework assignment or ticket-to-leave-and-Aim.
Arrange that, and who knows? I could imagine a 20% bump on kids' total learning on that feedback loop alone.