image of a wrench A Few Thoughts on (Web) Programming

August 19th, 2010

Why I Set Out to Learn

Decades ago, the wonderful media sociologist, Jeremy Tunstall said of his field that “the recurrent weakness of so much ‘academic’ discussion of the news media is a preference for over-sophisticated explanations in general and conspiracy theories in particular.” His wise words sum up the rationale behind what’s become, for me, a life-long commitment to hands-on media literacy.

Nothing keeps a researcher honest like real-world experience. I began my academic life as a film-studies scholar, and the one time I helped carry a 420-lb. camera dolly over trails into the recesses of the Los Angeles Arboretum spared me a lifetime of philosophizing about the hidden intentions of cinematographers who use handheld cameras while shooting in the woods. (This is, of course, a story about revising my own preconceptions, not a general comment on film studies scholars, some of whom have been among my wisest and most dedicated mentors.)

Working with the technologies I study in this way was what first raised, for me, questions that are now essential to my work, such as issues of material agency—how the structures we work within and the tools we use place limits on our ambitions; the social construction of technology—how the tasks our tools make simple or difficult, obvious or complex, are an outcome of a social and value-laden design process; and the politics of artifacts—how power relations determine whose values get embodied in our tools.

Today, I study the Internet. And in the four-plus years I’ve spent at Cornell, I’ve invested a considerable amount of my time learning to program for the Web. I figure that, just as the academic who studies film is better off when they know what goes into rigging lights and working a camera, and the person who researches journalism is sharper when they know what it’s like to work inside a news room, if I was going to study Web development from a sociological perspective, it could only help if I knew how to program basic three-tier Web applications and teach the skills involved. Here are a few reflections on the experience for other folks considering the same route.

Was it Worth It?

I do feel as though I’ve accomplished my primary goal of grounding my research. I have research conversations with Web developers that I never could have had just a few years ago. And I see sociologically interesting questions in exchanges and tech news that wouldn’t have even entirely made sense to me before I set out to learn these things. Certainly, not everyone who studies new media needs to learn programming—there are plenty of amazing lines of research that don’t consider code at all, nor should they. But there’s more to the question of “worth” than that...

Guido van Rossum said it most simply: “computer programming for everybody.” Reflecting on the cost-benefit ratio of learning to program, I believe there are good reasons for everyone to learn one or more basic scripting languages of the sort that make up the backbone of Web development.

Why? Well, first off, because everyone can learn without too much trouble. The basics of programming in a modern language like PHP or Python aren’t terribly difficult. Good design can be hard to achieve. Debugging your piece of software can be frustrating, yes. And building applications that scale well as they grow in popularity and sophistication is probably a challenge for the few who are lucky enough to have such a problem. But I’ve come away from my experiences thus far with the notion that learning a bit of programming is something everyone could benefit from. It’s a matter of self-empowerment.

You or I may never design a viral Website or write the software app that kills Adobe Photoshop. But it takes very little experience to come up with a PHP or Python script that, say, reorganizes your address book, fixes a small bug in your WordPress theme, or scrapes data from a Webpage and compiles it into a spreadsheet you can open in Excel, OpenOffice, or your favorite stats program. These are the sorts of things that you might otherwise have to wait an eternity for, hoping someone finally wrote the software application for your über-specific problem.

In short, scripting languages are great for more than just building Websites. I’m primarily a qualitative researcher, and I still use scripting regularly to collect data from the Web or visualize problems I’m working on. You can take a look at my notes from the WikiCandidate Project to see more about how this is useful, even—and perhaps especially—for small data sets you've already read “cover to cover.”

But What About Building Websites?

And yes, I have views on building Websites, too. There are people who know far more than I about these things, but here are a few of the principles that have become important to me for those who care to think about these things. I don’t claim to abide by all of these perfectly, but they’re what I aspire to. I also welcome feedback, as there’s always more I can learn.


With programs in information science and human-computer interaction, folks at Cornell put a premium on interface design. And I’ve learned to do so, too. I always try to imagine the two or three typical users who’ll be visiting a site, and the three or four things they’ll be looking for. I try to make those the easiest things to find. When something unexpected becomes popular, I make it more prominent as well.


These days, it’s hard to know what sort of browser or device people will be using to access a site. That’s why I try to test my Websites in all the major browsers—Firefox, Internet Explorer, Safari, Opera, and Chrome—to make sure they work predictably in each. I also load them in Windows, OS X, and Linux to make sure they look roughly the same on each system. Last, but not least, I practice graceful degredation, meaning that users can turn off Javascript and other bells and whistles in their Web browser (or use a device without these affordances) and still access the content and features on my site.

