Why I Don’t “Code”

I don’t really like the terms code or coding used in place of program or programming respectively. I’ve felt this way for a while, and I’ve tried to prefer saying “programming” over “coding” wherever possible.

As a shortened form of source code, “code” and “coding” were probably inevitable. To me, though, I can’t help but hear them as synonyms for cipher. They feel like a subtle call-out to programming-as-esotericism, into which a small elite has been initiated, using its own arcane symbols and language.

It doesn’t help that phrases like “bro down and crush some code” have come into (and hopefully back out of) vogue.


Screen Shot 2013-12-31 at 13.39.54I’ve been playing a lot of the older Legend of Zelda games lately, since OpenEmu arrived on the scene and changed things. Link to the Past was my favorite.

The entire in-game world was just a single massive interconnected puzzle that took months of playtime to unravel as a kid. Every single thing you saw, got, heard, or did had some significance in understanding and unraveling the next piece in the puzzle. For a kid with wicked, above-average recall, it played to my strengths. That was probably the reason it appealed to me so much, and at the same time, fucked me up so much.

I went into life later already in the habit of working out and memorizing every single thing that passed in front of me as if it were some puzzle that held a part of the key of figuring out the entire world. That definitely didn’t serve me well.

My interest in the Legend of Zelda series waned around the time I hit puberty (and video games began figuring out 3D).

Toward Test-Driven Writing

In programming, we use a methodology called test-driven development. For every piece of a program we write (often called a module), we also write an accompanying suite of test cases. Ideally, you won’t find a single piece of source code that goes untested. It sounds slower, but it actually improves quality so much that it has become (mostly) uncontroversially accepted as a best practice.

Testing a piece (a unit) of code is pretty simple. Each little test asserts an assumed behavior by following a similar pattern. It sets up the environment in which that behavior should happen, runs the relevant unit of the program, and asserts the expected result. You’ll find dozens, hundreds, or thousands of these little tests for a given project, and importantly, no one may change how the project works without making a test case for their change and proving it works, independent of the other parts.

Better yet, to an extent, tests can replace explanatory comments. By encapsulating the expectations for your program, I can better describe a program’s design by illustration. Unit tests therefore serve as documentation, sometimes even the only way to understand a program.

I’m beginning to see how it might be useful to apply the test-driven model to writing. I want my writing to make a strong, believable case, against which readers can make unquestionable assertions. I’ve heard the advice to “show, don’t tell,” and I always thought it meant something like including supporting detail. Maybe that’s not quite right. The advice is not to tell at all, instead of simply backing it up. It tells me both what to write and what not to write. Just like with a unit test, I don’t need to stop and explain.

For example, suppose I want to describe a character who loves another. I might say, “Alice loves Beth.” But that’s clumsy. It sticks out of the story, rather than reading as part of it; I’ve stopped telling the story to impart this premise. Worse yet, “love” is a slippery word—it means something different for each of us. What kind of love is this? Family love? Romantic love?

What if my idea of love falls outside the reader’s experience? That is to say, what do I have to say about love itself? “Alice loves Beth” squanders the opportunity and remains silent on the subject.

In fact, let’s not say “love” in the first place. That word carries a lot of baggage. Maybe I’m not even describing something the reader would ever qualify as love. I might find I’m just bluffing, and the reader only has to call my bluff for the assertion of love to fail.

Suppose instead I write a passage like this.

Taking it down from its hanger at the back of the closet, Alice held Beth’s shirt close and inhaled slowly, afraid that she’d exhaust the source of Beth’s lingering scent. Like a flashbulb, it revealed fleeting memories, which rushed into Alice’s mind’s eye barely long enough to register before slipping away again.

I didn’t say, “Alice loved Beth,” nor did I say, “Alice missed Beth,” but who could question that those statements are true? And there’s more. We know Beth is gone, in some form that allowed her to leave behind a shirt but not much else. A faded scent demarcates a rough idea of the time passed. Something irrevocable happened. A bad breakup? A death? Possibly Alice is moving, or maybe packing up Beth’s belongings. I didn’t even indicate whose closet Alice was in. We do definitely get a sense of some romantic love that could have involved cohabitation, so that distinction may be immaterial.

My point is, it’s not just about how you feel after you read the passage above. It’s more about stating what’s immediate and undeniable, making a case, while leaving out flimsy or even misleading commentary. Within this context, every action in the story fits and drives the narrative forward. The idea of test-driven writing—even though there are no actual tests involved, beyond the reader—helps me better understand what to write, and what not to write.


