Reflections on Gabriella Coleman’s _Coding Freedom_, part 1

Am I a hacker?

Since it was the Geek Feminism book club pick recently, I read Gabriella Coleman’s book Coding Freedom, which is available online for free.

It’s a dense, challenging book with lots of food for thought, so I had too much to say about for just a comment on Yatima’s post. I’m going to write one post per chapter. This post is about the introduction to the book and chapter 1.

The beginning of the book left me with a slightly disoriented feeling. Eventually, I realized I wasn’t sure whether I was reading the book as an outsider to the subculture she’s writing about, or as an insider in it. Coleman makes the choice, which I agree with, to use the term “hacker” to refer to people doing open-source software. Am I a hacker? To decide, I figured I had to look no further than the Jargon File definition, which lists eight senses of the word:

1. A person who enjoys exploring the details of programmable systems and how to stretch their capabilities, as opposed to most users, who prefer to learn only the minimum necessary. RFC1392, the Internet Users’ Glossary, usefully amplifies this as: A person who delights in having an intimate understanding of the internal workings of a system, computers and computer networks in particular.

I’m already not sure how to answer. At one point, I would have absolutely said that I delighted in having an intimate understanding of the internal workings of a system. But with time, “delight” has come to seem like too strong a word. (If you’ve read my previous posts on Geek Feminism, that won’t come as a surprise to you.)

2. One who programs enthusiastically (even obsessively) or who enjoys programming rather than just theorizing about programming.

“Enthusiastically” seems like a strong word to me now, too. But I certainly like programming more than I like theorizing about it.

3. A person capable of appreciating hack value.

Sure, I think I can appreciate it.

4. A person who is good at programming quickly.

Again, I’m not sure. I’m good at it, I think, but sometimes my anxiety gets in the way and slows me down to what seems like a snail’s place, and — aware of what’s happening — I get anxious about that too and get into a feedback loop. Plus, using a compiler with a long edit-compile-debug cycle, like I’ve been doing for the past two years, makes it hard for anyone to program quickly!

5. An expert at a particular program, or one who frequently does work using it or on it; as in ‘a Unix hacker’. (Definitions 1 through 5 are correlated, and people who fit them congregate.)

I’m an expert at a few particular programs, yes. (I’m not so sure I agree with ESR that these five definitions are correlated.)

6. An expert or enthusiast of any kind. One might be an astronomy hacker, for example.

This broad definition seems to include me, sure.

7. One who enjoys the intellectual challenge of creatively overcoming or circumventing limitations.

Yes.

8. [deprecated] A malicious meddler who tries to discover sensitive information by poking around. Hence password hacker, network hacker. The correct term for this sense is cracker.

No. Though I’m no longer very sure that the correct term is “cracker” or that there’s really such an absence of correlation between definition 8 and the other definitions. ESR’s “[deprecated]” seems rather prescriptivist.

So I’m still not sure whether or not I’m a hacker. I’m still not sure whether my take on what Coleman wrote about hackers is the take of an insider — someone who can meet her neutral, anthropological gaze with the complementary perspective of inside experience. Or was my reading of the book the reading of someone who, just like Coleman, has never truly been an insider in hacker circles?

I don’t know. Sure, for the past two years my entire salary has come from writing open source software. But the words that stand out to me from the Jargon File definition, words that also feature in Coleman’s analysis of what makes hackers tick — “enthusiasm”, “delight” — don’t seem to be words that characterize my work days now. Though enthusiasm and delight are what got me onto the path that led me to where I am, they are also the things that make me feel distant from a lot of my colleagues, ones whose senses of enthusiasm and delight in their work seem less unscathed than mine.

Practicing Freedom

Part of what I hoped for from Coding Freedom was a better understanding of what might separate me from them. I had high hopes for the book when I read the first epigraph:

“We must be free not because we claim freedom,
but because we practice it.” — William Faulkner

In this context, the quotation evoked what I’ve been trying to say in most of my Geek Feminism posts. That is: I’ve been trying to express my observation that when open-source people say they support freedom, they actually mean that they only support freedom for people who are like themselves and for people they see as their peers. Peers must be white, male, heterosexual, cis, and upper-middle-class — or, if they’re not all of the above, willing to use their freedom to say only things that white, male, heterosexual, cis, upper-middle-class people might say.

