I met with Ian Bogost last week, author of Persuasive Games: The Expressive Power of Videogames . He told me about a new book that he's writing on the Atari videogame console system. He said that the hardware on the Atari VCS could do some amazing and idiosyncratic things---this bit in this register would cause this display trick (maybe splitting the screen horizontally), and that bit in that register would do that effect. Game designers used these special capabilities, and then their games became popular. Today's games replicate some of those same effects---not because today's technology is similar, but because those games established genres. The creative use of the specialized hardware in the Atari VCS led to styles and genres that continue today when the hardware is radically different.
Ian asked me where we teach that kind of creative bit-twiddling in undergraduate CS today. Where do students learn to take advantage of particular features of particular machines to do amazing things? I said that we don't. Even our low-level computer organization course use simulated, pretend processors (a) to simplify the class and (b) to make sure that students learn the general lessons, not the specifics of any processor. Across our curriculum, we teach platform-independent tools (like Java) so that students create portable, maintainable programs that can be understood without knowledge of any specific platform. We lead students to being able to create well-engineered code, not necessarily particularly interesting code.
Yesterday, I gave a talk to our new cohort of Computational Media undergraduates about the CS classes that they will be taking. One student asked me about 3-D modeling, and I told him about our computer graphics classes. Then a young lady asked me a question that bowled me over, "If we don't take computer graphics and we get a Computational Media degree, is all that we can do is become programmers?" The last word just dripped with disdain, as if that was a mid-level in Dante's vision of hell. I told her about Frank Dellaert and Bruce Walker's work with SWAN, a system that turns spatial information into sound information for blind people; and about Gil Weinberg's Haile, a robot drummer who listens to you and riffs with a group of players; and about Thad Starner's work in mobile and ubiquitous computing. Those are Computational Media projects, too. The students were excited about pushing beyond computer graphics towards other modalities of computational expression.
What I kept thinking about was this student's fear of programming. I think that there is a connection between these two stories.
Colin Potts, a professor here at Georgia Tech who works in software engineering, has said that the goal of much of software engineering ("mostly SEI-inspired") is to remove all the fun out of programming. When I mention that quote to other software engineering researchers, they often agree with it. The goal of software engineering is for the creativity to appear in the design, and the actual programming should be akin to construction---a simple activity of putting together the pieces.
It seems to me that the cause of the student's disdain for "programming" and for the decline in CS enrollment lies there. As civil engineers need armies of construction workers to build their designs, and as mechanical engineers use armies of factory workers to produce their designs, so do software engineers use armies of programmers or coders, people who are explicitly not software engineers, to produce their designs. Few students go to college to become construction or factory workers. Why should it be surprising, then, that few Western students want to go to college to be the Information Age equivalent workers?
Education historians and theorists have argued that the current US educational system was designed to produce factory workers. They say that we need to revise our system to produce knowledge workers for the future. I propose that our current undergraduate computer science programs are designed to produce coders for software engineers. We spend our time, especially in the early classes, focusing on coding standards and writing good, clean code. Rarely, and certainly not until the upper division courses, do we emphasize creativity and novel problem-solving techniques. That meshes with good engineering practice. That does not necessarily mesh with good science practice.
Computer scientists do not need to write good, clean code. Science is about critical and creative thinking. Have you ever read the actual source code for great programs like Sketchpad, or Eliza, or Smalltalk, or APL 360? The code that I have seen produced by computational scientists and engineers tends to be short, without comments, and is hard to read. In general, code that is about great ideas is not typically neat and clean. Instead, the code for the great programs and for solving scientific problems is brilliant. Coders for software engineers need to write factory-quality software. Brilliant code can be factory-quality. It does not have to be though. Those are independent factors.
I suggest that we will attract more students emphasizing brilliance than factory work. Our students want to be creative, not mundane. Many want to push hardware to do things that no one has ever thought about. Many want to explore new forms of expression. That is what computer science is about. That is not necessarily what software engineers need.
|
|
Bio
I started teaching computing in February 1980. I was 17 in my senior year of high school, and I taught "Bits, Bytes, and Basic" in a community education class. I taught through my undergrad years--community education, afterschool classes, GED classes, and even community college in 1984. I read "Personal Dynamic Media" by Adele Goldberg and Alan Kay while on an internship at Bell Labs in 1982. I'd never before thought about computing FOR learning (as opposed to learning ABOUT computing). Adele and Alan's thoughts and words set me on the road to my PhD in Education and Computer Science at the University of Michigan in 1993. Nowadays, I focus on using lessons from learning sciences and educational technology for teaching about computing.
|