(computer) code for everyday digital technologies/objects is (usually) written by a human, or a group of humans, who have preconceived notions about the world, through their own common senses, knowledges, and values that enable them to do their work according to best practices and web-standardizations.
This paper focuses on the programmer’s embodiment of the code and how the programmer brings notions of the world into the code itself, thereby creating an invisible layer of embedded normativity. I argue that the embodied actions of developers (and their socio-historical entanglements), along with standards and best practices, normalize our everyday digital interactions, rendering certain embodiments invisible.
The programmer (and development team) are humans who are, amongst other things, aged, gendered, classed, raced, sexualized, nationalized, and educated in particular ways. These specific humans create meaning for our current interactions with, in and through multiple intersecting histories and genealogies over the space and time of the Internet.
How does this impact everyday life? How does embedded normativity within the code render the content inaccessible? (or doesn’t it?) How are our physical bodies rendered in code? What do we learn when we read the ‘code’ that represents us?
Untangling this matrix requires a close reading and queer interpretation of the code that underlies it. Using queer theory, phenomenology and critical code studies, I uncover what it means to queerly read the developer’s embodiment of the code for popular social media objects, such as user profiles and website taxonomies.
So, here’s a litttle textual close reading of some facebook code:
On August 12, 2007, Facebook had a server glitch which for a short time exposed some unexecuted code for its user home page. Many people took the liberty of posting this proprietary code snippet across the web, and it was confirmed by Facebook to be real, though, as they said at the time,
“It was not a security breach and did not compromise user data in any way. Because the code that was released only powers the Facebook user interface, it offers no useful insight into the inner workings of Facebook. The reprinting of this code violates several laws and we ask that people not distribute it further.” -techcrunch.com http://techcrunch.com/2007/08/11/facebook-source-code-leaked/
Though Facebook has changed tremendously since 2007, it still does offer useful insight and is still valuable to investigate/do a close queer reading to see how the code itself re-creates ‘real world’ systems based on the programmer’s embodiment of the code and how the programmer brings notions of the world into the code itself, thereby creating an invisible layer of embedded normativity. The embodied actions of developers (and their socio-historical entanglements), along with standards and best practices, normalize our everyday digital interactions, rendering certain embodiments invisible at the same time they become more hyper-visible.
The released source code totals about 10 pages of code, which act as a container for all the components that make-up the Facebook user page. The first 24 lines of code simply ‘call’ for 24 other code files to be included when this page is run.
Each of these 24 code files contains executable code for different, separate functionalities, and are kept separate from the main file, to be called upon when needed, for security purposes and for ease of finding and updating code, adding new functionalities, amongst other programming needs.
The snippet that here checks for login information, calls for, checks and places announcements, advertising, friends, posts, pokes, upcoming events, birthdays, friend requests, status updates, time zones, and photos,
Briefly -about the code
Though this code can be read from top to bottom, (and is numbered so as to appear like there is a chronology) each set of functions can be called at any time- making this non-linear, so to speak-
And, code is not static- meaning that as Facebook has expanded its reach, has added user functionalities, the developers must adjust the current code to work with the new code, without breaking current actions and interactions.
Code Comments
Code developers need to be able to communicate to other developers what has been done in particular areas- guidelines for reading the code and knowing what it does and how it connects to other pieces of code. This is done through a standard known as code comments – which a way for humans to leave messages for other humans, while allowing the computer/machine to ignore it.
In this way, Comments are extra-functional- they fall outside the realm of the code itself, in that they don’t compile, and are not executed as part of the software. Essentially, we can think of the code and the comments as having two audiences, the machine and the human. One for instruction and one for execution, though as we will see, there are leaky, unsealed boundaries between instruction and execution.
2 code commenting examples:
// this is a single-line comment
/* this is a
multi-line comment */
Code commenting standards are built into programming languages as a way to prevent new developers from breaking an application, piece of software, or in our case, the Facebook user page.
So, for example, on line 23 it says
// require login
the two slash marks prevent those lines from being read by the computer as code, and the note ‘require login’ simply lets the developer know that the code that follows is the code that does just that.
The code below it:
$user = this user, which represents all users, including this individual one, (like the N variable in algebra) must login in order to proceed.
Other commented lines include things like (lines 35-68):
Line 35.
// homepage announcement variables
Line 51.
// todo: password confirmation redirects here
Line 52.
// do we want a confirmation message?
Then, since anything can be written in the comments, and no one sees it but other coders, developers sometimes place song lyrics and poems as hidden gems for human readers, but they also sometimes explain their code in surprising ways.
(QUEER THE MERMAN)
One line 121 – the comment reads:
// Merman’s Admin profile always links to the Merman’s home
So, to unpack this a bit, this comment technically appears to explain that the code below is about people who are administrators for groups and pages- and that for those people, the admin status is always connected to the user’s profile. So, if you are an admin for a page, you don’t have to login separately from your regular user login- the admin permissions are granted to you automatically this way.
Now, to the more interesting piece of this:
a merman is a male mermaid- a mythical creature, lesser known than his female counterpart.
Why did the developer choose to use the merman, an unknown male mythological figure, who is half-human and half-fish, to describe a user with administrator powers?
The obvious connection might be that the Merman, like mermaids, like to sing to people and cause them to become distracted- sometimes causing the people to drown.. just like Facebook has the capability to pull our attention from other things- sometimes to our detriment.
Most likely though, is that someone on the development team had a friend named Merman.
Ok- so now that you see where a code comment can go…
‘RETARDED’ CODE
Let’s jump down to line 247
// we special case the network not recognized error here, because affil_retval msg is retarded.
So, I’ll translate- here we have an explanation of irregular code functionality that has been ‘fixed’ by ‘special casing’ (whatever that is) the error, which, according to a developer, is retarded.
here, a developer calls non-working code ‘retarded’ – bringing his/her own pejorative terminology to the code comments in order to describe code that doesn’t quite work properly.
This not only speaks to the developer’s own knowledges, but also speaks to the community of developers that this comment-writer thought might be interacting with this code in the future.
This comment lies within the code that, once executed, creates pages where our friends and family post about their lives- many of them using Facebook as a way of communicating about their own family and friends with special needs.
How might they feel if they knew that the word retarded was used in this way, that was used systematically across Facebook to explain a piece of code that helped to create their own post on, say autism, or turrets?
These code comments are an easy way in to the coder’s mindset,but it lays the ‘responsibility’ for that comment, those words, at the level of the individual, just within the human readable, machine ignorable comments within the code and not at the systems level, which is where we might begin investigating how normativities are produced by and entangled with the very actions of the site itself, so what happens when we design systems and worlds we want to live in instead of objects that perform tasks? does the code and commenting change? does facebook continue to exist?
WORKING CODE
To begin at a systems level, we need to understand that code must ‘work properly’ in order to run successfully. Most of us have probably arrived at a page online that didn’t produce the expected results, and returned an error, or a blank page instead.
Only code that works can pass muster – code that has significant issues will need to be worked with and changed in order to meet the requirements for inclusion- for it to be useful, to not ‘break’ the site.
So, briefly, let me define ‘working’ code for our purposes today-
-as code that is able to be compiled and interpreted in order for the intended actions to take place.
A program is ‘compiled’ in order to translate the original code from one programming language to another- Wendy Chun, at the Critical Code Studies Conference last Spring, spoke of this translation as a conversion of the symbolic into real, which in turn, causes meaning to be re-inscribed in the action.
As different functions are being called by the end-user- chunks of code are constantly cycling between interpretation and re-compilation- therefore the code is also always circulating between the possibilities of symbolic and real, of meaning and action, of absence and presence.
So, to look at the comment again –
the correction of this code chunk allows the code to execute properly, and by doing so, it erases the code labeled ‘retarded,’ making it disappear from the user’s experience.
Reflexivity constantly recirculates and re-orients the code within the push-pull of systemic conceptions of normativity and queerness, thereby forcing the system to be oriented through its movement from broken-ness to fixed-ed-ness and back again.
Queerly, this code labeled as ‘retarded’ is only present by its absence – as soon as it is fixed, it no longer exists, except through the developer’s potentially pejorative comment within the code.
Therefore, when my friend posts a link about autism on Facebook, her action of clicking the ‘share’ button connects her as user, and her friends as recipients, with the worldview of the developer who believed that code could be labeled ‘retarded’ – all without it being visible or known to them.
The code becomes a discursive trace that deploys queerness through the cycle of absence-presence, rendering certain bodies visible only when leaked to the public.
BRIEF HISTORY
I want to contextualize this a little by briefly historicizing the discourse around this code.
Though we don’t have the time to do justice to this today , I hope to quickly show how the code becomes a text of classification, a mode of regulating embodiment through the always already embedded power relations of its history.
So, I will mention the military history of the Internet, and it’s World War II and Cold War origins, which places its birth within a very particular American society, which set the trajectory for the Internet’s modern-day framework.
Then, there is the practice of academic Computer Science, programming, human computer interaction design, and standards and practices, which combine in such a way as to normalize certain people as over others, creating a framework that renders invisible those that don’t fit in with their world view.
This framework encompasses programmers and their teams- who are (currently) humans, who are, amongst other things, aged, gendered, classed, raced, sexualized, nationalized, and educated in particular ways. These specific humans create meaning for our current interactions with, in and through multiple intersecting histories and genealogies over space and time.
Standards and best practices reinforce these normalizations through the very production process that presents a programming team with a challenge- a problem to solve– which reflexively circulates within the pre-ordained framework of standards and best practices.
Software, code and programmer together form an interlocking cycle- developers use code to solve problems created by the idea in the software creation itself- a case of the system reflecting itself-
both are based within the ‘real’ world of social construction and therefore the team of developers/production managers try to solve pre-existing issues related to their mirroring of the ‘real’ world-
this then affects the structures of knowledges within the systems of code –from the type of programming (ie oop, symbolic, relational, procedural) to the resulting categories on the end-user’s screen.
The code is a set of ‘rules’ – which are really value systems – every choice, from programming language to user-interface/interaction – are all choices made on the development team’s knowledges – so since people tend to reproduce what they already know,
QUICK FORAY INTO THE INTERFACE
By taking a quick look at the Facebook user profile interface, we can see how a /computer science problem-solving approach led the developers to embed ‘normativities’ within the code itself as well as the site functionality.
The interface allows the user to write-in their current city and hometown, political views, religion and even a bio. Sex is an option, but male and female are the only choices. There is no gender option. Additionally, a user can only be interested in women and/or men, and can be ‘looking for’ friendship, dating, a relationship or networking. There are no choices for one-night-stands or S&M, no choice of being gendered queer, or sexed as intersex.
Facebook also gives users interesting choices for relationship status: standard ones such as married, single, in a relationship, engaged, widowed, separated, divorced, civil marriage, and domestic partnership, plus ‘its complicated,’ and ‘in an open relationship.’ These last two, presumably, are to allow people to define themselves outside the mainstream of ‘respectable’ sexual relationships.
The contradictions between implied primary sexuality, (Adrienne Rich’s COMPULSORY HETEROSEXUALITY) and the enforced hetero or homo normativity reduce the Facebook user profile to the historically representational instead of lived, actual embodiments.
These choices, built into the system as simple ways of problem solving, render certain people invisible within the system itself, which at the same time it creates invisibility, also allows room for what many people consider as transgression, or a hyper-visibility through alternate uses or doings.
Yet this queer hyper-visibility also makes us less digitally ‘mobile’- we ‘friend’ people who are like us, we tend to stay away from those who disagree with our identity-politics. How we frame what we know frames how we mark people as ‘other’ or different – rendering particular groups both invisible and hyper-visible at the same time.
Our digital realities become hyper-coded extensions, further entanglements with
always already reproducing rules and value systems that place, identify, render, visualize, hurt and destroy.
IN CONCLUSION
Through the extra-functional significance of code comments, and the standards of web programming practices, we begin to get at the hyper-codeability of marginalized bodies, made visible through the developers’ world-view, and their emplacement as problem-solvers within a pre-ordained socio-historical framework.