Last summer during a session run by Damien Barrett at one of my school's professional development programs, I was introduced to computer coding. I don't remember anything about the finer details of what we did that day. I don't remember the language we learned or the keys we pressed to make websites work. But I do remember something about one of the habits of programmers. Coders, according to a video we watched at the outset of our training, are the kinds of people who will spend 25 hours building a program to complete a task that takes only 2.5 seconds to complete.
Initially, this idea made me laugh. It sounded absurd and extreme. But humor is often, as George Saunders said, "what happens when we're told the truth quicker and more directly than we're used to."
What I learned, quickly and directly that day, is that programming is at least in part about slowness. It's about the long-view -- if a task takes 2.5 seconds but you have to complete it 10 times a day, 5 days a week, for many years, it makes sense to invest some time upfront to save that time on the backend. This approach only fails to make sense if you feel that you couldn't possibly find the time right now to design a system that could save you time in the future. After all, 2.5 seconds right now doesn't feel like much. So you keep writing the grocery list from memory; you keep rushing out the door in the morning and hoping your various family members have everything they need for the day; you keep grading the stacks of quizzes and turning them back in the hopes that such transactions will somehow improve student learning. We move faster to move faster. But maybe we're doing it wrong. If we're not very good at something, doing it faster doesn't seem like a sound plan. Maybe we should focus on doing it right first.
To work towards a rule of thumb:
It takes time to slow down, initially, to go faster, eventually.
Said more economically, slow down to go faster.
Or, as my friend and colleague Reshan Richards said when I told him about this post, even more economically and eloquently, slow faster.
From the moment I grasped the "25 hours < 2.5 seconds" idea, I have seen possible applications for it almost everywhere I turn. It's only slighlty tongue-in-cheek to say that wasted motion, duplicated effort, and the reinvention of wheels are among the chief activities of many people in schools. But like the drips of leaky faucets, such daily non-efficiencies can begin to wear on one's nerves. What are you doing to stop the leaky faucets in your school?
When you grade a stack of essays, do you keep a running tab of common errors or do you rush through the pile in order to return the papers and move on? The latter is a short game; the former is a long game. Certainly it takes extra time to perform a meta-analysis of your grading as you grade, but such attention to detail will help you to prioritize your instructional time, and therefore help your students to improve in those areas where they most need attention. As my colleague Erica Budd pointed out -- just a few days ago -- at a workshop she was running for teachers at my school, there's a big difference between "looking for answers" and "looking for assessment data." Looking for answers is helpful in producing a grade right now; looking at assessment data is helpful in producing the next lesson plan, the next unit sequence, the next fully formed student understanding...
Another way of posing the question is to frame it for school leaders. When something goes wrong in your area of school life, do you take the time to examine the conditions that led to the problem in the first place, or do you just put out the fire and rush to the next one? Do you update policies and checklists to ensure that the small, non visionary work of school functions efficiently?
A final, and I think most important, way of posing the question is to frame it for students. How do we model the concept of slowing faster for students who are up against daily deadlines, whose days are arranged like a gauntlet of tiny hourglasses they slide through whether they want to or not?
I saw such modelling done exceptionally well when Reshan Richards (mentioned above) spoke to our juniors and their advisors. Our junior advising program asks students to think about their developing stories; Reshan met with the junior class to teach them some basic design principles to help them tell those stories more effectively.
He started with a slide that, to his eyes, was not very well designed. Notice the multiple font sizes and colors; notice the way the text runs into the bottom image.
The students in the audience were easily able to identify the problems with the slide, creating a perfect transition for Reshan to share some lessons about fundamental design principles. He showed the students fonts and color wheels; he gave them advice on selecting and sizing images; he explained the best way to tell a story; he showed them how the best presentations, the best storytellers, are deliberate.
Then he showed them how he would re-design the initial Three Little Pigs slide, using the design principles he had just discussed. He started by framing the story in a clear and compelling way:
And then he focused our attention on specific images, placing our heroes at the bottom of the frame, as if they were lost in the cosmos:
He added background:
He altered colors and zoomed in to indicate that the pigs were moving:
And then he introduced the antagonist:
He had the students (and their advisors) hooked. Even though we had heard the story before, we were compelled to know what was going to happen next. But then Reshan stopped. And, for me, this is where his presentation became truly special. He said, "this is as far as I got . . . and I felt a little bad about that, but then I realized that there's another lesson here. Doing this kind of work, getting better at design, getting the details right, takes a LOT of time. You can't do this work quickly. Especially not at first. You have to add things and then take them out. You have to try different colors next to each other and then make adjustments. You have to rehearse and make changes to your presentation. You have to change the order of the slides and then change them back . . . only to change them again."
In a way, he was saying, if you want to master a complex discipline, you have to start over and then take your time with each step. You have to fumble and tinker and discover the textures and nuances of your craft. You have to think just a little bit like a programmar, who creates his/her code line by line by line, through trial and error, in search of the simplicity that is also known as elegance. To get there, you have to slow down . . . faster. We all do.
As a coda to this post, I think it's worth pointing out that the learning process documented herein would not have happened if I did not slow down to attend (1) a summer workshop on programming run by a colleague, (2) a mid-December workshop about formative assessment run by a second colleague, and (3) a mid-December presentation about design thinking run by a third colleague. These opportunities were neither convenient for a busy administrator, nor mandatory. But each of them supported the long-term work (with students, in schools) in which I have chosen to engage. They support the constant layering necessary to get good at this work. I should add, too, that the learning process documented herein would not have happened if the colleagues mentioned didn't slow down enough to teach me. And that slowing down enough to blog about my learning process helped me to crystalize that process. You get the idea. Now use it.
The leaky faucets comment comes from Dan Saffer (who was paraphrasing Charles Bukowski).