How do you fit into all of this, dear comment?

The comment, I think, is one way that helps set up places like these. It is a tool for communication, and I want to embrace this. Be it to write to myself, collaborators, or others who see the website. From what I experienced while browsing and writing comments, they can take many different shapes. I‘ll try to organize my impressions into a few aspects to better describe what I see in these different types of comments. However, I don‘t understand them as selective categories; rather, they are overlapping fields where a comment can have one or multiple aspects.

The first and most common type is the aspect of explanation. This type of comment is all about describing the code's functionality in a short, clear, and impersonal manner. From my experience, this is also what is used most by the coding community and is generally understood as a comment. When scrolling through Reddit and other forums, as well as skimming over good practice advice, this is what I see most often as the canonized comment, with many debates over what a good or a bad comment is. I imagine scenarios where code is commented on in preparation for a hand-off between developers or while trying to organize the contributions of many people more efficiently. I somewhat see Knuth‘s ideal of literate programming in this aspect, as it also focuses on explaining code. To a certain degree, it’s good practice to describe your code with comments. However, it’s something that programmers seem to do afterward and to a lesser degree than they would like to in theory.⁸³ This also explains to me why the more elaborate and work-intensive ways of commenting, like literate programming, never caught on. The way current large language models⁸⁴ comment code also falls for me in this aspect, as they can only reproduce the status quo. Acknowledging this status quo, I think it‘s good that it is now possible to make written code more understandable by including automatically generated documentation. Looking back at the history of code and computing, this way of engaging with the comment and code in general stays in the confines of the masculine-coded programming tradition. Even with an outlier like literate programming, this aspect has an underlying motive of efficiency and rationality. Code has to be commented on to streamline the working processes. I see this aspect in a continuous struggle to find a balance between writing and not writing comments to maximize efficiency and, by proxy, profit. Further automating this time-consuming process of commenting in a standardized way using large language models seems to solve this struggle in the near future.

Initially, I still had a way of thinking about comments and code that tended to label them as good and bad to a certain extent. The more I looked into the topic, the more I realized that the debate and evaluation between good and bad is not particularly helpful. It‘s so shaped by historically grown values that classification is not practical for me, as nearly everything that is important to me in comments exists in opposition to efficiency, productivity, and impersonality.

Re-examining the aspect of explanation outside the bounds of efficiency, the key function of explaining code stays the same, but the goal can change. A website can become a repository of knowledge and a learning tool for others that is more accessible and understandable than just code. In that way, I resonate with Knuth’s idea of literate programming, but more in the sense of taking the time to think and reflect about how to communicate what code does in a way that prioritizes the human reading it. I also see the opportunity for citation or referring to others to build a network of references and relations to other people and websites, embedding it into a contemporary period of web-making.

For me, the aspect of the archive represents the contextualization of present and unused code, as well as existing, unutilized, or even rejected features. So, writing about everything that is present, commented out, or not in the code anymore. Reflecting on decisions, recoding processes, documenting features that never came to be, mourning parts that no longer exist, treasuring drafts, and imagining alternative paths. I think of this aspect as a personal interpretation of version control on the website itself.

Moving beyond code itself, I want to talk more about the more personal aspects of commenting—the aspects of relation and intimacy. The aspect of relation represents comments that establish connections between me and something or someone else and position my work in larger or specific contexts that are important to me. I see them as ways to express inspiration, write about references, refer to ideas, recommend something, or share a fascination. The aspect of intimacy is all about emotions, thoughts, and opinions. Reminiscing about moments of joy, voicing struggles, hardships, and frustrations, telling an in-joke or sharing a secret, holding on to fleeting thoughts, and sharing some gossip. They are the records of day-to-day life while working on a website, little artifacts of moods—a sort of diary.

The aspect of worldbuilding represents narrative elements and storytelling. I consider this aspect, to a certain extent, as an inversion of the aspect of intimacy, as it builds a fictional character that takes the place of the person making the website. Depictions of this could be websites as entities or characters serving as the main focal point of personal interaction and relation. I imagine narratives unfolding as a website grows older, gets updated, or certain milestones are achieved. Mixing storytelling and role play with the making, maintaining, and updating a website.

Last, I want to talk about the aspect of ornamentation, which embodies the urge to decorate and organize. Even though it is not a comment, I would include the general shape of the web code in this aspect. For example, the stylistic choices made for indenting, line width, breaks or white space, and layout in general. This can also include considerations about the web code's general structure. Are different parts of code treated like chapters, or are certain parts of the CSS and JavaScript split between multiple files for specific purposes? Returning to the comment itself, I see it as a blank canvas for custom lettering, headlines, spacers, separation lines, illustrations, and many more forms of ASCII art—playing with the textual nature of code and subverting it. I see the aspect of ornamentation as an extension of the website’s design permeating through all layers of the website, as well as a graphical layer that can be used to deepen other aspects.

