Monday, January 28, 2013

A Simple Protocol For "You Are Not Your Code"

"You are not your code" is impossible to implement if you're being a dick to somebody about their code. The solution is simple: Don't be a dick. But how would a person without social skills know if they were being a dick or not? The ability to recognize whether or not you're being a dick is a social skill which many geeks lack.

Worse yet, "you are not your code" is impossible to implement if you seem like you're being a dick, even if you have no intention of being a dick. Geeks who fail at recognizing genuine dickishness fail even harder in situations like that.

I think I know some ways to help. First, a series of problems and solutions. Then, a really simple system to prevent people from freaking out. It's a little pompous but it just solves the fucking problem forever. I think in some circumstances the tradeoff is worth it.

Problem: You are not your code

In 2011, Sam Stephenson released rbenv, a Ruby environment manager, apparently designed to replace rvm, a similar project. Drama, of course, ensued:

a slightly antagonistic tone taken by rbenv's README (which has now been taken away) led RVM's maintainer Wayne E Seguin to vent some pressure on Twitter...

Part of the complaint made in rbenv's README was about RVM's "obnoxious" redefinition of the "cd" shell builtin.


Much more recently, Mr. Stephenson complained on Twitter that discussions about rvm and rbenv still center on what a great guy rvm creator Wayne Seguin is. I find this ironic, as rbenv's readme focused the introduction of rbenv around disrespect to rvm.

Mr. Stephenson works for a company which is famous for its great marketing, among other things, yet he appeared surprised that the frame of reference he used when he introduced his product is the frame of reference which people have used to understand his product ever since.

I raised this point on Twitter, with less refined phrasing, but did not receive a reply. Soon after, Mr. Stephenson wrote a blog post called You Are Not Your Code:

I have learned that in the open-source world, you are not your code. A critique of your project is not tantamount to a personal attack. An alternative take on the problem your software solves is not hostile or divisive. It is simply the result of a regenerative process, driven by an unending desire to improve the status quo.

While all this is true, in context it seems hectoring, unnecessary, and unpleasant. I sometimes think I see a similar pattern in the tweets and blog posts of a colleague of Mr. Stephenson's, namely David Heinemeier Hansson, creator of Rails. I've seen others express the same opinion.

Mr. Heinemeier Hansson wrote this on his blog:

There are lots of à la carte software environments in this world. Places where in order to eat, you must first carefully look over the menu of options to order exactly what you want. I want this for my ORM, I want that for my template language, and let's finish it off with this routing library. Of course, you're going to have to know what you want, and you'll rarely have your horizon expanded if you always order the same thing, but there it is. It's a very popular way of consuming software.

Rails is not that. Rails is omakase. A team of chefs picked out the ingredients, designed the APIs, and arranged the order of consumption on your behalf according to their idea of what would make for a tasty full-stack framework. The menu can be both personal and quirky. It isn't designed to appeal to the taste of everyone, everywhere.


It's good writing. It reads well. I even performed this blog post as a comic monologue.



But it loses credibility with a little context:



I hate to say it, but it might be fair to characterize the Ruby culture as packed to the gills with hipster drama queens. I might even be one of them; I'm blogging about drama, which sounds like something a hipster would do. But I think I know a simple solution.

The GitHub comment thread mentioned above describes a small change to Rails defaults. Many people complained that the change complicates deployments and makes design assumptions they do not agree with. Mr. Heinemeier Hansson replied that Rails is omakase.



I consider his response imperfect, but I can see some merit to his argument, because I've blogged a solution to the problem which this change poses. It's a one-line script which completely eliminates the issue, and which you can run automatically whenever you start a new project, just by adding a command-line flag to your rails new command.

So I think Mr. Heinemeier Hansson had a point, but I can't sympathize with his reaction. Saying "you disagree with me because your company is inferior to mine" is an ineffective persuasion strategy. And, both with Mr. Stephenson and Mr. Heinemeier Hansson, I think I perceive a strange combination: reasonable blog posts which appear designed to justify unreasonable behavior.

Solution: Apologize

In contrast, I want to highlight a simple apology which Corey Haines made on his blog. Mr. Haines had made fun of somebody's code on Twitter, upsetting them. Here's how he apologized:

Yesterday I made a mistake. Without thinking, I put up a mean tweet about some code that Heather Arthur wrote. And I want to apologize...

