Computer science is more than the pursuit of "let's see what we can make this computer do." If that's your only goal, then you might make a fine computer geek, but a lousy computer scientist. In her blog post for Computer Science Education Week, Caroline McCullen reminds us that computer science is the "T" in STEM, and isn't an isolated pursuit, but an integral part of preparing today's students for the modern and future job market.

Back in the day, one of the required courses for all computer science majors at my alma mater (SUNY Potsdam) was Data Communications. The culminating project for that course, when I took it, was to link four PCs in a data comm network via the parallel port.

This was a very geeky project. We used soldering irons to modify cables; we implemented software layers in assembly code as well as C code, and we had to work together as a team. All of these are important skills for real world projects. But as the end result, we had a small network of four PCs linked by parallel port -- something that really had no practical use. (Remember, the parallel port was used mainly for communicating with printer devices. Your computer sends information to the printer, but those printers sent relatively little information back, aside from a BUSY or ERROR signal.)

That's not what computer science is about today. Within today's computer science departments, students work with their peers in other academic departments (and industry) to use their skills to solve problems in the domains of other disciplines. That includes math, economics, statistics, and physics -- the disciplines with obvious need for number crunching and equation solving. But it also includes the "humanities" subjects, such as English, music, and education. Just as important, the practitioners of these other disciplines learn that technology can help improve their work, and not just distract from it.

We still need the geeky projects like my data comm experience to help build the basic skills, so that as computer scientists we have that background knowledge to bring to the table. It's like how a medical student has to spend a certain amount of time with cadavers, not to become really good at working with dead people (apologies to Quincy), but to build up the knowledge needed to bring help to the living patients who can benefit from it.

That brings me to this true anecdote: A couple of weeks ago I had a phone conversation with a SAS customer who works for a major health insurance provider. He uses SAS to collect and report on data about surgical outcomes. We had a great conversation about SAS libnames, data sets, and many other geeky aspects of SAS programming. He spoke with such fluency about programming concepts that I was surprised when I later saw his credentials in his e-mail signature: he's a registered nurse.