I want to take up two questions in regards to coding this week, both of them having to do with this idea of “pleasure” that Chung introduces in her first chapter:

1) Can I really get pleasure from something that has no obvious return value? This is the question I ended my last post with. I think it’s important to clarify that I’m thinking about “pleasure” as “fun” here. So, to restate my question more bluntly, when, if ever, does coding become fun? 2) Can we get pleasure from the “aesthetics” of code? This is something Nathaniel takes up in his coding blog post this week, claiming “there is an elegance in good code that isn’t radically different form the elegance of a good song, or poem.” While I don’t know if I would go this far, I do want to address a sort of “elegance” that I also think is there.

In my first question, I say coding has no obvious return value. Now, coding has return values. If I know all of the “instructions” and I “execute” properly, something should happen. But more often than not, this is a process of trial and error. I type something into Atom and I actually have no idea what will happen. So where’s the fun in this? In the Chung, Torvalds claim that “what makes programming so engaging is that, while you can make the computer do what you want, you have to figure out how” (49). In other words, the “engagement” comes from the process and not the product. In literature, we would call this something like the journey being more important than the destination. But I’m not sure this process/journey/whatever is actually what is fun. I can’t help but feel like any “pleasure” is sustained by the (perhaps neoliberal) promise of an end result. But Chung claims there’s something about the unknowability of the end result that can be “enabling.” I know that “enabling” is not the same thing as fun/pleasure; anxiety, for example, can also be enabling. But in practice, I have yet to find that sense of empowerment in not knowing, a sense of “enablement” that can (maybe) make coding pleasurable.

Do I get pleasure from the “aesthetics” of good code? Recently, when I’ve submitted my dailies, I’ve tried to “clean up” the code. I’ve erased an unnecessary pseudocode, I’ve tried to implement the proper line breaks, etc. But I want to bring back the neoliberal concept of “return value” here. Am I doing this because I find “elegant” code more appealing? Or am I doing this because I want Scott to be happy with my daily? I’d like to think it’s the first, but once again, I can’t be entirely sure. There is something in Chung that resonates well here: “regardless of whether or not it can execute, code can be – must be – worked into something meaningful. Source code, in other words, may be the source of things other than the machine execution it is ‘supposed’ to engender” (52). The code is not just for the computer; we want to make the code look good for us. Now, is there something about the “aesthetic” here that goes beyond clarity or readability? Do we want to make the code “look good” because we admire the elegance of, to use Nathaniel’s example, a good song or a good poem? Or is there a certain elegance in simply being functional?