Modeling & Coding for Understanding

ibm-flowchart-template

This is the start of my life in programming. 10th Grade. Downingtown High School in Pennsylvania. My father told me of an after-school class being taught by two teachers from a local college-- West Chester State College as it was known at the time (1970). In my first class, I was provided with a blue/green IBM plastic programming template. I think the first assignment was to write a program that read a count (N) of numbers, averaged these numbers, and then output the average of the numbers. We had a card punch machine in the school, and our card decks were shipped to the College for processing. Later, we received our green-striped paper output. It was a long process. Although some may see programming as a sort of automation, I was creating a new "machine" with each program. Imagine being told that you could create a machine, but that you'd need to "write" a machine rather than build one. This is the essence of programming. Even today, a program is a mental model of an ethereal machine--stuff that moves around, is stored, and manipulated. Writing doesn't really do the "machine" justice. It is really all visual, a mental model, and I used writing because that is all that was available. Today, coders and modelers do the same thing -- they create imaginary machines that are not quite real--all existing in the head, but real enough to reason about unless too many weeks have passed, and the formerly crisp memory of the machine begins to decay. The goal of programming and modeling is not to automate a task but to understand one. What better way of understanding something than to design a machine to recreate that thing? Want to know how to bake an apple pie? Write a program. Create an apple pie machine. As the old saying goes, if you cannot write a program (or make a machine) then you don't understand the task sufficiently.

One thought on “Modeling & Coding for Understanding”

Comments are closed.