A few summers ago 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?
The leaky faucets comment comes from Dan Saffer (who was paraphrasing Charles Bukowski).