I finished reading the book feeling like either it didn’t get there, or it addressed this point in a way that was too subtle for me. Close to the beginning, Coleman mentioned that she wasn’t going to talk about gender politics. It’s understandable that she chose not to. Any woman writing about open source would run the risk of having her thoughts on gender dismissed because many male hackers believe women to be inherently biased about gender (and believe themselves to be, as men, not gendered and therefore not biased). The people she was writing about might well have extended that dismissiveness to her entire body of work. Of course, I don’t know if that’s why she chose not to address gender, but there are certainly many imaginable reasons not to.

And yet, without addressing the issue of who doesn’t get invited to the party of enthusiasm and delight that Coleman paints such an appealing picture of, there’s something missing. That said, I think gets it right in writing about the subjective experience of programming in a way that few writers that I know of ever have, which is remarkable for someone who hasn’t spent her life immersed in it — the only comparable writings about it that come to mind are Ellen Ullman’s books The Bug and Close to the Machine, and Ullman is both a programmer and a writer. Coding Freedom has bits that made me write “Yes!” in the margins all over the place, like on page 11:

…their deep engagement, sometimes born of frustration, and at other times born of pleasure, and sometimes, these two converge.

and

hacking is characterized by a confluence of constant occupational disappointments and personal/collective joys.

(ibid)

and

In encountering obstacles, adept craftspeople, such as hackers, must also build an abundant “tolerance for frustration”… a mode of coping that at various points will break down, leading, at best, to feelings of frustration, and at worst, to anguish and even despair and burnout

And yet, she goes on to say, the frustration isn’t all; hackers keep hacking because they’re pursuing (in Martha Nussbaum’s words) the unimpeded performance of the activities that constitute happiness. This rings true for me. When my work is going well, hacking is “the unimpeded performance of the activities that constitute happiness”, in a way that literally nothing else I’ve ever experienced is. And when it’s not going well, I keep going because I hope that that unimpeded performance will come again.

But then — in my opinion — she goes a little bit far: “In the aftermath of a particularly pleasurable moment of hacking, there is no autonomous liberal self to be found.” (p. 13) To which I say: if only! I know that I got into programming because it was a way to lose myself, to forget I had a self, to forget there was any such thing as “I”. It was something that, as a closeted trans teenager, I desperately needed — and that I got into programming (a route to middle-class financial success) instead of, say, crystal meth, was pure luck. But just like the pleasures of addictive chemicals (so I hear), the pleasure of programming diminishes with time, or at least it has for me. When it starts to be what you have to do — and surely most hackers aren’t trust fund kids, and have to earn a living somehow — it gets to be less fun. At least for me. Perhaps that’s a character flaw of mine; when people who have been hacking for decades say they still feel like the luckiest person ever to get to do it for a living, I’d like to believe they’re engaging in wishful thinking, but part of it worries that it’s true, while in the meantime, I’m incapable of ever feeling that way again.

Personal and Political

The personal pleasures of programming, though, aren’t divorced from politics, and Coleman acknowledges the connection vigorously. For example, on page 14:

Free software hackers undoubtedly affirm an expressive self rooted not in consumption but rather in production in a double sense: they produce software, and through this technical production, they also sustain informal social relations and even have built institutions.

I found this statement a bit unsatisfying. How can I produce without someone else consuming? (This is, by the way, why “maker” culture makes me uncomfortable. How much physical stuff does anyone need, regardless of whether they made it on a fancy machine or bought it at the Dollar Tree? Though at least with software production, the results don’t have to end up in a landfill if they aren’t needed…)

I like the idea of “unalienated, autonomous labor”, but I’m not sure how unalienated or autonomous most hackers really are — again, assuming that most of them have to work for wages and choose to do so by writing software (a plausible assumption since, it seems, software is rapidly becoming one of the few highly rewarding, low-risk career paths left in North America). I don’t feel unalienated or autonomous; I take orders, and I guess if I keep at this, someday I’ll give orders. I feel alienated because in order to earn a living as a programmer (which is the path of least resistance for me to earn a living), no matter where I work, ultimately my income is very likely to originate from one of a few sources: the military (killing bodies); advertising (killing minds, by creating desires for things that aren’t needed); or the finance industry (some of both). The pleasant emotional states I’m sometimes able to achieve while writing code don’t change that fundamental reality.

