Distraction Free Reading

Coding Places: An Interview with Yuri Takhteyev

In “Coding Places: Software Practice in a South American City” Yuri Takhteyev depicts a group of developers from Rio de Janeiro working on software projects with global aspirations. His ethnography, conducted in the span of three years, provides rich detail and insight into the practice of creating a programming language, Lua, and struggling to form local and global communities. In his narrative, Takhteyev sets off with a task that is particularly akin to anthropological studies of globalization: to specify socioeconomic and political forces shaping localities and creating instances of production and circulation of transnational scope. We asked him a few questions related to the book and his research on the topics of globalization, computing expertise, and politics of information technology. Enjoy!

Cover of the book "Coding Places"

Published by MIT Press, 2012.

Q: Let’s start with a predictable question coming from an anthropologist, the question of your personal involvement. It is worth mentioning your decision of becoming, in your own words, “fully participant” and engaging in software development alongside the group you were studying with. Your positioning suggests to the reader (of a non-positivistic ilk) how powerful it can be to build a rapport through “non-parasitic” forms of fieldwork. Your case is different given your contribution of a software project, Sputnik, a wiki engine written in Lua. What prompted your decision of engaging more deeply? What differences did you notice in respect to your work before and after becoming an active participant?

My engagement with the project was fairly active from the very beginning: I was spending lots of time in the office with one of the participants, attending meetings, interviewing the participants (who were willing to talk to me quite frankly from day one). I was on their mailing-lists and their code repository was open to me. And yet with all that, I felt like I wasn’t actually seeing work, I was just seeing traces of work. This was quite frustrating and that motivated me to get my hands dirty in the code. Another factor, to be honest, was hubris. I was helping out with documentation, and we decided we wanted to use a wiki. I thought it was strange that there wasn’t a wiki written in Lua, so I thought I would write one, which probably meant at that point I had already been caught in the logic of the project.

I expected this would be a good thing for my fieldwork, but I didn’t anticipate the magnitude of the effect. In many ways, everything changed. Once I started writing code myself, all the same things that felt like dead traces of other people’s work suddenly acquired meaning, came to life. Part of this change was internal: I started looking at things as a participant, trying to make sense of things in a practical rather than just a theoretical way. Part of it was external: once I started making tangible contributions, others started treating me differently, as a fellow participant rather than a guest. Before they were telling me things they thought I would want to know as a scholar. In most cases this meant they would tend towards high-level, theorized descriptions, and I would have to work hard to bring our conversations back to everyday reality. Afterwards, my conversations with them primarily revolved around practical issues.

Q: You explore with ethnographic detail the distinctions between developers from affluent and peripheral parts of Rio de Janeiro. You turn the reader’s focus to the ways in which socioeconomic differences inform the conditions for cultivation of technical skills. One of the marked differences you explore in the book refers to the Rio de Janeiro Java users’ mailing-list (populated by novice developers) and the more elite, university educated, and English speaking Cariocas of the Lua community. An important distinction, which is common in Brazil and speaks to your depiction of differences in cultural and economic capital, is that of the “POGramador”, a programmer who uses the method of POG or WOP (“Programacao Orientada a Gambiarras” or “Work-around Oriented Programming“). What aspects of the everyday life of Brazilian programmers made these distinctions more pronounced to you?

Through my involvement with Sputnik, I had a good deal of closer technical contact with PUC-educated developers who all really knew what they were doing. My interaction with developers with less education was more distant, organized around observation and interviews. So, the differences in actual approaches to coding weren’t as apparent. What typically jumped at me was the difference in cultural capital. For example, access to vocabulary (in particular English vocabulary) for talking about software development. The more educated developers would often sound like people who have worked in California, maybe apart from some light accent. And they would achieve that without making it seem like they were trying to sound like someone from California. For example, they would only drop English words into the conversation when they would correctly guess that I wouldn’t understand the Portuguese word or when there wasn’t really a good Portuguese equivalent. With developers from lower socio-economic rungs, I would more often hear misused English words or English words used in situations when a Portuguese word would have worked just fine.

