To promote close reading of software within socio-historical contexts, CCS offers a set of reading practices to interpret specific aspects of the code. Below is an intial list of “what can be read.” (This list is hardly exclusive but meant more as a starting point for methodologies to be developed at greater length over the course of this blog and the writings related to CCS.)

The context of the software

• the coders
• years of the programming
• history of development and use
• funders
• research questions
• additional personal, testers, consultants
• programming language
• hardware
• paratexts (articles about the software)

The software itself

• procedures (how the code operates)
• the high-level structure
• Its programming

Individual lines of code can be read as:

• natural language affinities (run, execute, fire, print)
• whitespace
• clarity-obfuscation
• in-program commentary and documentation

Issues to be considered

• social implications of software
• world representations
• aesthetics
• impact on race, gender, ethnicity, sexuality, and socio-economic status
• oppositional practices: obfuscation (Mateas and Montfort), transcoding (Zach Blas)
• “values sensitive design” (Daniel Howe) or “critical design”

Tactics:

• Reading functionality against code (form-content)
• Comparing implementations in different languages
• Reading functionality against socio-historical context
• Reading code against output
• Reading “interpreted code” against content
• Reading instructions against data

And, of course, “against” here signifies in tandem with, intertwined with, in dialogue with.