One of the things I like about being a mechanical engineer is the inherent fundamental simplicity at the heart of the discipline. Depending on who you talk to, there are 7 simple machines: the inclined plane, wedge, screw, lever, gear, wheel and axle, and the block and tackle(a.k.a. pulley). All machines can be thought of as a combination or application of those components.
As a designer, I crave simplicity. There is a beautiful efficiency to getting the job done with the smallest number of parts. As an engineer, I chase simplicity relentlessly because it tends to make the math easier. Regardless, simplicity in tech is often (perceived) elusive. However, if you dig deep enough, you usually find it.
So now to talk about something that is not (perceived) simple: programming. If you are familiar with me in the least, then you know that I do a lot of tech related education and instruction. Which is why it makes me happy to hear the increasing focus on STEM education, and the increasing organization efforts to support that. A lot of the time, that focuses on teaching people how to code. I support that wholeheartedly, however I do think that there are other aspects of the STEM toolbox that we could…you know what, that’s a different blog post. Let’s move on.
I don’t think the focus on coding is misplaced. Coding is sexy, mysterious. It makes millionaires out of teenagers, allows adults to retrain and adjust their careers, and does a whole lot of other things that mixed parts cool, important, and scary. Coding is powerful stuff, and people are picking up on this. I’m seeing advertisements on TV(Ok, ok, Hulu, as I rarely watch TV these days), and I’m hearing people I never would have thought saying words like CodeCademy.
Safe to say, I think computers are here to stay. So where does one start? What are the fundamental concepts of computer programming? A google search led me to an interesting article on that very subject. It essentially breaks down into 5 concepts: Variables, Control Structures, Data Structures, Syntax, and Tools. I like this breakdown, given my obsession with simplicity. It makes sense to me.
One of the many things I like about teaching is the consistent challenge it gives me. I can have all the knowledge in the world, (which I do NOT have, by the way) but communicating that to someone else is another matter. Communicating said information to children is ANOTHER matter separate from the previous, and it is in that situation that I often find myself.
Teaching children often considered underrepresented, has made me more sensitive to a lot of my own unconscious biases when instructing. Fundamental programming concepts, that makes sense to me, but how do I explain that to a youngster? Particularly one that may not have the same shared experiences I did as a youth? Or how do I take advantage of the experiences that we do share to express a concept?
I feel that instruction often hinges upon metaphors. To explain an idea someone doesn’t understand, liken it to something they do. This has been my mission for the past couple of years. It continuously amazes me how much a shift in perspective(along with a bit of patience) can go with certain demographic groups. Admittedly I’m a bit more sensitive to this because I was one of those demographic groups, and that is something I draw upon a lot in my teaching. Even armed with those experiences, I find my understanding and techniques constantly evolving to better address this challenge.
It is my position that a shift in perspective would be useful for programming instruction in under-served areas. Going back to the fundamental concepts of programming, I initially started there, but I found myself spending a lot time just trying to get those points across. I want to make clear that is not because of any inherent difference in ability, it just comes down to exposure. (SAT bias, anyone?)
Here is my example of an alternative perspective for programming instruction based upon the hurdles I have and continue to deal with when i comes to coding instruction:
In order of importance:
1. Accessibility
2. Equivalence
3. Time to effect
4. Experimentation
5. Organization
Accessibility
I mean accessibility here in a number of ways. First meaning: accessibility of resources. What are the resources available and what are students access to them. And I mean ALL resources. A brand new computer lab with the latest software and the fastest computers made available. That is the ideal. Reality doesn’t always measure up. A lot of my teaching has been done on whatever computers I can scrounge up, and I use a lot of open source software because of hardware requirements and availability. If students have access to tools they can use on their own, on what may not be the best hardware, then the probability of them working on their own goes up. Which is what you want.
Equivalence
As an exercise, I’ve often had students go to a webpage and look at the source HTML(Ctrl-U). In looking at the source the concept that is important to understand is that the source data and the visual page that one sees are synonymous. A change in the source will precipitate a change in the page. The best description I’ve come to for this idea is equivalence. Understanding this concept leads us to…
Time to Effect
One of the largest initial roadblocks I’ve had in programming instruction is getting students to understand what a compiler is, and why it is important. The programming workflow can be simply written as: Write Code -> Compile Code -> Run Executable. (Yes, I skipped debugging, but we’ll save that discussion for later.) I’ve often had students get tripped up in the compiler step, which is why equivalence as an idea is so important. To help lay down the fundamental blocks for computational thinking, we need to get through that middle step as quickly as possible. Having a short time to effect helps drive the idea of equivalence, or that changes in source DIRECTLY affect changes in the output. If a student gets caught up in debugging, especially with initial exposure to programming, it dilutes the impact of instruction, and at worse can create discouragement and push disengagement. Especially in beginning stages, we want to keep our students engaged, which is why we need to move source code to output as quickly as possible.
Experimentation
I am a big believer of the importance of creating safe spaces, and how important they are to facilitating learning. Just as we create safe physical space, it is also important to create a safe digital space as well. At this point, we’ve discussed the importance of having an accessible system, and how important time to effect is to driving the home the concept of equivalence. If we combine the previous three items, a situation exists that allows for experimentation. A lot is gained in STEM fields from a willingness to experiment, taking the information you know about a system, trying something new and seeing what happens. These are the type of behavior and habits that we want to instill in our future engineers. The reduction of the fear of trying something new. The confidence to not to get hung up on failure, but to view it properly as a chance to learn what did not work and to use it as a hint to what might work in the future.
Organization
After the students have started experimenting, is the time to talk about organization. Computational thinking/programming is a process, and the first step bringing new learners into that world is doing everything we can to make them comfortable in said world. Once they’ve started experimenting and figuring out some of the rules on their own, then we can start to bring in some of the accepted conventions and standards. Programming is often(but not always) a collaborative endeavor. However, even if you are working alone, the ability to arrange and structure your work so that others can follow is paramount. Also, familiarity with accepted norms and standards allows one to contribute to the larger body of work, and assists with continued self-study and improvement.
We are (slowly) becoming more aware of the difficulties faced by varying demographic groups when it comes to coding and STEM instruction. There remain varying institutional roadblocks to effectively instructing our youth in these areas. That said, there are things we can change and things we can’t, so keeping these difficulties in mind, if falls upon us to constantly iterate, view alternative perspectives, and do whatever we can to surmount these challenges with the tools we have available. I do not intend these ideas to become the end-all, be-all for coding instruction. It is another iterative step, in what should be are continuing desire to do better.
Here’s to hoping this gets you thinking.