Q: Even though it is more subtle in the book, I find your play on the notion of “portability” (to “port” a software to run on a different computer architecture) and the global “portability” of Lua as a programming language created at Pontificia Universidade Catolica (PUC) in Rio de Janeiro to be very insightful. Lua became much more prominent outside Brazil, having a stronger userbase outside the country and its documentation primarily composed in English for a “global” audience. You explore throughout the book the conditions for achieving this portability, namely, the choice of using English for the “reserved words” of the language, the connections of its creators with foreign academic institutions, and its adoption by large companies such as Petrobras, Adobe, and Microsoft. Despite its academic origins, Lua managed to break out of its status as “Ph.D.ware” and its initial context of application as a scripting language at Petrobras. What parallels and contrasts do you see between Lua and other emergent and popular computer languages, such as Ruby and Python?

Lua was not created for research. It was from the beginning intended for practical use at Petrobras. It was also, at the beginning, a fairly simple language. It developed sophistication over time, and in that sense it seems to me that later versions actually bear much stronger imprint of academic research.

One interesting thing about Lua is that its authors have over the years repeatedly made a decision to keep it small. Small both in actual size, but one could also say small in terms of ambition. Software projects that become popular tend to expand, so that they cover a wider and wider range of use cases. Programming languages that start as “scripting” languages and become successful tend to grow into general-purpose languages. Lua has resisted this trend. It has avoided venturing too far from its niche. Kepler, the project I spent most of my time observing, wanted to change this, wanted to extend Lua to a new domain, essentially turning it to a full web development environment. But Lua’s team was not really behind this effort.

Q: You show in the book the extent to which the process of achieving openness and creating collaborative ties is, actually, the end not the starting point for Lua, as it is for Free and Open Source technologies more generally. Another aspect worth mentioning of your ethnography is the importance of the “center-periphery” model for your analysis. Yet, there is another interpretative possibility, which your analysis also accommodates: one in which the local and global are not opposed in terms of geography but in terms of articulation of local and transnational ties. In the history of Free and Open Source technologies we have cases in which the space of interaction for software development constitutes an online locality. Major Free and Open Source software projects, such as Linux and Apache, or Free Culture projects, such as Wikipedia are flagship examples, as they managed to constitute online spheres of interaction and moved on to create local ties by starting foundations (for managing projects) and local users groups (to enroll more users and share information).

One key challenge that I set for myself in Coding Places is to understand how human action today is situated simultaneously in local and global contexts, and how it, in turn, shapes those contexts. This requires an analytic distinction between social contexts that are localized (say, “Rio de Janeiro”) and those that are global (e.g., the Lua mailing list). Online contexts such as the Lua mailing-list can create a strong sense of “place,” which in some cases may justify saying that they constitute “online localities.” But this is still a metaphoric sense of locality. In Coding Places I avoid this use so as to not create confusion between this sense and the literal, geographic sense of “local.”

I think when talking about projects such as Linux or Wikipedia, it is important to remember that in addition to the metaphoric “locality” that such projects create, they often also have strong localized dimensions as well. Wikipedia is not and has never been just an online community of disembodied minds. It started as a project of a company based in the United States. It is today coordinated by a US-based non-profit foundation. With Linux, also, while some of the key participants have come from around the world, the history of the GNU/Linux ecosystem is tightly linked with specific places, most of them in the United States. What I stress in the book is that the illusion of online locality that some of such projects create in part depends on the actual physical locality and can start cracking as you move to the periphery.

Q: In your book there is a mention of a gender minority in the passage on the prejudices of Brazilian developers regarding the local origin of Lua. I reproduce here the excerpt of one of your interviews in which the interviewee says: “I remember that we had to do a [class] project in C and she [PUC professor] taught a new language, which just existed for a few years, invented at PUC and called ‘Lua.’ I looked at that and was like: ‘Eew! A language invented here at PUC? How stupid! I am not going to learn this. I’ll never use it in my professional life! What will I do with it?’ And I remember there being two parts to the assignment that she sent us. One part was in C, another part in Lua. And a girl who was doing a part of the assignment with me . . . [I told her] ‘Here, do the part in Lua, because I am not going to learn this stuff, I don’t want to know about Lua. I’ll do the part in C, which is more interesting, since I’ll use it’.” (Takhteyev 2012, p. 164).