Around this point in the book, I started wondering how much of Coleman’s analysis is predicated on the assumption that hackers work for free. My experience is that most don’t. The vision of a programmer coming home from work and immediately retreating to the basement to work on an open-source project for the pure joy of it, unrelated to work (no doubt while his wife cooks dinner and scrubs the bathtub) is a romantic one, but I’m not sure how common it actually is. Lots of open-source work gets done on the clock, simply because corporations recognize that sometimes, sharing the code results in more profit. (Coleman does acknowledge the latter fact later on, but the story she tells is of the original, free, pure, Stallmanesque vision getting corrupted… and I’m not sure there was ever anything to corrupt in the first place.)

When Coleman says hackers support “a liberal politics of free speech” (p. 15), I was hoping for more analysis of just whose free speech hackers support, but I didn’t find one. In fact, in my experience, the kind of free speech hackers support is quite narrow. Racist, sexist, homophobic, transphobic, and ableist speech must be protected; any criticism of such speech must be suppressed in order to protect the free speech of those who would make remarks that marginalize and exclude (I guess you have to kill free speech in order to save it). Later on the same page, she writes “From an ethnographic vantage point, it is important to recognize many hackers are citizens of liberal democracies, and have drawn on the types of accessible liberal tropes–notably free speech–as a means to conceptualize their technical practice and secure novel political claims” — which I thought was closer to the truth. Consistently with the selective nature of the application of the “free speech” trope, hackers don’t believe in free speech for its own sake; they use it because it’s a powerful tool for getting support. At least in the kinds of liberal democracies Coleman is talking about, no one wants to say they’re against free speech.

When outside is inside

By the way, so far I’ve just been talking about the introduction to the book. Chapter 1 begins by describing what the early life of a hacker might be like. When I read it, I was hit by a wave of jealously, to be honest. My early life was very little like the prototypical genesis of a hacker that Coleman describes. ‘A hacker may say he (and I use “he,” because most hackers are male)…’ — well, I am male, but nobody recognized me as such until I was in my late twenties. I didn’t take apart electrical appliances, because I would have been afraid of the consequences my abusive mother would have imposed if I’d experimented in such a way. I didn’t teach myself to program when I was six or seven, because we couldn’t afford a computer and I’m not sure my mother would have thought to buy me one even if the money had been there. I was just barely too young to get in on the BBS era, even though I finally did acquire a computer and modem in my mid-teens. When I did get access to a computer, I wasn’t too interested in UFOs, conspiracy theories, or warez — actually, what I was interested in was connecting with other people who were like me. That, oddly enough, was what led me to hacker culture and then to programming. (And there was some porn mixed in there, I’ll admit.) The only part that does sound familiar is “The parents, confusing locked doors and nocturnal living with preteen angst and isolation, wondered whether they should send their son to a psychologist.”

So maybe I’m not a hacker. Maybe I’m just a professional programmer who lacks that extra je ne sais quoi that would make me not just a workaday programmer, but a hacker. (If you read the Jargon File, you’ll notice this boundary being drawn repeatedly — between hackers, who program for fun, and do so even when not getting paid; and staid, dull, programmers, who might wear ties and write Cobol. That sounds like a class stratification and one that hackers might well be using to their advantage.)

Next to the line (on page 26) “Nonetheless, he grew to adore the never- ending, never-finished nature of technological production, and eventually fell, almost entirely by accident, into a technical movement.”, I wrote the note, “what about the part where you start hating computers?” And I’m reminded of a tweet that my friend Caylee Hogg wrote:

“I’m not in cs because I like computers. It’s that I don’t trust them and want to keep an eye on those fuckers.”

