I may have bitten off more than I intended to chew last week, when I began teaching the Apple computer program Terminal to my students in our Digital Arts and Sciences curriculum in seventh grade. For those who don’t know, Terminal is a command-line program, which allows one to navigate one’s hard drive via text commands rather than Graphical User Interface (GUI) commands. It’s a layer closer to machine code than many of them are used to, and it’s a layer closer to the actual way that a computer operates than most of them really understand yet.
See, graphical user interfaces are actually a shell or interface between you and how your computer actually works. On an Apple computer running Mac OSX of any level, as I understand it, the mouse clicks and the movement of the mouse’s X/Y axis are essentially giving instructions to Terminal, which is then translating those instructions into machine code for the computer’s hardware chip to read. It’s more complicated than that, but the essence of it remains the same: the graphical user interface is a façade operating in front of the real software mechanisms.
I’m using Appendix A of Learn Python The Hard Way to teach the use of Terminal, and kids are finding it annoying. But they’re going to thank me when it comes time to write python programs, or at least I hope they will. In the meantime, I’m finding it mildly scary for myself to be learning how to run computer commands this way. It’s also been useful, though — when I found a program-test to see if the Shockwave bug in Bash affected me, I was able to figure out how to do the test.
I never intended to be a computer science teacher. If you’d asked me ten years ago what I’d be doing in a decade, I’d have told you, “Teaching history.” But teachers have a funny way of being thrown for a loop late in their careers. Either they become skilled at a new area of study, or they become administrators. I’ve become a little of both. My computer science classes are still weighted heavily toward multimedia and typing and learning to make presentations, but at the same time I’m leaning into my weaknesses, and learning how to be a computer programmer and a teacher of computer languages. It’s scary. But at the same time, it’s going to make me a much more powerful and flexible teacher in a couple of years than I am now.
The result has been fascinating. I’ve been teaching some of my students geometry a year earlier than they would normally be exposed to it, by showing them how to use vector graphics programs to lay out geometry proofs. It’s good practice for them, picking color and shape and line, and designing a problem’s solution-space. Some of the kids have taken to animating them. Others are working on short animated videos. Still other students are learning to type, while others are learning HTML and CSS — first at the level of typing commands, and later on using a dedicated editing program.
It’s a bit of future shock, though. For me, and for them. So much of the class is not about learning, but how learning. They’re learning how to program, how to build slideshows, how to choose fonts and colors and shapes. It’s hardly what they normally experience in school. It’s been hard learning for me, too — learning how not to touch the keyboard and mouse, learning how to give verbal and visual instructions instead of simply taking over their projects. It’s been wild to discover the actual boundaries of what “digital natives” genuinely know how to do (which is more limited than we suppose).
I took up the role of our Design Thinking director at my school in part to teach many more hands-on skills with hammers, saws, knives and drills. Instead of doing that, I’m teaching kids to manipulate bits and bytes: to be graphic designers, slide-show creators, better typists, and now computer programmers. It’s still design, but it’s a weirder kind of design than I expected to be doing. So it goes.