Before I was a teacher, I was a computer programmer. It wasn’t a long career. An unsatisfying summer internship saw to that. But to this day, I am amazed at how much my programming experience impacts my teaching – especially when it comes to planning units.
My computer classes at Pepperdine University taught me to write programs using an approach called Top-Down Design. I start by developing a clear picture of what the program is meant to accomplish. Next, I put into place an output protocol that allows me to ensure that the program is working correctly. This is quality assurance. With this end in mind, I begin the process of writing code that meets the desired outcome.
Depending on the size of the program, this can be an arduous chore. Therefore, the Top-Down Design approach suggests thinking of the program as a series of smaller tasks. I simply write “black box” procedures or functions to accomplish these tasks that I fill in later. Each of these “black boxes” includes some output protocol that allows me to monitor the progress of my program and make adjustments as needed.
Now I am ready to write the code for the “black boxes.” As I make my way through writing the program, I execute test runs during which I check the outputs I put in to monitor the program’s progress. That way, when problems arise I can address them immediately. If I wait until the end to see if the program works it is often too late or too unmanageable to make necessary corrections. (This reminds me of Tom Wujec's TED Talk.)
Once the program is complete it is time to put it to the test with real, messy data. Chances are there will be some bugs that I didn’t anticipate. Fortunately, if I wrote the monitoring outputs correctly, then I have feedback regarding where the problem is and what I need to do about it. More often than not, this results in a successful program that accomplishes its goals.
What does this have to do with unit planning? Those of you familiar with Understanding by Design probably see the connection between the Top-Down Design approach to programming and the essential elements of the unit planning design developed by Wiggins and McTighe. Anyone struggling with the connection between programming and unit planning might replace “program” with “unit,” “output” with “assessment,” “black box” with “lesson,” and “real, messy data” with “learners.”
If not, maybe this diagram might help. The summative assessment is the goal of the program. Formative assessments represent the output protocols that I will use to monitor learners' progress toward the goal. And the experiences are the lessons that I will develop that supports this progress.
If not, maybe this diagram might help. The summative assessment is the goal of the program. Formative assessments represent the output protocols that I will use to monitor learners' progress toward the goal. And the experiences are the lessons that I will develop that supports this progress.
I learned to write unit plans after I learned to write programs, but I initially did not see the connection. I planned my units like I was planning a parade - one lesson after another until it was time for a test. And then the test only checked to see if the learners had paid attention to the parade. Planning with the end in mind from the start makes so much more sense and results in a much more coherent curriculum.
I hope you plan for and find success.
I hope you plan for and find success.