So, I'm sorry, Heather. There is no excuse for what I wrote.


There's a little more to it than that, but not much. When a person writes a real apology, you read it, and you're done. I think a similar strategy would have saved time and agitation for Mr. Stephenson and Mr. Heinemeier Hansson. Mr. Stephenson could have said "I'm sorry I disrespected rvm. Let's move on." Mr. Heinemeier Hansson could have said "I'm sorry but I'm not altering my decision. Let's move on." In either case, both would have been able to eliminate arguments.

Likewise, I want to apologize for any disrespect, in using Mr. Stephenson and Mr. Heinemeier Hansson as examples.

Problem: Haters Gonna Hate On JavaScript

I joined the Ruby Parley mailing list recently. It's a private list but membership can be as cheap as $10, which is the option I went with. The content's good, but it uses Google Groups, which is not a user experience I like or even understand.

Consequently, I only just the other day discovered a Parley email which had been sent to me a few weeks ago. I had made some comments about Ruby and its Modules, and in the newly-uncovered email, Josh Susser had replied with a tangent about JavaScript, and speculations about my personal experience with it, which I found irritating and irrelevant.

Solution: Bail

I cancelled my membership and requested a refund:

Hi, please cancel my $10 yearly membership. I want a refund. I believe a member of the podcast trolled me.

Transaction ID is xxxxxxxxxxxxxxxxxx. xxxxx@xxxxx is my PayPal address.

Not an anger thing. I've had near-death experiences, and nobody spends their time on internet flame wars after they've had near-death experiences.

I wish you all the best regardless, but I want my money back, and I want it to be a fast, simple process.

Thank you.


The bit about near-death experiences is true, and it influences your understanding of time management. "Life is fragile, nobody knows how much time they get, and I'm going to spend my precious remaining moments arguing with some dude" is not a sentence I can agree with, although it certainly has parts which make sense.

Terrifying Story About Facing Mortality

By the way, I don't mean the type of experience where you encounter a floating ball of light and learn the wisdom of the universe. I mean the kind where you're like, holy shit, I almost died. One of my near-death experiences involved this complete dipshit of a cardiologist who actually put a catheter inside my heart which was too big to fit, and caused my heart to stop pumping for a second. I was watching the whole thing happen on an x-ray monitor at the time. I literally saw my own heart stop right in front of my eyes.

Nobody's going to have that experience and then think arguing on the Internet is interesting.

In fact, it's entirely possible that Mr. Susser meant me no harm whatsoever. I wrote a reply to his remarks, making it as a civil as I could and being sure to include some useful information, so for all I know the discussion is still going on. I don't know, because I haven't been back, and won't. One way or another, it's over and done with.

Internet drama sucks up time and attention like some kind of horrible, greedy sponge-demon. Nine times out of ten the only thing that matters about Internet drama is how quickly and cleanly it can end.

Problem: The Battle of Los Angeles

A long time ago, Steve Klabnik tweeted a random comment about how he hated Los Angeles for some reason. I tweeted back that it's a great city. I grew up in Chicago, I used to live in San Francisco, and in my childhood I frequently visited London. I think I know great cities. And I live in Los Angeles.

Mr. Klabnik refused to back down, give my argument any credit at all, or apologize even a little.

(Edit: Mr. Klabnik emailed me to tell me that he remembers the events differently, and also to apologize regardless, which I think was pretty cool.)

Solution: Block

I blocked him on Twitter for more than a year. In that time frame, Mr. Klabnik moved to Los Angeles, where he now lives. We never settled the issue, but I unblocked him because he had written some blog posts I liked, I quoted those posts in my book Rails As She Is Spoke, and everything was fine until he started making fun of somebody's Node.js project and I blocked him again.

However, I block people all the time. I block them for angering me, or saying things I disagree with, but I also block them for bad spelling, bad timing, incomprehensible remarks, or reminding me of frogs. I recommend you look at Twitter as a game where you find excuses to block people and the person who blocks the largest number of people, for the largest number of different reasons, wins.

