I love how the author explains that in live coding, each of the programmer and the program becomes “mutually part of an open-ended and contingent process of both problem generation and problem solving.” Until now, although I had the understanding that live coding is all about showing the process, there was some pressure that the approach that will be shown ‘has to make sense’ and ‘build up’ towards something. The author’s word created a shift in my perspective that the beauty of live coding performances lies in that the process is not just about problem solving and making things better, but also about creating or running into problems and showing how the programmer deals with them through trials and errors.

Expanding on my initial thought that live coding performance still has to ‘build up’ to create something fancy, I think I limited myself to thinking that there has to be an ultimate product I should be aiming for. After reading the philosopher Paolo Virno’s saying “what characterizes the work of performing artist is that their actions have no extrinsic goal” and that “the purpose of their activity coincides entirely with its own execution.” My understanding is that yes, the performance should show progress in some way, but the focus is not necessarily about the end goal and more about making the best (or interesting) moves for that instance and seeing where the performer can go with that.