Another year, another new blog. I seem to create a new one of these every holiday season. I get some time off and inevitably figure out what dissatisfies me about the previous personal site I had up—despite having gone through the same process last year, and the year before, and so on; despite leaving the site to languish for months on end; despite the urge to burn it down and start all over.

Let’s do it again. I hate WordPress, but it’s so awfully convenient. I’m probably the only person ever to migrate away from Pelican back to WordPress, so I’m going to have to do so largely by hand. I think I’ll go back and pick out the entries that make sense. That is, the ones which have little to do with the process of setting up and using Pelican, I suppose.

So this won’t be the first entry in the system, but it’ll be the first one made for this particular site. At least I won’t be starting over from scratch. Maybe I’ll leave this one up for a little while.

On Distinguishing Microaggressions

While for me the word “microaggression” made sense immediately, I’ve met people for whom the meaning doesn’t land right away.

The distinguishing feature of a microaggression is that it inflicts damage mainly by attrition. That renders the damage invisible, when taking any one isolated incident. It’s a siege tactic; like any offense, though, it ultimately works towards the same defeat, oppression, and hegemony as an outright attack. It’s only when taken in the aggregate that the damage reveals itself.

Most importantly, an invisible attack is hard to rebuff. You certainly feel it, but no one else knows what’s going on, maybe not even the attacker. By consequence, your defenses are lowered because any response looks like escalation, possibly alienating any sympathy and provoking further attack. This feeds into a kind of gaslighting where you’re not sure anything even happened, even as the inflicted damage remains.

That’s why I feel pretty glad the idea of microaggressions is being spread, to mitigate that cycle.

(Not Quite) Everything You Ever Wanted to Know about Leaving Google (And Were Afraid to Ask)

I thought I’d write up a bit about how I’ve gone about leaving Google and why I’ve done so. This is going to get a bit long, so bear with me.

This was a pretty personal decision on my part. It’s not something I generally recommend at this point. Once you try to fight the Google hegemony, you really start to realize how pervasive and powerful it is. Google positions itself as a kind of default for the web services that make up our daily lives—mail, documents, search—and even as organizational foci, like with groups, document sharing, messaging, and now Plus.

I think Plus was the thing that really started to drive a wedge between Google and me. As Google began to push Plus aggressively and made questionable policies around it (like the nym wars), I began to see Google as a corporate entity whose goals were fundamentally at odds with my interests as a person. The bottom line is that I didn’t want to be a product anymore.

I also worried about the future. Now that Google has shown the potential to tear down well beloved and well used services (like Reader), what else would they do? Talk is becoming a feature of Plus. Would mail eventually become so? That’s not what I want.

I want a home on the Internet. Or maybe a homestead. A place on which to hang my identity and remain static as long as possible. Changing from service to server a few times a decade is very awkward.

To this end, I registered a domain for my personal use (the same one which hosts this very web log) and began to wonder how best to set up my own services.

Google provides a lot of services. I wanted to replace the majority of them, where it made sense. For this post, I’m going to talk primarily about the ones I use for personal information management and communication. For me, this includes Mail, Calendar, Talk, Groups, and Voice.

Initially, I wanted to replace all these services with self-hosted open source services on a virtual server. That’s still certainly possible, but as time passed, I realize some services just weren’t worth my time or money to set up and maintain indefinitely. I realized, in some cases, that the software isn’t quite there, and in other cases, I couldn’t accomplish my goals that way. All that matters is that I control the domain and the data, really. Replacing Google has meant questioning my motivations and goals along and along and making decisions accordingly.

As an example, the first thing (and biggest thing) that I wanted to replace was mail. Gmail has innovated remarkably in the space of mail user agents, leading to amazing clients, and I’ve used Gmail exclusively for the better part of a decade, so the bar was a bit high in that regard. I also figured that server-side mail transfer agents had equally advanced in the time since I had last set up a mail server.

I was wrong. Mail servers have changed very little. What seems to have changed the most, with regards to MTAs, was all the other rigamarole to avoid being marked as spam. Between making sure my DNS setup was just right, getting DKIM signing working, making sure I had working SSL certificates, and so on, I felt like I had gotten in over my head. It certainly would have been workable, but I didn’t want to have to maintain that mess (and spend days encountering subtleties in my setup that made it insecure or flub a command and risk dropping mail on the floor).