And I really think this is a key distinction. The hackers that Coleman talks about seem to be genuinely working with computers because they like them… but for Caylee, and me, and not a few others, it’s about not trusting them — and for me, at least, not trusting the people who like them. I work on statically typed programming languages with type systems designed for soundness because I don’t trust the intentions of hackers, cowboy coders, or anybody else who’s immersed in enthusiasm for programming — because enthusiasm for programming doesn’t tend to go along with rigorous attention to quality, to handling corner cases well, or to designing user interfaces that non-programmers can use without frustration (just to name a few things); it doesn’t go along with empathy for people who aren’t programmers.

I’m getting off the topic, but I guess it’s to do with more of why I’m not a hacker, why my reading of Coleman’s book is as an outsider, albeit one who has spent time among hackers, just as she has.

Of love and snark

In about this part of the book, I began to wonder whether hackers really, uniformly, love everything about computers and software. Am I not a hacker because I don’t? Or is the love less black-and-white than the picture Coleman paints? (The use of “sensuality”, on p. 27, might be a stretch.)

The life she’s describing in this chapter seems to be the life of a quite privileged child, one with genial parents who (at the least) provide a computer and a room of one’s own. Or perhaps it’s the privilege, as well, of having grown up in a particular era: “time, most programmers who learned about
free software anywhere between 1985 and 1996 greeted it as if they had stumbled onto a hidden treasure trove of jewels, with the gems being Unix-based
software and its precious underlying source code.” I was born just a bit too late, I guess, because by the time I installed Linux for the first time (1999), I just sort of took it for granted that there was a free Unix.

Likewise, the excerpt from the Jargon File about “larval stage”…

“the ordeal seems
to be necessary to produce really wizardly (as opposed to merely competent)
programmers.”

…makes me think I’m not a really wizardly programmer. Maybe all of this is the lament of the non-wizard, and I don’t have a clue about what it’s like to live the experiences Coleman documents because I’m not a wizard.

Reading the Neal Stephenson quotation on p. 37, though, I recalled that not all hackers are united in love for Unix — for example, how about the Unix-Haters’ Handbook? I think it does hackers a disservice to suggest they’re so united about any ideological or technical question. Coleman talks a lot about hacker humor, but I think she still doesn’t give the full picture… the one she gives is more of the hero-worshipful side of hacker culture, the one that turns me off, and less of the snarky, iconoclastic side that’s expressed in the Unix-Haters’ Handbook. It’s the difference between the “worse is better” philosophy and the “worse is still bad” philosophy. The latter one is the one that hopes to do better — and, I’d hope, it’s related to the one that hopes to do better at including everybody.

Meritocracy

Coleman brings up an interesting point on p. 38: that initially, hackers saw free software as equivalent to ‘free beer.’” This is especially
ironic, since some programmers now adamantly insist that the free in free
software is precisely about “speech, not beer”. Ah, backjustification. When I was nine, I wanted to become a vegetarian because I didn’t like meat. Not too long after, I read that some people were vegetarians because they didn’t like killing animals. I decided that I, too, was one of these “ethical vegetarians”. But to be honest, I never liked eating meat in the first place. Perhaps the slogan “free as in freedom, not as in beer” is a little bit like that. And anyway, how different are these concepts, really? Beer is one thing, but if finding food is what you spend most of your time on, you’re not going to have a lot of time to exercise your freedom to hack, even if it’s technically there. The same logical fallacy seems to underlie the popular Silicon Valley slogan of “I’m fiscally conservative and socially liberal.”

Page 41 is Coleman’s first use of “meritocratic” that I noted, but it probably shows up before. One thing that continues to bother me about the book is that she uses this word seemingly uncritically. As we’ve covered before, the word “meritocracy” is inevitably a smokescreen for covering up the unfair advantages that abled white heterosexual cis men receive. Perhaps Coleman was silently putting air quotes around the word, but I don’t see them.

There are actually at least two ways to think of meritocracy: one is the sense Coleman uses, where the insiders form a set of standards that the outsiders must meet in order to become insiders (possibly higher standards than the insiders themselves ever had to meet). But another sense of meritocracy is one where it isn’t the insiders, with their superior power, who get to define the standards for inclusion. Another way to think about meritocracy is to treat it as a priority to bring as many people into the community, so they can contribute, as possible. That’s a formulation that has a lot more to do with acccessibility, as I’ll talk about in a bit.

