Readings in prep for week 3

I know you've already been reading and watching in preparation for week 2, but there is just a bit more I'd like to put out there before our next full-class discussion. Please read the introductory chapter of Nick Montfort's Exploratory Programming for the Arts and Humanities, 2nd edition, as well as Paul Ford's What is Code? – but note that the latter is longer than it seems. For now, I'm only asking you to read section 1 ("The Man in the Taupe Blazer") and then jump to section 6.5 ("And Now for Something Beautiful").

When you've finished reading, please use this forum to propose ideas you'd like to discuss further, ideally grounded in particular passages where possible. For example, you might...

Highlight new ideas or key terms, especially those that you expect will be useful in thinking about digital projects.
Highlight sentences, passages, or methods that struck you as especially well done, perhaps worth imitating.
Link outward to something a passage reminds you of, explaining where you're leading us.
Pose questions to your classmates about a passage, especially (but not exclusively) if something is confusing.
Respond to any of the above.

NB: While I say "grounded in a text," you should also include your own questions, confusions, connections, excitements, or incitements. If you aim to write at least 100 of your own words, that should give us a place to begin.

Direct responses to other students’ posts are optional but encouraged; to make that more possible, please try to post by Friday evening when you can.

Montfort states in section 1.10 of his introduction to "Exploratory Programming" that programming isn’t just putting images and texts to a webpage. He states that “Figuring out some simple statistics of different photographs, represented as JPEG files” is what he would count as “a tractable and computational” project. This note brings me back to “Memories/Motifs”, one of the digital humanity’s projects we looked at through Posner’s video last week. I feel like at first glance it seems to be a combination of texts and images, a product that Montfort doesn’t deem as challenging and worthwhile as something that requires seemingly more programming. But, when you start interacting with the site, you notice the moving images as well as the different forms of media embedded (?) in the various web pages, like videos and music. I suppose in comparison to the “simple statistics” Montfort talks about, the ways in which Rachel Deblinger divided the content of "Memories/Motifs" into different themes would be akin to what he’s talking about. My point in saying all of this is a reminder to myself (someone who has absolutely no experience in programming) and to the rest of the class, not to stress about creating a unique, never-before-conceived project. I think what Montfort is saying, and what Dr. Miller expects of us, is to get a grasp of what the digital humanities is through a hands-on project that will hopefully end with a tangible product that illustrates our own exploration of programming and the melding of our own interests in the humanities with the digital tools we will be introduced to through this course.

Montfort allows us to perceive the distinct ways in which text, sound and image interact with each other through structures of programming. As a literature student in the past, I often missed out on the investigation of visual and auditory cues, thus leading to a limited understanding of the issue at hand. Therefore, when one takes programming as not just a technical exercise but a tool of excavation and brainstorming, it allows both the probing of data for new systems of thought as well as the emergence of myriad artworks that have social and cultural relevance. This paves way for newer modes to think about sources, processing and presentation of lived realities, ideas that we discussed in our first lecture.

When one reads Paul Ford, they become acquainted with the implementation of above ideas via coding and the challenges it might bring. Section 6.5 titled, “And Now for Something Beautiful,” elaborates our discussion from the previous lecture about coding as a collaborative exercise and the accommodating potential of a platform like GitHub which brings together diverse streams of thought and is a fertile space to fuel discussions (what we are also trying to do here). However, the interesting point to think further is how the choice of a programming language remains a highly contentious subject.

In addition to this, one of the questions that looms large while reading both the texts is that of the intended reader. Whereas it is evident that Paul Ford’s essay is geared towards businesswomen and men, it will take a few more chapters in Montfort’s book to discover his frame of reference and then discuss further about coding and culture.

Reading Montfort and Ford in tandem made me think about how people interact with tools, and specifically what kind of tools we think of like levers and pulleys and which ones we think of like magic. On pg 6 of Exploratory Programming Montfort notes that no other skills-based instruction books have the convention of offering a justification for their study. But coding instruction has that convention because people find it intimidating and may assume that they can't understand it. Ford's piece actually addresses a similar dynamic. It's a very long article in a publication focusing on business issues, which is a genre that traditionally centers brevity. In many ways, I think of computers and coding like a kind of magic, and I think lots of other people do too. But both Montfort and Ford's pieces emphasize that coding, like anything else, is a practice made up of a million tiny iterations. But because digital tools move so quickly and can do such incredible things, they look like magic. (Insert the overused Arthur C. Clarke quote here...) But demystifying programming is important for understanding how almost everything works in the world. I'm hoping working with GitHub will help me understand a bit better. (I loved Ford's description of version control as a "combination newsfeed and backup system.") But we'll see how that goes over the rest of the semester!

