Category Archives: Musings

A Different Perspective on Programming Instruction

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.

Comic Sans and STEM: A retrospective

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.

Alan Ware, “Cyber Expert?”

news10Last week I was on KXTV 10 Sacramento, the local ABC affiliate station, to answer questions related to the recent Anthem/Blue Cross/Blue Shield hack. The data breach has been in the news as of late, you may have heard something about it. Actually, this is the third time I’ve been on ABC 10 in about the last half year. I wonder if I’m quickly becoming their resource to talk about computer-y stuff. Which I am totally okay with, by the way. (Also, big thanks to Walt Gray for inviting me down to talk for a bit.)

It’s a bit funny because most of my Hacker Lab compatriots respond to this sort of thing with a vehement “No way!” or “They don’t want me on TV…” or more responses of that nature. I suppose that lines up with the stereotypical “hacker” disposition: distrustful of authority, avoidance of the population at large, and other such behavior. Now when I say stereotypical, I mean exactly and just that. If you come down to Hacker Lab, you will find, by and large that we are respectful, welcoming, engaging, and more than willing to help. I’ve been told multiple times that the Hacker Lab building from the outside, gives off a vibe that screams, “If you don’t have business here, you should just move on…” What I’ve also been often told is that this vibe is usually quickly dismissed once you come inside. That is one of the main reasons I’ve stuck around for so long.

Going back to this “cyber expert” thing. Truthfully, that makes me a little uncomfortable. Mainly because I know actual cyber security experts and my knowledge doesn’t hold a candle to theirs. That said, I suppose I probably know a bit more about cyber security than the average person, so we’ll call that a push and move on. Anyway, as “experts”, I feel we have to work harder to interact and discuss with the community. As techies, we (stereotypically) shy away from interaction with the public at large because of social anxiety or annoyance. This creates a gap of knowledge that leads to a whole host of issues, because the people that have the information aren’t sharing it with the people that need to hear it. Of course, the people that need to hear it usually don’t want to because it’s boring and they’re otherwise not interested. I can’t tell how many times my friends/family/significant others’ eyes have glassed over when I go into full nerd mode. (At this point in my life, I try REALLY hard to tamp that down, but there are slip-ups…)

Now I could chide the listener, and I sometimes do, but I always have to turn the situation back onto myself and ask what can I do differently. Especially in academic contexts, the “rightness” or importance of what we are discussing is usually carries enough value in our minds, to make it worth someone else’s time. Often times, this sentiment is not shared by the listener, hence the glassy eyes. Again, I could blame the listener, this is important stuff, they should pay attention, and the importance should be enough. But it is often not. However, all of this information I knew before I started the conversation. So if know the mindset of my audience, know how they generally respond to this type of information, can I really be surprised at the outcome if I approach instruction from that angle? If anything I need to chide myself for expecting anything different. Should I have to chide myself and alter my message? No. Buuut, if I want to communicate with my audience, I have to start with where they are, not where I’d like them to be.

It is from this place that I try to teach. Life is all about the perspective through which you view it, and I’ve always been about dealing with the world that is, not the world I want. Your “students” usually aren’t going to come in with an appreciation for your subject matter, or at least not a proper one. In framing a message, I believe the most important thing is to frame it in a way that is relatable/digestible to your audience. You’ll have to wait a bit to drop the main idea. Got to keep them awake first.

True Fear

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.

Pacific Rim

pacific-rim-posterI saw Pacific Rim awhile ago, and loved it. Now when I say I love movies like this, it always comes with a caveat: I don’t expect too much. I have basic expectations, and as long those are filled I’m happy. With this movie, I wanted to see giant robots beating up on monsters, and I got that. (For the record, I would have liked a little more robot action, but I will take what they gave me.) Whenever I see a movie like this, it always appeals to the tech geek/engineer/nerdy little kid inside of me. One of the many cool things about the times we find ourselves living in is that the tech exists to do really amazing things in the entertainment realm. I can gripe about corporate soulessness and greediness all I want to, but at the end of the day with a flick like this just shut up and take my money. I recently read an article that detailed the “post-mortem” of Pacific Rim, and what it means for (possible?) future cinema of this type. I link to it because I think it’s a spot-on analysis of the movie, it says what I want to better than I would.

Going back to that engineer inside of me, whenever I watch a movie like Pacific Rim, I am always constantly evaluating it on its technical merits. How good does it look? How detailed does it get? Is this at least partially conceivable? To most, this might sound mentally tiring, but I enjoy it. In seeing this movie, I was blown away by the detail and sense of scale. That effect was magnified that I (generally) make my bread working in 3D mechanical design. So not only am I blown away by the final effect, but also because I have some appreciation for what it takes to create it.

Recently, the work I’ve been doing with 3D printing and related tools has really served to further illustrate how the lines blur between 3D mechanical design and 3D graphic art/design/animation. If you didn’t know, there is a lot of crossover. Autodesk, a leading company in all things 3D, produces various software that handles 2D/3D design in varying ways. There is AutoCAD, which just about everyone has heard of, and many mechanical engineers like myself know intimately. While primarily 2 dimensional, AutoCAD does have 3D capabilities that I’ve become more familiar with recently. Autodesk also makes Inventor, which is pretty good 3D design software from all reports I’ve heard. Next is Maya, widely known as go-to 3D graphic design software.

One company, three applications. Each accomplishing a different task, or rather similar tasks in different ways. I’ve been putting a decent amount of time in to learning 3D graphic design and animation software, Blender specifically. (Hey, it’s free.) The differences in the object creation workflow have been my greatest hurdle. (I thought it was all 3D, right?) However, the truth is that while the end result may be similar, the process that I go through to design-let’s say…a giant robot, is quite different from how a 3D graphic artist would approach it. And tools are built with that idea in mind. The challenge is learning to adapt to the differing methodologies. I’d like to think I’m good at it already, but this 3D creation rabbit hole is pretty deep…