All of these aspects exist outside the scope of writing functional code for a website to be performed. They are bridges enabling connections to other practices, which are able to enrich the experience of creating web code and interacting with environments of web code. I see comments as ways to relate to and reflect on the code I write. With my now better understanding of the history of code, I also feel the responsibility to critically engage with this part of my craft in an ongoing way—and why not visibly in the documents and websites I create. For me, a part of this is making my code understandable and relatable to non-programmers as well. In this, I align with many aspects of Bajohr and Krajewski‘s concept of Source code Criticism from the perspective of a person who writes code. Code in itself should be something that should be primarily written with human readers in mind. In source code criticism, the focus is more on analyzing algorithms and more complex code than on the websites I make. Nevertheless, I think that the approach of contextualizing web code as it is created and placing our actions in a larger context also makes sense for websites. On the one hand, with a view to all the people who visit the website in the present; on the other hand, with a view to the future and the possibility that the website could still be available in some form in archives or databases many years from now. When I search on the WaybackMachine myself, I wish I could find something additional on many websites that would tell me more about the context and the moment in which the website exists or about the people who made it. In the research for this thesis, I could only learn more about the background by reading interviews or memoirs; I wish this had also been possible on the websites themselves.

Recently, I started watching Cory Archangel‘s Let’s Play Majerus G3. It‘s part artwork and research into the late painter Michel Majerus‘ restored laptop. Majerus used his computer in nearly all aspects of his working process as it was an extension of his studio into the digital. Archangel shares insights about Majerus‘s practice by exploring this digital working environment and explores how artists‘ use of digital tools could have shaped their work. Following this deep dive into Majerus‘ works left me wondering about artists or designers working exclusively with digital media or net art websites. Relating my own practice to this, I‘m wondering how much my laptop would say and how much is already inside the website—as I see it as a working environment supported by my code editor of choice. Using the analogy of the studio to reflect on the dual nature of object and process in websites. Here, the website as the object would be the artwork, and the website as the process would be the studio. In this sense, it feels weird to me that I am artificially cleaning my studio afterward or trying to use my studio space without leaving any traces behind. I see it as a somewhat magical property of websites that I can leave my whole studio within them. I‘m also realizing now why I think of websites in terms of spaces or a place. Using the metaphor of studio, I now start to understand why it‘s also so important to me to make these spaces nice and warm, as they are places I inhabit or inhabited. Looking at my physical desk right now, I‘m in front of my laptop, surrounded by my notes, different pens, snacks, tea, and plants, while my diffusor spreads bergamot fragrance. Of course, this also carries over into my digital working environments.

But building these personal spaces and sharing them with others somehow exudes an aura of unprofessionalism. I associate this link between personal web space and this perceived lack of professionalism with the commercialization of the web in the 2000s and the entry into the era of Web 2.0. The personal, quirky, the undesigned, and the hobbyist had to go⁸⁵ and make way for a cleaner and better-designed look. For me, this professionalism expresses itself in terms of writing web code in code that is clean, efficient, and detached from the person writing it, as it is soaked in the conventions that established themselves throughout the history of coding. There is no room for the playful, the expressive, the opinionated, the relational, the personal. I see it as a way to erase the people working on web code, as well as their spaces. It hides the diverse voices, perspectives, and histories behind a veil of professionalism, further upholding the problematic web-making values.

I think it‘s important to rethink what professionalism means and how this social code shapes what we do. It‘s not that I want to go back to yellow Comic Sans on a light green background, but I think it‘s important to reconsider where the web came from, where it will go, and what influence we have. The current values of professionalism regarding web code and the histories of code and web are deeply entangled in capitalist and patriarchal structures. As a result, I see how we tend to make the web as fundamentally in conflict with the effort and care it takes to set up these places through comments. In this sense, commenting could also be understood as a form of care within the framework of technofeminist theory. Commenting as a form of work within programming that is geared towards enabling access and participation for others—to care for those visiting and to make those who make the web more visible. I see them as an opportunity to reflect on and change how and for whom we write web code. More than just displaying the code of a website through view source, comments can make this part of a website into a more inviting space—working against the prejudice of who should have access to these spaces. Similar to feminist hackerspaces, I see the opportunity for websites to be places of learning, questioning, and sharing what it means to engage with the technologies we use.⁸⁶ In this sense, comments can create spaces of critique, rethinking, and resistance - not as a singular solution but as one of many possibilities to critically engage with the historically grown structures of our practice as web makers.