There was also the matter of an SMTP server. I would need to send my mail somewhere. Probably using my ISP’s supplied SMTP servers? The days of sending mail around directly from server to destination in a trusted way are over, from what I can tell. This means, no matter what, I couldn’t be on my own with mail or completely avoid US-based MTAs from seeing my mail (even if the transmission itself were secure) ((I may have misunderstood all this; if so, disregard.)).

Some services just are best left to the pros.

I asked around for recommendations, and it sounds like, these days, most people are using Pobox or Fastmail. The biggest disadvantage I can see with either of those are they host themselves in the US. I don’t know what sort of PRISM arrangements the NSA has made with these providers, but after checking out Fastmail, I decided that I liked them enough that I didn’t care. Avoiding surveillence wasn’t one of my primary goals (though nice if I could accomplish it), so I ended up going with Fastmail.

For now, I’ve pointed all mail to my domain with a wildcard to come directly to my Fastmail inbox. It’s worked really well so far! I haven’t encountered spam yet, so I can’t speak to how well Fastmail deals with that, but every other feature I could want seems to work swimmingly (server-side filtering, nice UI, secure, and so on).

I have changed my mail address for most lists and services, giving each its own specific address. The transition is really still ongoing, as I wait around and see what mails end up going to my Google account and addressing the source.

I think the most awkward part was moving over Google Groups subscriptions. I’m not going to get into that subject here in detail, but suffice it to say, it’s almost completely undocumented and awkward to achieve for private lists, but it’s absolutely possible.

If mail was hard, setting up an IM server was a dream. I ended up using Prosody on my EC2 instance for XMPP ((Fastmail advertises that it has IM, but in my experience, it didn’t work, and others on the internet have complained about it.)). The only qualm is, again, interacting with existing Google users. I’m disinclined to add Google contacts, knowing I may lose communication with them at any moment—and not even know it. Maybe Google will change course someday, or maybe someone will figure out interoperability somehow despite Google. I doubt most people I know will end up moving en masse to another, more interoperable service.

At the polar opposite end of ease, I totally failed to get a working setup for a calendar server. Fastmail does not offer calendaring, contacts, tasks, or notes. I thought I could reasonably set all that up through some sort of DAV server, and I wasted probably weeks of my life (off and on) trying to find one that I could get working on my EC2 instance.

They were almost universally impossible to get working in a way that felt obvious, secure, or straightforward, and it was maddening. Every solution I found was either overengineered groupware or someone’s beta-stage private project.

Eventually I learned about Fruux on Twitter. I initially felt a pang about giving up control over this service, as well, but they won me over handily once I actually tried them. Compared to all the hours of effort I wasted trying to set up my own service, Fruux was so easy, it was like falling in love.

Okay, great, I’m no longer using Google. Now what do I do about my account there and all that data?

I want to keep the data forever and control it. I want to ensure my privacy (inasmuch as I realize the horse has already left the barn) for that backed up data.

I’ve used a combination of exports (for Calendar and Contacts), Google Takeout (for miscellaneous services, such as Voice), and a nifty app called gmvault for Talk and Gmail. All this data goes together in a directory which I’ve archived up, compressed, and GPG encrypted. As for long-term storage of this archive, I’ll probably use an archival quality CD and a flash drive.

As it all weighs over half a GB compressed, I doubt I’ll be able to print it all as a hard copy (and I’d worry about that if I did so).

Now, with the data backed up, what about the account? I’ve left my account active for the time being. It’s too abrupt, for now, to cut myself off from all Google services right now. Maybe someday in the future.

Zen Not Zen

On my day off, I was browsing the Internet and came across yet another nonsensical use of the word “Zen” to adorn a programming project. This isn’t the first time I’ve seen this in the wild. A quick search of GitHub shows an undeniable pattern.1 Even GitHub itself is complicit.

A quick glance at some of the (sometimes grating) descriptions and documentation for these projects reveals the use of “Zen” to connote simplicity, ease, and minimalism. Especially minimalism. I think the idea is to evoke harmony—with nature, with the user, with the computer, or with whatever—and peace, inasmuch as that can come from a computer.

(Searching the Internet some more, I came across a wonderful term, a “dharma-burger”, to describe this combination of Buddhism and pop culture via marketing.)