Blocking people on Twitter does not have to be about anger or hate. Blocking people on Twitter is about the fact that in real life, in chat systems, or on the phone, you can shut down a conversation, or change the subject, whereas on Twitter, there are situations where you can only either uninstall your Twitter client or block people. (Email has a similar problem, but it's much less severe, because email has a concept of deleting.) The Canadian singer Grimes said in an interview that she blocks her own mother on Twitter.

Only one person in my experience ever freaked out when I blocked them on Twitter, and they had a very widespread reputation for freaking out about things already when it happened.

A Simple System Which Always Works

Speaking of Mr. Klabnik, you're about to see his name a lot in the next few paragraphs. Before I left the Ruby Parley list, a conversation came up involving him, and in this conversation, somebody who did not know Mr. Klabnik referred to him as "Mr. Klabnik," instead of by his first name, just like I'm doing here.

I thought that was really cool. Jeff Casimir, who works with Mr. Klabnik, posted that he thought it was the first time anyone had ever said that. Technically correct but essentially wrong. I referred to Mr. Klabnik as "Klabnik" in my book on Rails, Rails As She Is Spoke, and did the same for everyone else I quoted, or whose ideas I discussed. I used last names throughout the book. To quote directly:

My goal is to make it clear that if I disagree with anyone, it's about their ideas. Using last names is more formal, but it's important to create an atmosphere of respect.

(In the initial version of my book, I followed this with a remark to the effect of "but, fuck Zed Shaw." I feel you have to draw the line somewhere. But this remark really upset one reader, so I've toned it down a bit. But only a bit. I really do think you have to draw the line somewhere.)

Where It Comes From

Nate Silver made me remember it, but I got this idea from St. John's College, where I studied for a year. St. John's has no majors, no optional classes, and no professors either, if you're going to be strictly literal; instead, you read a fixed selection of books, you discuss them, and you have tutors, equivalent to professors, who guide the discussions.

In addition to obvious topics like philosophy, literature, and history, you also study math this way, spending nearly the entire first year discussing Euclid's Elements, the first book in Western history about geometry and basic number theory, and proving its theorems. You memorize proofs, perform them, and defend them from criticism. In some cases, people will explore or invent alternate proofs.

Here's a YouTube video of two students at St. John's demonstrating the Pythagorean Theorem:



But due to a lack of context, and incredibly poor production values, the video doesn't capture what the experience is like at all. It's a very, very different experience than what people normally think of as math class. Euclid doesn't even mention numbers until you get to the end of the book. There's nothing but logic and abstractions until then, and you have to fit them all together in a coherent structure. It's a book about how a system built on a few very consistent rules allows you to build complex and sophisticated conceptual tools.

No matter how good you imagine that experience might be, for the purpose of preparing a young person to become a programmer, trust me: it's better than that.

Anyway, you also study science the same way, plus enough Ancient Greek to read a few snippets from the Elements in its original language, along with bits of Aristotle, Herodotus, Plato, Homer, and Sophocles.

The curriculum revolves around discussion as a means to figure things out. Because discussion involves disagreement, you refer to each other as "Mr. Foo" or "Ms. Bar" during classes at St. John's. This simple gesture of respect permits people to discuss provocative opinions -- for instance, religion vs. atheism -- with clarity and courtesy. And St. John's really is a place where religious people learn from atheists, and vice versa.

Why It Works

When Mr. Stephenson wrote You Are Not Your Code, he said something true. You are not your blog posts, either, or your emails, or your tweets, or your ideas. If you want to disagree with somebody's ideas, however, it's smart to differentiate between the person and the idea, and there's an easy way to do that: use the most respectful available term for the person. That makes it easier for the person to disengage their ego and actually listen.

If I'm doing serious writing about code, like in my book, I like to refer to other people by their last names, in the style of St. John's College, because this formal style signifies respect. You want that established from the beginning, as a default, so that it happens automatically. Disagreement without respect inhibits clarity, and you would have to be a compete fool to enter a programming discussion without anticipating the possibility of disagreement.

I suspect, however, that the number of complete fools who write open source software is greater than zero, in part because you can find, anywhere on the web, on any given day, staggering numbers of angry programmers expressing surprise because some discussion fell apart. Many programmers spend a great deal of time arguing without coming to any useful conclusion. I played a part in this horseshit myself for many years, but I've lost all interest in it.



So Do it

Formal modes of address constitute a simple protocol for disengaging egos. You type two letters, a period, and a space, and then you type the other person's name. It isn't complicated, but it is sometimes worth doing.