As the job market is getting even less welcoming, and digital skills are at the forefront of national discourse, digital literacy objectives are being integrated into student learning goals across disciplines. But there are still a lot of questions to answer: what skills are essential? Do students in all majors benefit from learning to program?
Stephen Ramsay started a debate when he argued that to be part of the digital humanities, at least in his program, you had to learn code. At ProfHacker, we talk a lot about possibilities for digital projects—which may or may not involve working with code. Many of these echo the desire Brian Croxall described to teach kids (of all ages!) to “make.” We’ve also addressed coding itself: Ryan offered pointers for learning Ruby, and Jason suggested Codecademy for getting started with code-literacy.
I teach many courses labeled as computer science, yet many of my students don’t identify as “technical.” As the students are interested in game design, some are more motivated to pursue art, or writing, or design and concept work—but they all have to learn some programming. When they ask why, I have the standard industry answer ready: despite their own specialties, they’ll be on teams with programmers, and they need to understand what programming can do and how to frame their projects and discourse.
But is there a further value to learning programming that translates across disciplines? I recently finished reading Douglass Rushkoff’s Program or Be Programmed: Ten Commands for a Digital Age. Rushkoff argues that knowledge of coding is essential: “Understanding programming—either as a real programmer or even, as I’m suggesting, as more of a critical thinker—is the only way to truly know what’s going on in a digital environment, and to make willful choices about the roles we play” (8).
The learning that goes on in the traditional classroom may teach digital literacy, but does it teach an understanding of code? Rushkoff claims that for students taught to use programs rather than to create them, “their bigger problem is that their entire orientation to computing will be from the perspective of users. When a kid is taught software as a subject, she’ll tend to think of it like any other thing she has to learn. Success means learning to behave in the way the program needs her to. Digital technology becomes the immutable thing, while the student is the moving part, conforming to the needs of the program in order to get a good grade on the test” (136). This echoes some of the same patterns I’ve seen in my classroom: a student who is only familiar with what others’ programs can do, and used to working within those systems, might never consider a solution outside those boxes.
Douglass Rushkoff’s Program or Be Programmed might not convince you to dive headfirst into C#, but it is a solid foundation for starting conversations on the value of technical skills for yourself, your institution, and its students in any discipline. Some of the arguments are dubious, but the book offers succinct and clear discussions of lessons gleaned from longer works such as Sherry Turkle’s Alone Together and Jaron Lanier’s You Are Not a Gadget, other essential texts considering these same ramifications of our relationship with new technologies.
Do you program, or teach programming in your classroom—regardless of your discipline? Do you feel it changes your relationship to your technology? Let us know in the comments!