Montfort and Ford mention that computing and technology have been essential touchstones for humanity and the sciences for a while. Montfort asserts that computation is a part of culture. Moreover, both emphasize that computing will be more effective in addressing various aspects of human existence.

"Exploratory Programming for the Arts and Humanities" provides basic information on computers and programming for scholars studying arts and humanities, even for those without any background in computers, code, or programming. While I initially found this topic quite complicated, the author suggests that it is easy to grasp with this book. It is also noted that there are creative and exploratory ways of thinking to address questions related to the arts, culture, and more. Both especially stressed collaboration to explore and create a project, which I think is the most vital component of working on a project.

I particularly appreciate the quote by Anette Vee: "Unless you can think about the ways computers can solve problems, you can't even know how to ask the questions that need to be answered." This quote has made me ponder whether I truly understand how to formulate questions and what computers are capable of doing.

Furthermore, there is another anecdote in Montfort's book about thinking artistically and humanistically with computation. Does this imply that we can also create art or produce humanistic content using computers? What about concepts like aura, spirit, authenticity, and uniqueness?

I’ll start with Monfort because for some reason I became more and more frustrated as I read the introduction. Aside from his tone which was somehow both quirky and pretentious (not important here), I think in part, the frustration came from the distinction made in 1.2 between exploratory and exploitation. I do understand that he was trying to explain why understanding some degree of programming is important if you’re trying to use it as a tool for inquiry. Essentially, you need to at least be willing to learn how to take inventory of what’s under the hood before you go for a drive and start dreaming of more horsepower and less emissions. Fine. In fact, it makes a lot of sense, and I’m quite excited to use creative computing and code as inquiry to figure out which questions I should be asking in my own work.

I’m left wondering other ways to think about exploitation in computing/projects. With the grocery store metaphor, it seems like if we think about the basket as a database, the shopper as the person choosing which code to write, the items on the shelves as the code, and the final transaction is the programmer uploading their code to the database, I’m not sure either options sound that bad in the way he posed them (which is maybe my problem). If you’re going to the store to buy something from a list you use regularly, who is to say that you don’t find something interesting sitting on the next shelf and add that to your basket? Then you go home and pair that with your regular ingredients to create something wonderful; or at least new. This is kind of like a scholar who is an expert in an area that finds ways into other spaces through their home discipline. It seems more inevitable than not.

The exploration example-always buying something new and never repeating a purchase, would just add more to the database and someone would eventually do something with that. Sort of like an ever-expanding network.

I see the importance of being aware of your methods and being able to balance exploitation and exploration, but I’d like to see what this looks like in practice. I’m imaging reading a methods article that details the project, why it’s successful, but also, what may have happened if they ran it in an unbalanced way. Perhaps one that overuses exploration or exploitation.

On another note: the Ford piece was wonderful, and I’d like to read it in entirety if I have some spare time this week. I had some flashbacks to a time when I worked in an office with extremely outdated case management software and outdated marketing practices. One of the younger attorneys made a case to upgrade these systems and it truly was a never-ending process for a lot of reasons. They ending up outsourcing the work to a startup company with no previous stake in the legal sector, so there was a great deal of translational work that needed to happen regarding use factors and efficiency. It seemed like they understood what they were building but not how to make it work, for us as attorneys, paralegals, investigators. As office staff. Every week they were trying to create, revise, debug, and update. As I’m typing this, I wonder if that would be an example of being unbalanced and exploited by their own existing knowledge. It seemed that because the partner attorney didn’t understand a lick of how to even turn on a computer, he outsourced to a tech company who didn’t understand what was under the hood of a law firm, operationally. This disconnect prevented any use of creative inquiry to reach a solution that could’ve been a more functional case management system for its users. The price of conducting drunken business deals I guess?

benmiller314 / dsam2023fall

Readings in prep for week 3 #4