Again, when on Page 47 in a lengthy discussion of hacker conferences, she says, “These types of intense, pleasurable emotional experiences and expressions are abundant”, I want to emphasize that such experiences are largely limited to hetero, cis, white, abled men. The more intersecting identities someone has, the more restricted their access to these experiences and expressions is. It’s unfair not to mention that. It’s hard to let go and have a blissful experience geeking out with peers at a conference if they don’t see you as their peer and they express that by trying to grab your crotch at the first opportunity. Likewise, it needs to be specified who is welcome at the “rituals of confirmation, liberation, celebration, and especially reenchantment” (p. 48)

Speaking of “enchantment”, this part of the book reminded me of the hacker trope that involves using words like “wizard” and “priest” to refer to people who know a lot about computers. Since these words are usually coded as male (calling someone a “witch” to mean she was a good coder would come across very differently), they serve to reinforce the belief that only men can be good at hacking. A belief in the value of logic and rationality goes along with hacker culture, yet there’s nothing very logical or rational about attributing magical powers to people who are simply very good at a skill they’ve practiced a lot.

Open Source Values

In Chapter 1, Coleman talks a lot about the ways in which hackers value freedom and meritocracy. These are not the only possible values that could be the driving forces behind hackers’ communities of practice. Even though many hackers identify as outsiders and as idealists, their values look a lot like the standard narrative behind Western neoliberalism. Why is that? Coleman touches on it somewhat in later chapters, but one thing I felt was missing was a discussion of other value systems that could drive open-source development, though right now they don’t.

One of them is accessibility (in these thoughts, I’m influenced by Choose Your Own Logic). In computing circles, where it’s referred to as a11y, “accessibility” often refers to making computer software and hardware easier for people with disabilities (often disabilities related to vision) to use. That’s important in itself, but I think accessibility could be construed a lot more broadly. The hacker approach that Coleman talks about is about making it possible for anyone to use software… so long, that is, as they have the cognitive and emotional resources to put up with lots of frustration and arbitrariness, to learn lots of seemingly arbitrary rules, and deal with broken systems (often by fixing them). Do you have to meet this high bar in order to be able to contribute to software? Or just to be able to get something out of it? If not, maybe accessibility as a value might be worth considering. Another thing that acccessibility that means to me involves documentation. As tangentline on Twitter pointed out, if software isn’t well-documented and you have to go on a potentially hostile IRC channel and negotiate a likely-male-dominated hacker space in order to get information, that’s putting up a barrier both to its use and to people who might otherwise be able to contribute to it. So to me, another part of what accessibility means is to prioritize good documentation so that it’s easy for somebody to get involved without immediately having to navigate an unsafe social situation. And I suspect that hackers’ famed antipathy to documentation writing is not an accident — if people have to navigate informal social rules rather than having formal documentation to consult in order to get involved, it shuts out people who aren’t a good “culture fit”.

Another value is quality. While I want to be clear that I’m only speaking anecdotally here, as someone who’s worked both in academic research groups that were about applying formal methods to prove stuff rigorously about software, and in software companies, there seems to be a lot of tension in both directions. In hacker circles, programming quickly seems to be more valued than programming correctly. If you read through the Jargon File and other hacker writings, there’s a lot in there about the joy of a good hack and the importance of releasing code early, and not as much about the pleasure of stating formally, in a machine-checkable language, what your code is actually supposed to do (not surprising, since that’s really just another form of documentation). Quality matters not for some obscure, pointy-headed, theoretical ivory-tower sense of purity — but rather, because when software has bugs, real people waste their time (and potentially, money and lives). Valuing writing software quickly, but not valuing writing software that’s correct and reliable, reflects a sense that other people ought to be doing the work that’s not so interesting.

