A Brief Study of Reticence

I am archiving older pieces I have written on other sites, making this the definitive home for all my work. This is one of several I am porting over from my GameDev.Net user journal. Enjoy!

This will be the last of my entries bitching about the state of learning in the computer sciences. Frankly, this nonsense is taking up too much of my time, and I have many, many other tasks to complete. My future journals will return to contemplating the interactions of computer science with other disciplines, from psychology and behavioral sciences (usability) to human factors (ergonomics) to cinema arts (storytelling and interactive narrative).

Today I looked deep into the eye of the beast. It was a fleeting moment, but it was telling. I was sitting there in my Computer Game Programming class, cranky as all hell (the class hasn't taught me anything I didn't already know, and nothing I actually wanted to know - like more about game architecture, design and integration) when I made a comment about differences of approach between academia (our class) and industry. The professor was introducing DirectSound and DirectMusic (since he's teaching from LaMothe's Tricks of the Windows Game Programming Gurus, we're effectively talking about DirectX 6 here) and we somehow got to how it's important to learn because such low-level knowledge is in high demand in the industry.

Somehow, he invited me to comment - perhaps we were back-and-forth-ing, who knows - and I pointed out that professional game developers frequently target multiple platforms, which means delving into the arcana of a single system for relatively low return on investment was highly unlikely. Instead, the rational thing to do is to license a multiplatform audio library, with support for multiple formats. License a physics "engine", a "game engine" and slap them all together to create your "presentation layer," then build on top of that. I concluded by saying that while that was the industry approach, it was very different from our approach in class, so I didn't think our in-class progress should be projected as having any larger benefit.

And then I slipped in a comment about preferring the industry approach, but that being outside the parameters of the class. In that minute, the professor replied, "Well, perhaps you'd like to teach the course?" I quickly deflected by saying I wasn't in any way trying to usurp his authority and blaming it on general crankiness.

What I saw, however, was the dogged refusal to budge in the face of change because of unfamiliarity. We see it all the time, the hordes who said people writing games in C in the mid-80s were crazy ("Assembler!"), who then turned around and said C++ would never find a foothold in the industry in the mid-90s ("C!"), and who are now saying pretty much the same thing about managed, interpreted and other high-level languages ("C++!").

See a pattern?

The fear of change, of having to re-learn, of not knowing. This professor is a very bright young man, very personable and an all-round great guy, but in that moment he conveyed to me a reluctance to reexamine his analysis of the game industry and the consequent best approach to teaching game development at a college level.

Now I must give him the benefit of the doubt in that we were in class, half-way through the semester, and it was an inopportune time for open-ended theorizing about best approaches and the philosophy of technical instruction, so I'm not even remotely mad at him, nor does my estimation of him decline in the slightest. Rather, I simply want to articulate the following: if you fear change, you will be overwhelmed by it. Technology, and society in general, move forward at a relentless pace, and, being faceless entities, have no compunctions about leaving you behind.

Embrace change. Welcome change. Consider it another chance to get it right, to make it better, easier, more powerful, more flexible, more expressive. Live it, learn it, love it.