…I’ve been here for years. (Couldn’t help myself) Who knows if anyone reads this, but I finally got around to some much needed website maintenance, and now the blog is working again. Current events have definitely affected me in a myriad of ways, and for that and other reasons, I decided it was time to wake this beast of a blog from it’s slumber.

A habit I’ve endeavored to break over the years is talking about what’s coming. I really just prefer to do the thing and then just talk about the fact that it’s done. Works a lot better for business environments. There’s a whole bunch I would like to say about my plans for this site moving forward, some of the content I’m working on and all that noise. So I’m going to skip all of that and we’ll just have to see what happens.

I’m going to paraphrase a quote from a recent interview Dr. Cornel West gave on Anderson Cooper’s CNN show that’s been making the rounds on the internet as of late. Try, fail, try again, and “Fail better next time.” Here’s to failing better than we did before.

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.

Recently, I was hanging out at a friend’s house and the subject of the Black Lives Matter movement came up. Now myself most often being the only black person(or a member of a single-digit cadre)around when these questions come up, I’ve gotten quite used to having these discussions. It’s a nice benchmark of how comfortable someone is with me when they start asking these questions.

My friend while appreciative of the movement’s larger aims, was perplexed at the font choice on some of the t-shirts. His position that the choice of Comic Sans to convey the message “BLACK LIVES MATTER” might dilute the desired impact of the message. (Ironically, Impact is another overused font in urban environs, but we’ll save that discussion for another day…)

In a situation that continuously repeats the longer I live in California, as I digested his assertion of improper font choice, I came to the conclusion that…yeah, he had a point. What I find even more interesting is prior to that exact moment, that thought had never crossed my mind. One of the things about growing up in minority urban environments, is that…you just get used to things. Some strange, some terrible, and others just plain unnatural.

It was at this point that I started to think about my own experience with Comic Sans. I was always somewhat computer capable as a child(remember, the internet hadn’t blown up yet), coming into the fold just before America Online(AOL) started mailing out free CDs. Sidenote: There are people in this country that STILL use AOL. I think one of the CIA guys had his AOL email hacked recently. That was one cool thing about growing up where I did, being able to explore this thing that not many people understood, and fewer cared about.

If I had to distill STEM thinking to it’s core, I would say it starts with a question. “I wonder what happens if I do this?” In this usage, “this” can literally be anything. You have a process, a way of doing, you alter…something, and see what happens. I spend a fair amount of my time on youth STEM initiatives, so I spend a lot of time thinking about ways to engage students. In so doing, I reflect a lot on my own experience.

One of the first things you learned how to do on a computer(at least in those days) was word processing. Typing. As we learned where all the buttons were, you start to poke around. Eventually you learn that you can change the text size, center justify…but you turn that corner when you find out that you can change the font! (And through that you learn what a font is.) And your head explodes. “You mean the letters can look different!”

Now as I’ve moved along my own professional path, I continue to be a student of design. Which is funny because at the beginning of my career, that was something to be left to the artsy people. Call me when you want to build something. I like to think about, talk about, analyze design because it is something that affects us all, whether we like it or not. Even if we don’t realize it. There is this subliminal quality in the visual that can evoke a physical/emotional response. That is magic to me. (Not like magic, IS magic)

“Any sufficiently advanced technology is indistinguishable from magic.” – Arthur C. Clarke

As I moved along my journey from high school to college and beyond. I picked up little bits here and there. White space, negative space, hell, space in general. One of the things that struck me was how strongly people felt about fonts, and to a lesser degree the vitriol directed at Comic Sans. Disclaimer: I used Comic Sans as my AOL Instant Messenger(AIM) font back in the day. Thought it was cool and fun. Of course, now I know better. I feel that Comic Sans hate is just one of the rules of the internet that people eventually learn.

For all the vehemence Comic Sans generates, thinking strictly as an engineer, I think there is another legacy as well. Earlier, I described engineering thinking as, “What happens when I do this?” I think of 12 year old me in front of a computer screen, poking the edges, finding out where the limits are, and perusing through font choices. The fact that the font that I (and others) picked generates the largest absolute value emotional response can’t be ignored. It’s a first step. A clumsy, ill-informed first step, but a step nonetheless. There’s value in that.

Also, as someone who spends a great deal of time trying to get kids to care about tech, I’ll take whatever I can get. By any means necessary. Wait, that’s a quote by a different guy.

I would say that as an engineer, you have not experienced fear until the moment someone installs a part you have designed. Something that I have noticed over the years through multiple work environments, is the desire to get it right the first time. Now some may look at that statement and say, “Of course you want to get it right the first time!” Which is true, somewhat. Design is an iterative process, and sometimes steps have to be repeated. Prototyping is essential.  In some instances, you don’t recognize issues until the part is in your hand and you’re looking at it. Of course as you repeat any process, you apply lessons learned, streamline, and quicken said process.

The issue that comes forth is when the streamlined process is expected right off the bat. Faster, cheaper, better is always what management wants. The importance of prototyping is diminished because similar work has already been completed, and individuals can build from that. Or that’s what your boss thinks, at least. Vertical pressure notwithstanding, there is always a since of foreboding with any recently built design. The self-reflection, checking, and internal questions. “Did I miss something? What if it fails? Maybe I shouldn’t have made that assumption…” As the engineer, if that part fails everyone immediately looks to you as the cause. (I mean you designed it.)

While design problems are the reflex answer, by no means are they the only possibility. Material deficiencies, production, improper scope, there are numerous cause that can lead to problems with design implementation. However, as is often the case with design(and business for that matter), the first task is proving that the problem isn’t your fault. It’s the fear of that situation that gives me butterflies whenever I see a part I’ve designed in use the first time.