These days, graceful degredation is an interesting problem. For instance, a touchscreen device like an iPad is Javascript-enabled, but doesn’t recognize CSS’s “hover” property, which used to be preferred for graceful degredation of things like mouseover-menus. Nor do Apple’s touchscreen devices support Flash, a former darling of media companies, favoring instead open standards like HTML5 and the H.264 video compression (which isn’t Flash, but isn’t entirely open either).


If part of what’s great about learning to program is the fact that you can solve your own problems, this “do it yourself” ethos would be impossible without open standards and open-source software. The standards that make Webpages renderable, and make things like email and RSS feeds work, are free for everyone to see and implement. PHP is free. Python is free. Database technologies like MySQL and SQLite are free. Impressive Javascript libraries like jQuery and Prototype are free. They’re not only free to use, but they’re free to tinker with, and all the resulting tinkering people have done is what makes them so usable, reliable, and wonderful. In short, all the things that make Web programming simple and available are wrapped up in this “freeness” and “openness.” I try to make use of open standards and code libraries wherever possible, and to make my own writing and code freely available whenever I can.

By the way, the ability to get ahold of stuff for no charge, to take it apart and see how it works—all that is great for learning and teaching, too. It’s possible to train students on widely accepted, state-of-the art tools for which they and their institutions will never have to pay. That seems more logical to me than making students pay for expensive licenses if they want a personal copy of the course software, or sending them out into the world with skills they can only implement and update with access to the same expensive equipment and tools. This isn’t to slight proprietary standards like Flash, which are widely used and essential to learn. It is, however, to say that those systems are only one part of a well-rounded and self-sustaining new media education.


This is simple in principle, but complicated in practice. Interactivity is imporant to any Web application, but interactivity can also mean security risks. When you’re dealing with a public environment like the Web, there are more and less secure ways to receive and store people’s information. For those who care about how I handle their data, I validate user-input carefully and use prepared statements whenever sending user queries to a database to prevent SQL-injection attacks. I also use database transactions for the sorts of database exchanges where the “acid model” is important. I use POST, rather than GET variables when processing sensitive form data, so no essential information becomes visible in the form of an exposed URL. When I take password information from users, I salt and encrypt their passwords using a current encryption algorithm so that even if someone improperly accesses the database, passwords aren’t exposed. And I re-encrypt password information with updated algorithms as older ones become less secure. Lastly, I’m always open to suggestions as to how to improve the security of my sites.


I validate all my Webpages against W3 standards, which not only ensures they will be more secure, reliable, and extensible, but also improves accessibility by ensuring that pages will work with assistive devices for visually- and hearing-impaired users.

Compassionate Use of Public Resources

This I learned from Dan Cosley, a computer scientist turned star social science scholar. In the age of RSS feeds, embeddable video, AJAX, and APIs, many times when you set out to program something, you’ll be using someone else’s resources. Local caching of frequently used resources, smart coding, and a bit of inquisitiveness about the code libraries you’re using (i.e., do they suck other people’s bandwidth) can go a long way toward making sure your nifty new program doesn’t get your Web host blacklisted or become the bane of some poor server administator’s existence.

The Right Tools for the Job

It pays to know neat Javascript libraries like jQuery, but not every Website needs them, and loading your pages down with a “heavy” client-side code library will only make your pages run slower and your users less appreciative. The same goes for AJAX and other tools and methods that are invaluable much of the time, but can simply be baggage at others. Evaluating whether or not you need a particular technology for a given project is an important part of keeping things simple, which in turn improves all the other aspects of good development.

Modularity and reusability of code are also important. A good development project should always add synergy to your set of resources. I’m as guilty as the next person when it comes to having written a lot of single-use pieces of code. But ideally, nearly every piece of code you write could become a reference you use to refresh your skills down the line, or better yet something you could plop into a new program in the future, making your life a lot simpler and letting you focus on extending other skills and completing more pressing tasks. Even within a single program, as a professor of mine said, if you find yourself writing the same thing over and over, look for the more efficient way to do things. This also helps when it comes time to update or alter your code. If you’ve avoided writing nine instances of the same code, you’ll only have to change it once.

Learning for Life

The last, and most important point should really be my conclusion. All these things move very fast. David Williamson, one of my professors, is fond of saying that three years is about the length of time it takes for a nascent Web technology either to become irrelevant, or to become so essential to the way developers do things that it’s hard to remember how stuff worked before.

That means different things to different people, though. If you plan on using your knowledge for simple tasks, like writing one-time scripts to reformat an old data set, or reorganize your recipes, you probably don’t need to worry about keeping up. But if you plan on working with Websites regularly or teaching Web development, it’s probably important to update your skills regularly. As I write this, I’m learning HTML5. Three years from now, who knows what I’ll need to know to keep up?

blog comments powered by Disqus