Coding != Computer Science

Listening to David Heinemeier Hansson deliver the RailsConf keynote a little over two months ago was, for me, a minor revelation. It was exam season in my final semester of university and I had several philosophy finals bearing down on me. As I began organizing my notes, I came across a link on Twitter and fired up the conference livestream. What began as white noise in the background quickly piqued my interest. Soon enough, I found myself glued to the screen.

Growing up in Copenhagen, DHH loved tinkering with computers and tried to learn programming on three separate occasions. In retrospect, he says, his early, uninspiring attempts at writing software had one important thing in common: each time he had tried and failed, Hansson had encountered programming in the context of computer science. As a gamer and aspiring video game developer, some of his first attempts at programming were in the esoteric language AMOS Basic. There was plenty of math and physics involved and Hansson has the report cards to prove his lack of scientific aptitude. He was an F student in math and physics, but an A student in English.

Years passed. Closer to the age of 20, Hansson finally learned to program. Three years later, he invented Ruby on Rails, the open source web application framework I'm learning here at Bitmaker Labs nearly ten years later. If your understanding of programming is based largely on the way it's depicted in popular culture, you may be wondering: how could that possibly be?

Stories like Hansson's are inconvenient exceptions to many of the storied myths of programming. From the outside looking in, many believe that what software engineers do is, in reality, a hard science akin to Linus Torvalds' development of the Linux kernel, and that in order to be a proficient programmer it's best to start parsing Ruby docs in pre-K. Worse still, many programmers wish that were the case (Hansson calls this hitting them in their "impostor plexus"). In reality, Hansson says, writing software is less like engineering and more like studying 17th century French poetry: when reading other people's programs, most of his time is spent wondering "what the f--k did this guy mean?"

Point taken—and now that I've waded through other people's code, I can fully attest to this. The analogy elicits a few chuckles from the audience, but it also succeeds in getting the message across. In DHH's view, writing software boils down to precisely that: writing. He uses this notion of computer science as a liberal art (a kind of cognitive re-framing of the discipline popularized by Steve Jobs) to further argue that, while there will always be a place for unit testing and optimization, prioritizing metrics ahead of system architecture is fundamentally wrongheaded because it sacrifices sound system design on the altar of objective science.

As a web developer-in-training, I prefer to view the issue of testing and TDD with a bit more nuance (this is a great piece if you're interested in the other side of the story), but hearing DHH challenge the computer science paradigm was a much-needed reminder that, despite a lack of formal computer science education, programming is still very much "for me." This may seem like a trite realization, but as someone who loved studying the humanities in university while maintaining a strong interest in software development, it was a relief to hear that the two aren't mutually exclusive. In fact, they may be more directly related than previously imagined.

I'll be writing more about my experience at Bitmaker Labs in the weeks to come; feel free to get in touch if you have any questions. You should follow me on twitter at @alessbell.