As I create new course materials for my students this semester, I realize that when I aim to teach computer graphics, I am also aiming to teach other things as well.
Primary among those other things is showing them how to connect the levels of engagement, from the most technical to the most conceptual.
There are people who self-identify as consumers, others as artists or designers, still others as technical artists, and so on, all the way to people who will tell you “I build the circuits that go into your computers”. Between these levels, there tend to be cultural barriers.
Even the language used by different people can make it more difficult to communicate across levels. If you’ve ever tried to talk to a doctor about a medical condition, you might know exactly what I mean.
So I realize that one of the things I try to do is to show students how to transcend those barriers, by making it easy to connect the dots and build working bridges from “artist” or “designer” to “graphics programmer” to “systems programmer”. I want to empower them to move freely between those levels, and to create connections between different ways of thinking that empower all sorts of users and creators.
That isn’t easy to do, but I think it’s worth it.
I hope you write more about this. I’m interested in specific things that can be done to bridge these levels.
I assume that connecting terminology used at different levels is part of it. For example, “warmer” and “cooler,” when applied to light sources, have nearly the opposite meaning to a physicist than they do to an artist. But I imagine there’s more to bridging this gap then pointing out the differences in terminology. Perhaps it means exploring the perspectives each type of specialist works from?
Early in my career as a software developer, I studied computer hardware design extensively, at one point taking a lab course series constructing a computer system from scratch. I can’t say I use the knowledge on a daily basis, but it’s always given me an appreciation – and reality check – on what goes on under the hood.
Since then, I’ve noticed the best system software architects often start with the raw specs of the hardware they’re targeting; identifying bus speeds, memory bandwidth, throughput limits, etc. This gives them a realistic limit of what’s possible, and what performance targets to aim for.