Engagement with questions of gender imbalance is a conspicuous absence in our ethnographies of Free and Open Source software (and I am including myself here). This absence speaks not only to our focus on other questions, but also the very questions we find people asking in the field. This issue, however, started to be addressed in the last +7 years with a bigger number of publications with a focus on Free Software and gender (Lin 2006; Nafus 2011Krieger et al. 2006; Reagle 2013) and the creation of initiatives to promote diversity in collaborative projects such as Gnome and Wikipedia. Is there something you could share with us regarding the issue of gender inequality within the Lua community and the Brazilian software company you describe in your book?

When I was doing my fieldwork in Brazil, I did not encounter any female Lua programmers, neither in person nor on Lua’s mailing list. This absence was of course hard to miss, and I tried to note it in a few places in the book. I did not focus on it too closely, since this was not something particular to Rio or to a peripheral location. Women are under-represented in computing in Rio just like in California. But the fact that women are largely absent on the pages of the book does not mean that gender is. Male programmers are also gendered – as “men”. And even in the absence of women, gender and software are often intertwined. And sometimes this intertwining does have a local-global dimension to it. One thing I discuss in the book, for example, is the tension between the hegemonic masculinity and the “nerdy” masculinity available to software developers – and the differences in how this tension plays out in different places. I argue that the software developer community in Silicon Valley has gone a long way towards reconciling that tension, by establishing nerdy masculinity as a legitimate form of masculinity. In Rio de Janeiro, this reconciliation process is a lot further behind, so the tensions are much stronger.

Q: Could you tell us what you have been working on and what are your plans for future projects?

I have left full time university work in 2012 and am now spending much of my time at a Toronto-based software company. This has been an interesting experience, since Toronto is in many aspects half-way between Silicon Valley and Rio de Janeiro. This would make for an interesting book, though probably not one I am going to write.

I am still maintaining an affiliation with the University of Toronto, as a status-only Assistant Professor, where I have been working on a project looking at retrocomputing – people working with old software and hardware. This is in some ways a very different topic from globalization, but there is a lot of theoretical overlap: in one case we are looking at practice expanding in space, in the other case we are looking at practice persisting in time. I have been also looking closer at Free / Open Source. In Coding Places the topic of Free / Open source software is often overshadowed by the main theme of globalization, but it is actually an area of great interest for me. I have been teaching a course on Free / Open source software at the University of Toronto.

Thanks a lot for the interview! We at CASTAC would like to congratulate you for your book, which is a must-read for those who are interested in the topics of globalization, Free and Open Source software development, and politics of technical expertise. We wish you the very best in your future research projects.

1 Comment

  • I expected this would be a good thing for my fieldwork, but I didn’t anticipate the magnitude of the effect. In many ways, everything changed. Once I started writing code myself, all the same things that felt like dead traces of other people’s work suddenly acquired meaning, came to life. Part of this change was internal: I started looking at things as a participant, trying to make sense of things in a practical rather than just a theoretical way. Part of it was external: once I started making tangible contributions, others started treating me differently, as a fellow participant rather than a guest. Before they were telling me things they thought I would want to know as a scholar. In most cases this meant they would tend towards high-level, theorized descriptions, and I would have to work hard to bring our conversations back to everyday reality. Afterwards, my conversations with them primarily revolved around practical issues.

    This is so interesting on a number of levels. It’s been one of the main dilemmas in my research: how does one study people who spend most of their time sitting at a desk and typing text at a terminal?

Leave a Reply to Shreeharsh Kelkar Cancel reply

Your email address will not be published. Required fields are marked *