I am not a Zen teacher, practitioner, or student. However, I have to try to imagine what sort of dialogue I might engage in, were I on a team of engineers who were all white and raised in the West.

Listen, everyone, I don’t think naming this product “Zen” is a good idea. I know that we’re all white here, and when we hear the word “Zen,” we think of a certain minimalistic, natural aesthetic. We definitely want that sort of aesthetic, too. We want our product to feel good and be second-nature to learn.

I don’t think we can use “Zen” as a shorthand to refer to that aesthetic or philosophy, though, because there are a lot of people who have very different associations with the word. The bottom line is that we need to make a decision, now, before we ship, whether we want those people to be among our users or even among our team in the future.

In short, to my mind, it’s needless and offputting baggage. In other words, “Zen arts without Zen study is just cultural junk.”


Was reading over some of the ways famous writers have organized their works mentally and saw that their outlines represent a special kind of condensation of their thought process. The way they organize, plan, thread thought through thought.

I was particularly struck by Faulkner’s use of his office wall—so much space! And Joseph Heller’s outline is almost equally impressive.

Another little piece fell into place in my mind just now. I really want to indulge in the largest whiteboard or other writing surface I can find, even if I end up painting an entire room in whiteboard paint, just so I can have an enormous place to plan without geometrical limit.

I hadn’t actually realized how constraining I find linear outlines and small journals to be in that regard. I need room to explore time and points of view, to elaborate.

Maybe a computer can also give me that…


I want to talk a little about caprice. I want to talk about its invisibility; its influence; its implications on privilege; and its implications on me.

What is caprice? They’re the things that we can’t control. It’s the agent of luck, acts of God. It’s unfairness. We’re all subject to caprice to some extent, and it’s treated some of us very well, and in other cases, it’s treated us pretty badly. Or maybe it’s been a mixed bag for you. Either way, we have no idea what it has in store for us.

I have the fortunate quality of seeing caprice’s role in my life because I haven’t always had a safety net. I’ve spent a little time in jail. I’ve spent a little time being homeless. I’ve spent a lot of time being broke. I’ve let health issues impact me for years out of lack of options.

I realize that caprice is a bit harder to see when it’s always helped you along, silently privileging you and your accomplishments. This is due to a pretty well understood cognitive bias, and we’re all subject to it. We can begin to internalize “good” caprice. Now, as I write, I’m at a shiny conference full of rich people, watching them socialize in a big room full of expensive computers and robots, and I wonder how many people in this room recognize the role of caprice—of privilege—in putting them there.

I think my favorite talk so far of Open Source Bridge has been Cameron Adamez’s talk about labor, ethics, and computing. She did this really awesome thing that led to these thoughts and underscored the contrast I’ve seen in my adult life so far. First, she played a clip of a documentary about San Jose’s tent city. Of course, she followed this right away with a small clip from Chris Anderson talking to an audience of “makers” leading startups.

What does this have to say? The juxtaposition spoke volumes: about elitism, about exploitation, about class, and most especially about how caprice unites all these factors.

Disadvantaged and marginalized people know caprice much better than those whom caprice has treated well. We know the world is unfair. This plays into our impostor syndrome, unfortunately. For those whom caprice has mishandled, we’ve internalized, at some point, the idea that only some people deserve to be where they are. In other words, we are subject to a different cognitive bias, a kind of survivorship bias, which blinds us somewhat to role of caprice in others’ success or to valuing our own accomplishments later on when they’re recognized and rewarded.

How we react to this situation interests me. Some people seem to look at their marginalized peers, see themselves and their accomplishments, and conclude they do not deserve their own success.

I’ve had a little time to observe the situation and think about it, and I am much more tempted to conclude, on the other hand, that others do not deserve their success anymore than I. I look around at my peers and wonder, why aren’t you guys as awesome as I am? And it has little to do with me. There’s not necessarily anything special about me (though I do need to own my accomplishments). By and large there’s an element of stupid, uncaring, meandering luck.

I keep wondering, how can I spread this professional success, my tech accomplishments, to my friends who may be struggling, who are equally talented but in another place in life?

I’m suffering less, maybe, from an impostor problem and more of a survivor guilt. Or maybe a success guilt. Maybe impostor syndrome is just a way of turning this success guilt inwards on ourselves rather than acknowledging the fundamental unfairness of the world around us.