Monday, September 14, 2015

How I Accidentally Falsified The History Of Ruby On Rails

Once upon a time, I decided to write a book:

I'd been building Rails apps for seven years at that point. The book did well. I talked about the many insane and poorly-conceived quirks in Rails, and the reasons Rails succeeded despite those quirks. Newbie Rails devs liked it because they wanted to avoid the framework's pitfalls, and understand the real mechanisms behind the so-called "magic." People with deeper experience and perspective liked it because Rails embodies a fascinating balance of inane bullshit and inspired brilliance, and it's a challenge to uncover the unifying themes, or to understand how these two polar opposites combine.

But I left out something important.

Who do you think is the second most important person in the history of Rails? Obviously, the first is its creator, David Heinemeier Hansson. And there's a long tail of open source contributors and bloggers who did the important work of developing and documenting Rails. But who would be second in line?

Would the second most important person in the history of Rails be Yehuda Katz, the architect of the Rails/Merb merge? No. Mr. Katz's work would never have mattered anyway unless Rails had already gotten off the ground. So it's someone who came along earlier. Someone who Mr. Hansson, when blogging, frequently mentioned and quoted. That's a hint. But it wasn't the founder of 37Signals (now Basecamp), Jason Fried.

Here's another hint, to make it easy. I'll quote an excerpt from my book which describes the effect this person had on Rails:
Rails "luxuries" are in actuality not luxuries at all, but massive, almost godly productivity boosts. Seriously. The code is a mess in places, and even some of the core ideas are bizarrely twisted, but the design is just genius, especially in terms of the priorities it establishes...

This, I think, is the most important thing you can learn from Rails: Make Steve Jobs your role model when you design your APIs, and the world will be your oyster.
I'm not going to say Steve Jobs was the second most important person in the history of Rails, because it wasn't actually Steve Jobs who inspired this stuff.

Kathy Sierra inspired this stuff, and not only that, but I knew this at the time, because when Rails first came out, DHH often quoted Sierra and linked to her blog all the time. I had a habit of diving deeper into the stuff DHH talked about at the time — for instance, the fantastic book Code Generation In Action — and so I read Sierra's magnificent blog of that era avidly. Every word was genius.

And every word was the specific type of genius I talked about in my own book, many years later. All of the underappreciated "luxuries" of Rails development — Rake tasks, migrations, ActiveSupport, the design of ActiveRecord's API, and even scaffolding (which was briefly an awesome thing, in the very early days, when Rails was brand spanking new) — stem from Kathy Sierra's gospel of ease-of-use and user empowerment.

These techniques live on beyond Rails, in countless other frameworks and libraries, as a testament to their usefulness. They made developing Rails apps fun and exciting, and they made every Rails developer quicker, more fluid, and more capable than most had ever been in their lives. The result: staggering popularity, feverish excitement, and an overabundance of eager evangelists. (A few people would claim they'd been equally productive in Scheme or Smalltalk, but even they were still quite excited about Rails.)

Ms. Sierra's writing predicted that if you focus on making your users incredibly effective, and you focus on getting them from newbie status to productive status quickly and gracefully, you'll produce that popularity, that excitement, and those evangelists. And Mr. Hansson obviously read her work, because he blogged about how great it was. And Ms. Sierra's design philosophy did for Rails exactly what she said it would.

I noticed all this recently, because I was reading Kathy Sierra's new book. It's excellent, and it's the missing link in understanding Rails. I had somehow forgotten about this, and in the intervening years, I'd written a book of my own where I reduced all of Kathy Sierra's brilliant insights to a brief reference to Steve Jobs instead.

There's a word for that. It's called erasure.

Here's a simple example: the current issue of Future Music, a print magazine about making electronic music, features a woman named Emika. She has a degree in music tech and did sound design for two of the best manufacturers of music gear. The interviewer asks her if she feels it's unusual and non-traditional for her to be an electronic music producer, because she's a woman. In fact, one of the greatest pioneers of electronic music was a woman named Delia Derbyshire. But the modern producer's unaware of her historical predecessor, and so is the interviewer. And this is not unusual; the achievements of women often vanish beneath a sea of understatement and undeserved dismissal. Emika has plenty of contemporaries; the Future Music story doesn't mention them.

I did the same thing to Kathy Sierra. It's important to recognize that, at the time I did so, I would have called myself a feminist in general, and a fan of Ms. Sierra in particular. I had bought a bunch of her Head First books, and based my entire presentation style on them, to wild acclaim. But I not only failed to tell people where I got the style, I honestly forgot, and went on to write blog posts about my presentation style, and to sell a video explaining how it works (which, again, met with wild acclaim, and paid my bills for a while).

This is something which was hard for me to understand, and I think it's hard for a lot of other guys as well. It's not just that I'm guilty of a sexist revisionist history; I'm also guilty of a sexist forgetting. The guilt is accidental. But it's still guilt. What I did was not the right thing.

I probably got that understanding from a woman too, and I wish I could remember for sure.

Anyway, Ms. Sierra's new book is fantastic, and you should read it. And at some point, when I get the time, I hope to revise my own.