Abstract
In this article, we analyze the productive role of aesthetics in organizing technoscientific work. Specifically, we investigate how aesthetic judgments form and inform code-writing practices at a large web services company in Russia. We focus on how programmers express aesthetic judgments about code and software design in everyday practice and explore how language with positive and negative valences is deployed. We find that programmers label code as “beautiful” without defining or establishing agreement about the term and are thereby able to maintain different ideals of beauty within the same organization. However, by learning how to avoid what senior developers deem to be “ugly” code, developers become socialized into producing code with a similar style and logic that we describe as “not ugly.” The fieldwork suggests that aesthetic language can function simultaneously as a mechanism that supports professional diversity within an organization and as a tool for producing consistencies in software design. Studying manifestations of both positive and negative aesthetic language in technoscientific work provides insight into professional practices and the various roles aesthetic language can play in organizational life.
Introduction
What is beauty for computer scientists and software engineers? How can considerations of ugliness shape programming practices? What does it mean to write code that is not deemed beautiful but is “at least not ugly”? In this article, we explore how aesthetic judgments about source code shape and structure software development. We investigate the organizational role of everyday debates about the beauty and ugliness of code through an analysis of our qualitative fieldwork in Russia’s search engine company, Yandex. Specifically, our research reveals how the aesthetic language of beauty and ugliness played a central role in how Yandex software developers communicated professional values to one another and aligned coding practices.
Three key observations came from our study. First, no single aesthetic ideal of “beautiful” code existed at Yandex. Developers within the company held different ideas of how beauty is manifested in code and did not attempt to establish a common definition of beauty. By maintaining ambiguity around what constitutes beautiful code, programmers were able to maintain allegiances to their different backgrounds and training. Second, while there was no single conception of beauty, developers held a shared understanding of the multiple forms of ugliness. Examples of “ugly” code were regularly identified, pointed to, and called out by members of the company’s developer community. Finally, through organizational processes centered on avoiding ugliness, developers became socialized into norms and coding practices that produced locally acceptable code that mimicked the existing codebase. Engaging in abstract debates about the ideals of beautiful code while criticizing and censoring specific examples of ugly code was how Yandex-specific coding practices were taught and modeled to newcomers.
By documenting how beauty and ugliness were used to preserve diversity while promoting alignment, we explore the role that aesthetic language can play in organizing technoscientific work. Specifically, we suggest that the language of aesthetics can variously operate as a mechanism of professional signaling, social control, and organizational alignment. Using aesthetic language as an analytical lens to study software development practices offers resources for thinking about programming not as universal and standardized but as discussable.
Aesthetic Considerations in Technoscientific Practice
In the emerging fields of Critical Algorithm Studies and Critical Data Studies, scholars systematically study and tackle algorithms’ legal, ethical, and social challenges (e.g., Gillespie 2014; Introna 2016; Noble 2018). More importantly, this body of work suggests that algorithms are always constituted by power relations, cultural norms, organizational values, and people who shape how these algorithmic systems operate (Seaver 2017; Ames, 2018). However, research in these fields has not directly attended to the practices of writing the code that underpins these algorithms. Meanwhile, science and technology studies (STS) has taken a keen interest in code as an object of inquiry, with researchers starting to investigate its boundaries and the significance of its materiality for software work (Couture 2019; Cohn 2021).
In line with this STS research, Critical Code Studies considers code as a central unit of analysis and explores its multifaceted nature, including the aesthetic dimensions of computation, by applying critical theory to code (see Fuller 2008; Marino 2020; Soon and Cox, 2021). This research argues for a holistic approach, looking beyond the technical and functional aspects of code to examine the broader contexts that shape our encounters with software objects. Mateas and Montfort (2005), for example, delve into the aesthetics of code, extending their analysis beyond traditional valences like “elegance” 1 to broaden the field’s understanding of the range of values placed on code.
In contrast to Mateas and Montfort, discussions on aesthetics within Critical Code Studies are generally characterized by a focus on code as art, regarding code practice as a mode of creative and critical inquiry (Fishwick 2006; Cox and McLean 2012; Sack 2019). While recognizing the importance of studying code in its multiplicity, including its materiality and aesthetic dimension, we aim to extend this discussion beyond artistic practices. Our goal here is to explore how situated aesthetic assessments of code operate in the domain of software engineering and, in particular, how they are put to work to achieve collective ends.
For this reason, we draw inspiration from another discussion in STS and anthropology concerning code, in which authors examine code as social, discursive, and organizational practices that can serve to structure communities (e.g., Mackenzie 2006; Kelty 2008; Coleman 2012). While this discussion is situated mainly within the context of open-source code, it suggests that the ways in which people relate to code can serve as an organizing function similar to what we observe in our examination of coding practices within an industry context. By bringing together work that highlights code as a material object with aesthetic dimensions, and literature that treats code as an organizing force, we lay the groundwork for our study on how aesthetic designations of code can shape organizational and professional practices in technoscientific work.
To elucidate this dynamic, we build on the legacy of STS-related ethnographic research on technoscientific occupations and workplaces. Traweek’s (1992) classic analysis of the occupational culture and work practices of High Energy physicists in the United States and Japan sheds light on how professionals are disciplined into becoming “good” physicists. In a similar vein, Goodwin’s (1994) influential work on “professional vision” explores how scientists and other professional groups learn to “see” the outputs of their instruments in relation to their inquiry objects. Goodwin provides a comprehensive account of how individuals learn to become “proper” practitioners by developing shared ways of seeing, understanding, and engaging with material artifacts within a community of practice (see also Goodwin and Goodwin 1996; Law and Lynch 1988). Goodwin highlights that learning to see and read abstract knowledge, as mediated through tools, is fundamental to professional socialization.
Traweek’s (1995) later work is distinctive in its attention to aesthetic designations as part of this process. Specifically, she describes High Energy physicists’ elaborate aesthetic discourse, which is used in the production of knowledge: “the erotics of taxonomies, the satisfactions in controlling grids of difference, and the aesthetic pleasures of sameness are fetishized in totemic machines, the only place where theories can become facts” (Traweek 1995, 4). The intertwined role of aesthetic judgments in technoscientific practice is also addressed in Lynch and Edgerton’s (1987) investigation into astronomers’ image manipulation. They reveal that astronomers rely on different aesthetic criteria when preparing visual data for different contexts, creating colorful “pretty pictures” for popular science magazines, and black-and-white “scientific images” for journal publications. In a similar vein, Daston and Galison’s (2007) work on the role of objectivity in the production of scientific atlases from the eighteenth century onward emphasizes that aesthetic considerations often accompanied and productively reinforced the search for scientific accuracy.
These studies, therefore, suggest that aesthetic considerations have always been a part of technoscientific practice, and what is considered “good,” “proper,” or “pretty” is context-specific and core to professional socialization. Additionally, STS research indicates a strong link between organizational narratives and the nature of the technoscientific work (Bowker 2005; Vertesi 2020). This focus on sociotechnical networks of meaning and practice aligns with the previously mentioned awareness in STS regarding the collective dynamics around coding and how code can serve as a central organizing force constituted through technological and aesthetic practices (Kelty 2008; Coleman 2012). We bring these perspectives together to discuss how situated aesthetic judgments take on a substantive role in organizing software work. In so doing, we expand upon Mateas and Montfort’s (2005) initial insight that there is no single objective value that practitioners agree upon and highlight that writing code involves an interplay of multiple, diverse aesthetics.
In the following sections, we explore the nuance of such assessments, finding that certain aesthetic terms are deployed in service of smoothing over differences and keeping tension in abeyance, while others are used to shape work practice and socialize programmers into specific ways of doing.
Methods
The data presented in this article were collected at the company’s headquarters in Moscow with permission from the company’s HR and PR departments. Empirically, we draw upon three months of intensive qualitative fieldwork at Yandex conducted by Fedorova in 2014 while she was a student at a Russian university. Although Russian academic institutions have no local review bodies equivalent to an institutional review board (IRB), this research was done in line with conventional IRB expectations that ensured privacy, confidentiality, and data safety. Participants signed informed consent forms; their information was anonymized, securely managed, and stored; and pseudonyms were used for further privacy protection. During the data collection stage, Fedorova conducted twenty-six semi-structured, in-depth interviews in Russian with developers. She also conducted four expert interviews with managers, along with numerous days of workplace observations. The interviews lasted one to four hours and were tape-recorded, transcribed, and translated into English by the author. Interviewees were selected to represent a wide range of demographics, skills, and experience levels in programming. 2
Initially, interviews did not focus on questions about the aesthetics of code. However, after several interviews, it was obvious that “beautiful” and “ugly” code was a recurring topic brought up by participants. The author then started integrating questions devoted to understanding the use of these aesthetic terms, asking questions such as “what does beautiful code mean to you?” or “what does beauty in programming look like to you?” Further, when participants brought up scenarios in which ugly code was called out, the interviewer would probe for situational details and the practical ramifications of such assertions.
Noting this complexity around the language of beauty, our first round of analysis focused on unpacking assertions of beauty in descriptions of code to uncover what work this language was doing for individuals and the organization. We found that although employees had individual opinions on the qualities of beautiful code, they did not see these opinions as relevant to the practice of coding at Yandex. While Yandex developers were eager to talk about the beauty of code (and often brought it up spontaneously), they also expressed confusion when asked how beautiful code was connected to their actual practice. For example, when asked about writing beautiful code at Yandex, developers would reply with comments such as “I thought you were interviewing me about programming. Beauty is more of a philosophical question for me. It’s different for everybody;” “regardless of my views [on beauty], we all strive to write similar code, so why are you asking?” “the best code you can write looks like the code that already exists here [at Yandex]. It’s not about beauty; it’s about reliability;” or “it’s an interesting topic, but to work here, you just need to be consistent in your code and with everyone else’s code.”
These quotes made it clear that writing beautiful code was not an overt goal for Yandex developers. Instead, their primary objective was to write code that looked the same as that of other developers at the company: “code has to look like it was written by the same person.” Yet Yandex developers did not recognize “looking the same” as an aesthetic in itself. This insight inspired another round of data analysis in which we looked beyond assessments of beauty to explore the variety of aesthetic terms deployed by participants. In so doing, we focused our attention on assertions about the multiple forms of ugliness. Our analysis of the emic language of ugliness suggested that, unlike abstract debates about beautiful code, assertions of ugliness pointed to specific lines of code and carried immediate and direct consequences for technical practice. Avoiding ugliness resulted in a new category of code that did not have a corresponding emic term. We called this category “not ugly.” “Not ugly” is not a spontaneous category, but a default category for all code that is collectively approved to become a part of the Yandex codebase.
Research Setting
In 2014, when the initial qualitative research was conducted, Yandex was headquartered in Moscow, with additional offices located in twenty Russian cities and nine other countries. At that time, the company employed more than 5,000 people, with software development as the largest segment of the organization (around 60 percent). The majority of incoming software developers were recruited from graduate and undergraduate institutions throughout the country. Most had a disciplinary background in mathematics or engineering.
Employees were organized into functional teams, each responsible for a specific product within the company (e.g., Yandex Search team, Yandex Cloud team, Yandex Taxi, and others). While there were distributed teams with some teammates geographically separated, most of the developers worked at the company’s headquarters. Each floor of the headquarters had an open office plan with a few enclosed meeting rooms. In part due to the open floor plan, most of the work at Yandex happened in silence. The layout of the space and office etiquette discouraged developers from engaging face-to-face as this would generate noise and distract coworkers. Interactions mostly took place through instant messaging and on the company’s intranet.
The company’s source code (which is human-read and machine-interpreted) was stored in private GitHub repositories, a proprietary system for managing software development projects that both stores the code and tracks changes to it over time. Yandex developers used GitHub to write code, review each other’s work, and leave comments. Yandex was somewhat unusual among large software companies in that the entire codebase was open to everyone in the company, meaning that employees from other teams had access to and could review the code of a colleague they did not work with directly. Employees joked that Yandex worked like a “huge startup.” Indeed, the company had a relatively flat organizational structure, minimal hierarchy, and an emphasis on employee autonomy and the right to make decisions: At Yandex, you’re free to talk to anyone. Even within a small project, you will contact lots of people from other projects because we are encouraging developers to share and reuse code. You talk with anyone and about anything, even the CEO. If he has time [laughing] You can even argue with your manager if you disagree with their opinion. We believe that this is how the truth is born. (Aleksey, age forty-one)
Senior Yandex developers spent much of their time reviewing and reading code rather than writing it. Code review is an important aspect of work at any software company because it is the mechanism for setting and maintaining standards for quality code. Yandex did not have any formal rules on code-writing practices, and teams were allowed to develop their own procedures and be flexible. Yet flexibility was limited by the fact that everyone was required to share the company’s code: Since we reuse a lot of code, code has to look like it was written by the same person. You can’t come from another team and be unable to understand what’s written. Yes, we are flexible within the teams, but still, you need to write the code in the same manner. (Pavel, age forty-two)
Specifically, fieldwork documented that when developers at Yandex talked about code, they used aesthetic terms as much as technical ones. Code was described as “beautiful,” “elegant,” “a delight to read,” and “inspiring.” But it also could be “ugly,” “monstrous,” “messy,” and even “dirty.” 3 This list does not capture all the aesthetic descriptions of code that we heard in everyday conversation but is consistent with the observation that these terms generally expressed either appreciation (i.e., beautiful code) or disapproval (i.e., ugly code).
This emic language was part of everyday practice. Aesthetic judgments about developers’ coding practices were discussed publicly at lunch with colleagues, criticized at meetings with managers, and questioned on the intranet. But more often, aesthetic assessments of code were expressed privately to the code’s author during official code reviews and shared within comments through the code review tools. In fact, developers’ comments on code about to be submitted into the company’s codebase became the main site for aesthetic debates.
Building and maintaining a stable codebase is critical to organizational success. Code is rarely written to be used just once; it must be maintained (Martin 2009). Further, it is read in anticipation of ongoing engagement. Consequently, code is constantly rewritten, reworked, improved, and debugged. The company trained developers from diverse backgrounds to write code that was stable, legible, and in line with Yandex-specific coding practices. Yandex is not unusual in this regard: every software company has its set of conventions 4 (often arbitrary) about how to write code for a project. Yet employees expressed that: “Even if your code looks pretty and you followed all the conventions and style guides, it can still be bad and ugly. You can still be a bad programmer” (Ivan, age thirty-six). This suggests that there is more to the aesthetics of code than style and language rules. We argue that maintaining the codebase and training employees to do so successfully involved three distinct yet complementary aesthetic considerations (beauty, ugliness, and “not ugly”), which we discuss in the following sections.
Coding Beauty
The most heated debates were concerned with whether code was beautiful and deserved a place in the Yandex codebase. As in classical practitioner literature (e.g., Knuth 1992, Dijkstra 1982), we found a diversified group of Yandex developers who did not share one understanding of what constituted beautiful code and did not attempt to align around a concrete definition. Indeed, Yandex developers often expressed conflicting understandings of beautiful code.
One reason for this conflict is that Yandex’s code is produced by practitioners from different disciplinary backgrounds. For example, some of our informants defined beauty as a nontrivial solution inscribed in the code. Others stated that beauty was characterized by simplicity and clarity of design. These two understandings of beauty represent conflicting approaches to programming, often glossed at Yandex as “mathematical” and “engineering” approaches, 5 broadly reflecting the different forms of training and background of Yandex developers. It is worth clarifying that mathematicians and engineers were not defined exclusively according to their educational background; rather, developers used these terms as ideal types to characterize different approaches to coding.
As our informants explained, mathematicians value code that is beautiful in its solution and the formula that underlies it. Developers who take a mathematician’s perspective strive to solve problems with solutions that are unique and unexpected. However, Yandex developers emphasized that no matter how clever such code is, it can obscure bugs, be difficult to maintain, and is less easily applied to industrial needs. I see that all the time how our brainy, mathematically inclined guys are trying to create some tricks to make their code run faster. Nontrivial solutions are ok if you write for yourself. If you need to maintain such code in a team, it’s doomed. It will work like one-two times, but, at the end of the day, it’s just a bug. Your creative solution will eventually fail you at some point, and all the connected patches will crumble as well. You need to create simple and elegant code that is, by default, durable. It’s boring, yes, but such code will last longer. (Lev, age thirty-two) Ideally, you need to write code that has, so to say, growth points from the very beginning. Because other members of your team should be able to make improvements to your code, and they should be able to do that fast and easily. You can’t simply code something that works. It’s prototyping, not coding. You need to think engineering-ly; you need to encode the architecture in your writings. Only in that case, you’ll be able to see the beauty in it. (Andrey, age twenty-eight) My work is different because it is more abstract. I need to create an algorithm to invent a solution that could work with our problem. It has not much in common with engineering because software engineering is more specific and more concrete. I would say it is more about adjustment: an engineer needs to adjust an algorithm according to a situation. It seems to me that engineering is about translation or introduction. So, to put it simply, an engineer introduces an algorithmic solution, translates it from a formula into actual code. A mathematician always strives to write something universal, and I think this desire for universality is what makes code beautiful. (Mikhail, age twenty-five) Being a good programmer means that you’re never reinventing the wheel, and mathematicians do that a lot. Sometimes you need to know what is going on in other projects or open source, so you won’t be developing something that’s already been done before you. And then, you just borrow this chunk of code. Mathematicians don’t do that, as they take pride in their belief that they can invent a drastically new way of dealing with things. And in industrial software development, it is often unnecessary. They think reusability is shameful, but it’s actually quite a beautiful practice. It is pretty important stuff, as usually, mathematicians think that beautiful code stands for sophistication and complexity while, on the contrary, it should be as simple and short as possible. That’s why the code of mathematicians is often filled with bugs, hard to read, and hard to maintain. (Maxim, age twenty-eight)
The process of navigating these legacies of disciplinary mastery became apparent when employees with different attitudes toward coding needed to collaborate. Work at Yandex was performed in teams mixing mathematicians and engineers, as well as developers with other backgrounds such as physics, linguistics, and biology. Such collaborations forced individuals to put their ideological and disciplinary differences aside in order to work together: Again, you can’t really divide math from engineering. At least, I can’t do that in my work. When you are fixing a bug, it is, probably, more about engineering. But what if you need to find the reason why it appeared in the first place? You will need to do what a scientist does: you will need to explore the problem, understand its nature, run some tests, and design a solution. Sometimes, you need to come up with an algorithm to rewrite the troubled piece of code. Also, you need to understand how your improvement would work with the whole system. And I don’t know which role I’ll have to fulfill next as I don’t know what will be broken. You never see it coming. (Dmitriy, age thirty-five)
The fact that Yandex employees did not attempt to precisely define the properties of beautiful code supports our argument that, at Yandex, beauty existed as an unattainable objective that allowed individual developers to preserve their disciplinary identity (as mathematician or engineer) without undermining the goal of maintaining a Yandex codebase that looked as though it was written by a single author.
This is not to suggest that beauty was an unimportant aesthetic within Yandex. Instead, as a platonic rather than realistic ideal, multiple conceptions of beautiful code could exist without forcing a reconciliation between strongly held beliefs. The ongoing debate around the properties of beautiful code thus acted as a release valve for the organization, allowing developers from diverse backgrounds to set aside questions of beauty and develop practices that ensured functional code. I’m not sure what you mean when you ask me about beauty. There are many beauties, and for every person, beauty is different. I don’t think that matters. If you see ugly code, it’s ugly, and you need to learn how to write good code. Beauty has nothing to do with it. (Alexey, age thirty-one)
Decoding Ugliness
Code is a highly expressive technology that, at Yandex, is subject to criticism and transformation. It is critical for the Yandex search engine to work 24/7 to meet users’ needs and maintain the company’s revenue. Thus, code that did not align with the style and logic of the Yandex codebase was perceived by some as threatening and “ugly.”
We found that, regardless of what developers said about beauty, they paid strict attention to ugliness. Further, Yandex employees were concrete and pointed in their assessment of ugliness: Sometimes we have this thing when someone from the seniors [engineers] uploads someone else’s chunk of code to our internal company blog and says, “look at this nonsense.” The most horrifying thing is that, in many cases, I can’t tell what’s fundamentally wrong with it. And then there comes an endless thread of comments claiming how stupid the author is and how ugly his code is. It goes on and on until the victim fixes his ugliness. Needless to say, it is very motivating: if you don’t want to become a punching bag, you need to write good code. (Kirill, age twenty-two)
It was not uncommon for a senior developer to reject code during review for being ugly. However, ugly code was not defined based on explicit qualities. Rather, developers called out any code that did not mimic the existing codebase as ugly. Given this situated definition, ugly code took different forms: it could be stylistically misaligned, deemed overly complex, or not carry the internal logic that senior developers saw as aligned with the standard way of coding within the organization. Experienced coders at Yandex simply had to have enough knowledge of the codebase to recognize examples of ugliness when they saw it. But once ugliness was called out, the consequences were clear and immediate. Ugly code was not accepted into the codebase and developers were expected to act immediately to fix it.
Not only was little effort paid to defining ugliness or verbalizing what made code ugly, but senior developers did not attempt to teach others how to avoid writing ugly code. Rather, upon being called out for writing ugly code, a programmer was referred back to the codebase to mimic the existing way of writing, commenting, and structuring code. At first, I was trying to clarify what exactly was wrong with my code, why it was ugly, but my team lead just scrolled through some lines and told me, “There, it works like this. Just do the same.” I was unable to grasp what was good about this code. And then, after a couple of months, I just got used to their style. I guess I just started writing more consistently, and it ended up resulting in fewer bugs and miscommunications. (Egor, age twenty-four)
The fully situated definition of ugly code established at Yandex was brought into relief when senior developers described the coding practices of developers coming from different organizations: We have a guy; he just recently came to us after his work at a bank. Well…Obviously, he can’t write code. It’s not surprising, though, as he came here from a bank, but still, I’m wondering how one can write so badly?! Spaghetti everywhere! We can’t read his chunks. A total mess! (Anatoliy, age twenty-six) We have a guy on the team who won several programming contests. Honestly, we were even, maybe, a bit intimidated to work with him at some point. Who knew we wouldn’t be able to work together at all? It’s all-over ugly! We can’t understand what he is writing, and we can’t merge his code, and I can’t even read it. So dirty, I’m surprised it runs. (Vadim, twenty-seven)
While Yandex developers intentionally embraced the elusive qualities of beauty to preserve disciplinary allegiances, they were committed to pointing out ugliness. As we can see from the quotes above, ugliness worked as a language of sanction. Therefore, we argue that exposing and, more importantly, learning to avoid writing ugly code at Yandex served two roles: (1) ensuring the cohesiveness of the codebase (as demonstrated in the bank worker example) and (2) providing a situated practice of professional socialization (as in the sport programmer’s case). Unsurprisingly, assessments of ugly code overlapped with examples of code that did not mimic the existing codebase. By directly drawing each other’s attention to examples of ugly code, the developer community was addressing its most pressing need—to maintain the qualities of the existing codebase. These data suggest that voiced claims of ugly code were not trivial and carried practical implications for programming as a practice. Further, by learning how to recognize code deemed ugly at Yandex, programmers from other organizational backgrounds could be socialized into reliable employees and effective contributors to the Yandex community. We argue that one way that professional socialization occurred was through the collective and ongoing practice of learning how to avoid ugliness.
Avoiding Ugliness and Writing “Not Ugly” Code
Fundamentally, aesthetic assertions of beautiful and ugly code at Yandex did not operate on the same plane. They worked in distinct ways that simultaneously aligned code-writing practices (by eliminating ugliness) while preserving difference (by leaving beauty undefined). As we have seen, ugliness was defined in practice as any code that did not align with the existing codebase.
Developers new to the company learned to avoid ugliness by reading and mimicking the existing codebase. For example, a junior developer recalled that when they joined the company, they were instructed to review the code of their senior colleagues: In our team, and I heard that other teams do that too, juniors have to review all the code that’s being pushed to production [within the team]. At least in the very beginning, when we are fresh off the boat from university. Of course, nobody cares about our comments [laughing], but they [senior developers and team leads] believe this is how we learn the codebase and avoid ugliness. (Anton, age twenty-four)
Developers rarely, if ever, sat down and talked a newcomer through how to code in a “Yandex way.” Instead, standard practice was to call out ugly code and then tell the newcomer to learn how to avoid ugliness from the existing codebase. In describing the code review process, one senior developer noted their goal was to write code that is, “at least not ugly” (Artem, age thirty-nine). Yandex developers learned how to write “not ugly” code by getting acquainted with the codebase, intuiting and mimicking the prevailing style, and discovering coding norms through the actual practice of writing. We picked up on this developer’s assertion of the code as “at least not ugly” and, for analytical clarity, we use the phrase “not ugly” to describe a local category of code that “gets in” and is greenlit to become part of the Yandex codebase.
We want to note here that Yandex developers did not have a specific term for such code, beyond the vague moniker of “Yandex code.” When asked what the code at Yandex looked like, many of our interviewees shared the sentiment that it should look as if it were written by a single author. By mimicking the existing codebase, “Yandex code” was expected to maintain the readability, reliability, and stability of a codebase that had proven itself over time within a particular local setting and situated practice. While these desired outcomes aligned with abstract principles of good code from an engineering perspective—the so-called -ilities 6 such as maintainability and reliability (Bass, Clements, and Kazman, 1997)—developers at Yandex were not attempting to implement those abstract properties. Rather, Yandex developers were writing in line with situated expectations and a specific audience. Several informants noted that an inability to write in a way that would make sense to an anticipated readership of future Yandex employees was likely to result in bugs, misunderstandings, and other instabilities.
The importance of “not ugly” code was often overlooked by employees who were busy celebrating the mythical ideals of beautiful code or chastising specific examples of ugly code. The production of “not ugly” code was so mundane, tacit, and unproblematic for the company that it was rendered invisible in the everyday of Yandex developers—as seen by the fact that there was no stable emic term to describe it. Developers were striving to write in a style that was often just called “Yandex code,” occasionally called “good code,” and “at least not ugly code.” By responding to claims of ugliness, Yandex developers fixed their code to conform to this default category. Thus, we argue that the process of avoiding ugliness through code review, censorship, and mimicry of the existing code engendered a default local category of “not ugly” that described all code accepted into the Yandex codebase, making “not ugly” code the dominant aesthetic concern at Yandex.
We also note here that the “not ugly” category was not the only framework that regulated code contributions. Specifically, coding tools (bug trackers, interpreters) and programming language rules also informed the production of code. However, tools and language norms did not play a decisive role in delineating which lines of code were accepted into the Yandex codebase. Thus, in our analysis, we have chosen to focus on how aesthetic utterances shaped core organizational processes around maintaining the codebase and on the pragmatics of “not ugly” in coordinating the code-writing practices.
Conclusion: How Aesthetics Shape Practice
In this setting, the aesthetic dimensions of code written by developers and entered into the codebase had little to do with ideal types of beautiful code. To remain competitive in its market, Yandex needed to maintain a stable and reliable codebase and to unite employees from diverse disciplinary backgrounds. Our analysis shows that aesthetic discourse played a practical role in achieving these goals. Indeed, attempts to invent or impose a top-down formal conceptualization on software engineering practices generally do not result in “normalizing” the real-life multiplicities of code (Cox 1995). For this reason, studying bottom-up coordination systems becomes important.
Lacking an explicit or shared definition of beauty, Yandex developers had the opportunity to preserve disciplinary differences and debate their own visions of beautiful code without needing to resolve different conceptions of beauty in everyday code-writing practices. The fact that beauty remained vague and elusive helped the organization prioritize a specific way of doing things (i.e., not writing ugly code according to the local definition) over a particular way of thinking (i.e., writing code in line with an abstract ideal). This open concept of beauty played an organizational role in supporting productive differences among developers rather than a situated role in shaping daily practice.
Our research reveals that the language of ugliness also played a functional role in the organization. However, while beauty existed in the realm of the ideal (preserving difference), ugliness at Yandex was vocalized and called out (supporting organizational stability). It was through the presence of ugliness that professional alignment, socialization, and coordination were achieved in practice. We cannot say whether Yandex developers consciously used aesthetic language to preserve diversity in disciplinary identity or to align code-writing practices, and we assume they did not. However, the use of aesthetic language at Yandex was both powerful and pragmatic in terms of organizational functioning and maintaining an esteemed codebase.
In closing, we reiterate three findings from this research. First, multiple aesthetic designations of code operate simultaneously in an organizational context. In line with STS literature (Mackenzie 2006; Kelty 2008), we argue that aesthetic assessments do not reflect an innate quality of code, nor do they derive from individual preferences. Rather, the power and meaning of aesthetic language emerges from a communal undertaking. Rather than adhering to one ideal, developers at Yandex dealt with a messy combination of aesthetic values that each served a unique organizational function.
Second, instead of describing various aesthetic properties of code, we traced how aesthetic language was deployed in practice, revealing how assertions of ugliness acted as clear pointers to code deemed problematic and thus directly shaped the situated practice of writing code. Third, the process of avoiding ugly code (by learning to mimic the codebase) served to socialize newcomers. As such, it operated as a collective form of self-management.
The various roles of aesthetic language in this instance suggest the value of studying positive and negative aesthetic designations in technical practice symmetrically. Assessments of beautiful code are diverse and remain a topic of active debate among Yandex developers specifically—and computer scientists and practitioners more generally. However, analyses that account for ugliness or gives guidance on how to avoid writing ugly code are rare. The same is true for aesthetic theory in general: researchers and philosophers often focus on the intricacies of beautiful rather than ugly. 7 However, such one-sided investigations into aesthetic concerns cannot capture the situated reality of the role of aesthetic language in practice. From an organizational standpoint, situated claims of ugliness at Yandex were arguably more important than beauty in their direct effects on the codebase. Yet ugliness is rarely at the forefront of wider discussions on aesthetic judgments in software or technoscientific practice writ large. 8
Moreover, we note that while there is a tendency within the programming literature and code studies to compare programming to art (see Knuth 1974; Fishwick 2006; Cox and McLean 2012), aesthetic considerations guide these activities differently. While the role of aesthetics in art has changed, 9 classic conceptions of fine art were often mired in debates about what was considered “beautiful.” Further, aspiring artists were expected to mimic the current conceptions of beauty in learning their craft. Dewey ([1934] 2005, 159, 301), for instance, writes that in order to be an original artist, one needs to “take a tradition into themselves” and “to be referred for exemplification to the work of the masters.” But while Dewey uses the words “good” and “beautiful” to explain the normative function of aesthetics in artistic training (as illustrative how-to examples), Yandex developers use “ugly” and other negative aesthetic delineations in their professional socialization (as instructive how-not-to references).
Another difference between programming and art is that software development rarely stops: code needs to be continually maintained. Unlike sculpture, painting, or music, code is never a finished object, and it is created for purposes that go beyond aesthetic ones. As our fieldwork has shown, aesthetic concerns can both complement and compete with practical and technological concerns. Aesthetic designations of code are powerful and slippery, simultaneously serving different goals for the organization. Thus, by symmetrically including both positive and negative aesthetic concerns, we can enrich our understanding of professional and technoscientific practices as well as potentially revisit some of the technical requirements (e.g., -ilities) as aesthetic achievements.
Footnotes
Acknowledgment
A sincere debt of gratitude is owed to Elena Bunina and the late Ilya Segalovich, who graciously opened Yandex’s doors for this research. The deepest appreciation goes to the interviewees, for their help, time, and the most enjoyable conversations. Fedorova is ever grateful to Oksana Zaporozhets, Olga Echevskaya, Anna Konstantinova, and Ivan Davidenko, who supported this work in its earliest stages. Mario Biagioli, Vincent Lepinay, and Melanie Feakins provided invaluable mentorship and guidance to the first author during her fieldwork. We are thankful to Tom Boellstorff, Chris Kelty, Bonnie Nardi, Madhu Reddy, Aure Schrock, and Andre van der Hoek for their insightful feedback on earlier drafts of this paper. Lastly, we are deeply grateful to our anonymous reviewers, editors, Timothy Neale, and Carolina Caliaba for their encouragement, valuable suggestions, and generative comments that contributed to the preparation of this manuscript.
Declaration of Conflicting Interests
The author(s) declared no potential conflicts of interest with respect to the research, authorship, and/or publication of this article.
Funding
The author(s) disclosed receipt of the following financial support for the research, authorship and/or publication of this article: This material is based upon work supported by the US National Science Foundation under Grant No. 1946668.