I think accessibility and quality are related. I think that having the patience to learn how to cope with and use bad user interfaces reflects a lot of privilege. It’s not as if there’s no one in the hacker community who’s urging more attention to user interface design and pointing out that even experts need software that works: for example, git, despite being a widely popular version control system at this writing, has many critics, particularly with respect to its user interface. The hacker classic The Unix-Haters’ Handbook (I’m thrilled to discover that the full text of it is online now as a PDF) spends a lot of time criticizing the elitist attitudes that the authors perceive behind Unix advocacy — specifically, the assumption that if you as a user find a system difficult, it’s your fault for not being smart enough, rather than the designer’s fault for not making it accessible. It’s somewhat notorious that when somebody submits a bug report to an open-source project, they’re likely to be told that the software works fine and it’s their fault for using it wrong; there’s a story I can’t find just now about a Ubuntu utility that deleted your entire filesystem when used incorrectly, and in a bug report, its creator staunchly defended this functionality, saying the tool was for experts and it wasn’t his fault if a non-expert happened to try it. I think such an attitude is totally compatible with valuing freedom above all, but I don’t think it’s compatible with balancing freedom and accessibility.

All I really want to say here is that when we talk about how the open source community values freedom, it’s easy to get lost in lofty rhetoric; easy to forget that freedom is just one value, that must be balanced with others. One area where I think Coding Freedom falls short with its extensive discussions about how open-source people talk about free speech and critique intellectual property law is examiningwhat they’re not talking about and not critiquing.

Being outside looking in at outsiders

Lest you think I’m being too negative, I wish I could go to a con like the ones she’s describing: “Reflexivity and reflection are put on momentary hold, in favor of visceral experience.” But such experiences may not be available to me, even though I’m fairly privileged. Though I’m usually assumed to be a hetero, cis, white, abled man (though I’m not hetero or cis), somehow I still feel shut out of the cool kids’ club among the kids who got there because they weren’t welcome in the cool kids’ club. Maybe it’s because I have a defiant consciousness, because I remember how different it was to move in hackish circles when people saw me as a woman. Or because I listen to my friends now who are women hackers. Maybe the loss of innocence that came with all of these things just makes it impossible for me to have that “visceral experience” without the critical part of me engaging and noticing who’s excluded.

I don’t want to come off as totally critical; in pages 59-60, Coleman does acknowledge, “The poor, the unemployed (or the overly employed who cannot get time off to attend these events), the young, the chronically ill, and those with disabilities often cannot attend.” But that’s just the beginning. I think her beautiful, deep analysis would be even more beautiful and deep if it centered the outsiders, the fringes of the hacker community rather than her chosen focus, the people in the center.

3 thoughts on “Reflections on Gabriella Coleman’s _Coding Freedom_, part 1

  1. Skud

    Hey Tim, there’s a few missing links in the text above — something about git’s accessibility, and a link to tangentline’s Twitter, at least.

    1. Tim Chevalier

      Thanks, fixed the links (they got lost in the shuffle while I was copying and pasting different versions of this between WordPress and a file in my private github repo…)

  2. AMM

    If it makes you feel any better, I don’t feel like a “real hacker”, either.

    Wrote my first program in 1964 (machine code for an IBM 1620, because I couldn’t wrap my mind around assembler.) I spent maybe 1-2 years programming for fun in college. Back then, “hacker” meant someone who wrote crappy code; we called ourselves “computer jocks.”

    Anyway, I graduated in 1975 and started programming for pay, and I don’t think I’ve programmed just for the heck of it since then. All my programming since then has been directed towards some goal beyond just the program, and my attitudes toward programming have been shaped by the need to get something that actually does what is needed and is reliable in a relatively short time, plus the need to maintain it (and have others maintain it) for years, sometimes decades. “Neat hacks” need not apply (BTDT.)

    I am not what these guys (gender intentional) call a “real hacker” and I don’t want to be. And I’m not all that happy with what these “real hackers” turn out. Linux and other “free software” is full of stuff that seems like it was a lot more fun for the developer and his buddies than it is for those of us who just want to get the job done (vim is one of my particular peeves.) Most of that stuff would IMHO be greatly improved if they had to do it on a tight budget (dev time, core, disk, network traffic, CPU cycles, maintenance, configuration, etc.) and had to justify every feature or spec change to a Product Manager, like I’ve spent most of my professional life doing.

Comments are closed.