00:00:20.240
Uh, we're in the home stretch here: last talk of the day. I met Sarah Mei at the first Golden Gate Ruby Conference, the one in the funky Swedish American Hall with the really uncomfortable chairs and thrones. Sarah's been at every GoGaRuCo since then. She's spoken at several of them and at a bunch of other places. It's been great watching her go from an inexperienced speaker to someone who consistently knocks it out of the park.
00:00:28.160
So, with that buildup, I give you Sarah Mei.
Sorry! Okay, I'm sorry, I forgot to say: hang out at the end. We're going to have a couple of party announcements and things like that to get you going for the rest of your evening when we're done, so don't run out the door right away. Thanks and good afternoon.
00:00:35.760
Let's see if this works. Oh, it does! Awesome! So, it's the end of the first day. How has the first day been? Yeah, I am impressed that you guys are still awake after all of that stuff going into your brains because I'm almost not awake.
00:00:44.320
I’m Sarah Mei. No pressure from Josh's introduction! This is my company, the Ministry of Velocity. We're a small consulting shop here in San Francisco. We just got going last month, actually. The logo's new and I'm very excited about it. I have shiny new business cards too, and I think I've already made several of you take one. We work on Rails, JavaScript, iOS, and assorted other things. We help you go fast – that's the idea. If you're looking for that kind of service, come find me and I will happily give you a business card.
00:01:13.240
And 'we' is not quite the royal 'we', because if you know me, you know I have to have a pair. It's been fun. I'm having a good time with it! The best part is I got to make up my own title: I am the Head of Propaganda at the Ministry of Velocity. I am also one of the founders of RailsBridge, which you may know from such programs as the RailsBridge workshops for women, which have taught Ruby and Rails to thousands of women in over 100 events. Thank you!
00:01:39.760
What you may not know about RailsBridge is that we're also starting an initiative to reach out to communities of color. We did a joint event with the Black Founders Group here in San Francisco a few months ago, and we're looking to do more of that type of thing while we continue to work on the gender gap. Anyone in the audience been a student at a RailsBridge workshop? Yay! Anyone been a teacher? Who's been both? All right, this is awesome!
00:02:02.800
All right, well I started this talk off with a question, and it's kind of an odd one, so let me explain a little bit of what I mean. Here, you all use Ruby every day, and you love it! I'm not even going to ask for a show of hands because I know you do – otherwise, you wouldn't be here. But for every one of you, there are a hundred people out there who have tried Ruby and discarded it. Most of them seem to post a lot on Hacker News.
00:02:45.920
Ever since Rails hit 1.0, basically, Ruby has been one of the favorite whipping boys of Hacker News. Witness just a few of the articles that have made it to the front page of Hacker News in the last few years. A bunch of the articles on this list are FUD – fear, uncertainty, and doubt about Ruby – and those are really popular! But even the ones that are neutral or positive about Ruby, especially the ones that are positive, attract really, really horrible comments about Ruby and what it’s good for.
00:03:05.280
Everyone knows not to read the comments on Hacker News, right? You never read the comments; they're a cesspool. I was going to get some screenshots of comments, but I felt too dirty just going in and looking around, and I needed to shower afterward. It’s not just folks in other communities that disparage Ruby; we in the Ruby community poke outward as well. We're constantly taking jabs at people who use other lesser languages.
00:03:21.920
We figure they must work somewhere like here, right? Like they do Java or Python or PHP. Oh my God. Those people… I'm certainly guilty of that myself. I mean, those poor people with their bizarre whitespace conventions, their onerous type checking, and their closed-source implementations! I want to save them. I want to save them with Ruby! Why can't we?
00:03:43.760
I have a friend who's been trying to switch from PHP to something that pays better. Of course, I've given her the pitch for Ruby, but it's been interesting to watch her thought process as she goes through this transformation of switching languages. I started wondering if there was something that we could learn from that process, because when you ask developers to evaluate languages, what often happens is they come into it with a bunch of subconscious expectations based on their current language.
00:04:01.440
I mean, when I switched to Ruby from Java, I wrote Ruby code that looked like Java code for pretty much the entire first month. I used for loops! Okay, that's how bad it was. But there are lots of other things beyond the actual code that people consider when they're evaluating a language. For example, no one starts projects in Smalltalk anymore. This is such an amazing picture; I love it. It’s not because Smalltalk isn’t wonderful to work with, right? It is! But just try posting a Smalltalk question on Stack Overflow and see how long it takes to get answered. Try hiring a senior Smalltalk developer? Good luck! They’re even harder to find than a senior Ruby developer. I've met one current Smalltalk developer in my life. Earlier this year at the Mountain West Ruby Conference in Salt Lake, he told me he was a full-time Smalltalk developer. That’s very impressive!
00:04:48.080
Then he told me that he uses his travel budget at work to come to a couple of Ruby conferences every year. And I said, 'Why don't you go to Smalltalk conferences?' And he said, 'Because there aren't any.' The number of people who use a given language and how active they are in public has a huge effect on people's decisions around languages. I wanted to understand better what the non-technical influences on people's decisions were because I had a hunch that these influenced people's decisions more heavily than the features or the performance or the other technical details of a language. Basically, I think people's decisions about programming languages are based largely on social factors and not on technical ones.
00:06:04.480
At this point, I had like a sample size of one: my PHP friend. So I figured that I could understand this better by looking at it at a smaller scale, where I could collect more data points. Because while I don't know a lot of people making the language decisions, I know lots of developers who make similar but smaller scale decisions all the time. Programming is constant technical decision-making, but it operates at different scales every day. When we're working on a project, we make hundreds of micro-decisions about where code will go and how to test it.
00:06:40.320
At a larger scale, and slightly less frequently, we make decisions about which gems to use. And at an even larger scale, and even less frequently, we make decisions about when it's time to switch frameworks. At the largest scale, and even less frequently, we make decisions about when to switch languages. While I don't know anyone who makes the language or framework trade-off regularly, I know lots of people who look at gems all the time. So, I started by asking a bunch of my colleagues to describe how they evaluate gems with similar functionality. It turns out everyone starts in basically the same place.
00:07:43.680
They look at the interface of the gem, the features, the functionality, and the usage of the code. This information is easy to find; it's usually in the README on GitHub. Let’s say that you are looking for a gem to make HTTP requests and a quick Google search turns up HTTP Party and Faraday. Assuming you don't immediately discard HTTP Party because you can't pronounce it, you look at the README for each project and skip to the usage.
00:08:10.360
This is what you find: HTTP Party has class methods that you can call directly, or it has a module that you can mix into your own class, while Faraday takes a different approach and gives you a connection object that you can then use to make calls. This information by itself is not enough for most people to make a decision, just like the features of a language aren't enough to tell you if it's worth using. Features of a gem aren't enough either. So I asked people to enumerate for me everything they do to evaluate a gem, and here’s what I got.
00:09:03.280
You ready for this? There's a lot. They look at the README on GitHub, the date of the last commit on GitHub, how many issues there are and how old they are, the comments on the issues and pull requests to see if the maintainer’s a jerk, the number of blog posts they can find when filtering on Google to the most recent year, Ruby Toolbox to figure out the relative download popularity, RubyGems to figure out their release schedule and how often they release, Stack Overflow to see how many questions there are and how many are unanswered.
00:09:11.919
They ask people they know from work, they ask Twitter, they visit Hacker News and Reddit. They ask other developers, look for official documentation, books, screen and podcasts. They evaluate the code directly - seems useful. They evaluate the tests. Sometimes they just try it, and sometimes they build a sample app to see what it does. This is a long list; I had to move the font on the slides way down to get these all to fit on one screen.
00:09:51.440
It’s not exhaustive; I could put more stuff on here. I want to point out a few interesting features of this list. The first is that different people rank these differently. I always poke around on GitHub first to establish that it has a reasonable interface and reasonable activity. The next thing I usually do is ask my coworkers for input. But one of the people I talk to works at a company where displaying ignorance is not good for his career, so he never asks his coworkers for input on anything. He basically pokes around on GitHub and then goes straight to the documentation and tutorials.
00:10:32.320
The second thing is that we rarely do all of these for a given evaluation. Maybe we do if we're evaluating Rails versus Sinatra, but if it's like HTTP Party versus Faraday, we probably don't do all of them. The last thing is that this list changes as our community changes. For example, before Rails, a lot of discussion about Ruby libraries took place on the official English-language Ruby mailing list. But today it wouldn't occur to any of us to post on that mailing list if we're trying to pick an HTTP gem.
00:11:15.200
The way that we collect and use this data is pretty complicated. We weight things differently at different times. Different people do different subsets of these things. Is there anything we can pull out of this? Most of this data is not technical; it's social. It's people data – information about the maintainers and the users of a project. There is some technical data; let's pull that out first.
00:12:14.240
Here's what everyone starts off with: they look directly at the features and functionality of the gem; not the internals but the external interface. We’ll put that stuff aside. Then there's information about the activity of a project: how often it’s updated, how likely am I to get help from the maintainer or get a pull request merged. We can pull these issues out over here and give ourselves a little more space.
00:12:59.360
And what’s left? We’ve got a big chunk all about the project’s popularity among other developers. Have any of my coworkers used it? How easy will it be to find help when I run into a problem? How likely is it that someone else has already fixed a bug by the time I encounter it? We’ll pull that stuff out over here. And we’re left with a couple of outliers: evaluating the code and evaluating the tests. They don’t really fit in with any of the groups we have so far.
00:13:38.720
Interface, activity, popularity – they're all pretty straightforward; there are well-known sources of data for this information. When you come into a community and you learn them once, then you’re good. But what we have left is a little fuzzier; it's really about how familiar things feel to you. Is this idiomatic Ruby? Does the maintainer share my test strategy? How much does this code match up with what I would write if I were going to roll my own?
00:14:30.560
How much does this code feel like other code I've seen? Let’s call this familiarity. So, that’s our last group. These are broadly speaking the four categories of data that we consider when we're evaluating a gem. Now, interestingly, only one of these is technical data: that's the interface. All the other three have a social component. Popularity and activity are almost purely social. Familiarity is partially a technical judgment because you’re looking through the internals of the code, and partially a social judgment because you’re looking through the insides of the code in order to find out how much the maintainer thinks like you do.
00:15:48.760
Certainly, by volume, we consider more social data than technical data. What happens pretty often in Ruby, actually, is that you have two gems that both have a sufficient interface. They both allow you to make GET requests and POST requests. They're about as popular; they're about as active. So judgment really comes down to this: does the code feel good?
Let’s talk about what that means. I want to come back to this example: familiarity is an intuitive judgment. But that doesn’t mean that we can't follow the thought process that someone uses when they're evaluating particular code.
00:16:49.280
If you recall, HTTP Party has class methods or a module you can mix in, whereas Faraday gives you a connection object. Here’s a thought process that one of my colleagues described to me when I asked him to walk me through the process he uses when evaluating this code. Now I’ve written it up as a conversation between me and my four-year-old son; I think you’ll see why in a minute.
00:17:47.840
I don’t like mixing helper methods into objects. Why? Well, sweetie, it’s a sign that there’s another object trying to get out. Why are you trying to design it this way? The Ruby way is to use objects. Why? So that my code is easier to test. Why? Testing is important!
00:18:18.640
This is a question we do not ask ourselves often enough, I think. In this case, the answer was: I have a team with mixed skill levels, and I need to have confidence in all of the code. And then this conversation ended pretty much the same way all conversations end in my house: can I have an otter pop? You guys know what otter pops are? They’re like little tubes of plastic with sugar water in them that you freeze. They’re kind of disgusting.
00:18:56.960
But this is Gabriel with an otter pop. So, this is not, obviously, a conversation we actually have with ourselves; it’s usually subconscious. This is why it has a variety of fuzzy labels. The way people describe it to me most often was pattern matching. This pattern matching is a difficult job for a computer, but a relatively easy job for a human brain – particularly a human brain belonging to a software developer.
00:19:44.240
You may be familiar with the concept of a neural net. It’s software that tries to replicate the learning process of a human brain. In very simplified terms, the way it works is that you construct in software a decision tree with algorithms at the branching points – that’s these question marks – and that determines which path it goes down for a given input.
00:20:33.760
Then you start feeding it training data, which adjusts the algorithms at the branch points and makes it more likely to correctly process similar inputs. As matching power gets greater, the more inputs you give it, it appears to learn. It turns out this is a decent approximation of how our human brains learn to match patterns as well. The more inputs you give it, the better its matching ability. Or in other words, if you want to develop a sense of familiarity, you'll get better at it the more code you read and the more code you write.
00:21:12.960
Now that's an idea we actually talk about all the time. Most of you are probably familiar with the 10,000 hours idea, right? I've lost count of the number of people who have told me, as if it's a fact, that you must spend 10,000 hours programming in order to get really good at it. Basically, what they’re saying is our brains need 10,000 hours of training data to reach mastery.
00:21:54.480
More generally, this means the only way to master programming is to wait for it to happen. This idea is originally from Malcolm Gladwell's book 'Outliers' and has taken pretty deep root in our community. We talk about this all the time, even though we all know some counterexamples. We all know a few people who seem to have skipped ahead in line. We've all had a coworker with three years of experience who made better decisions than someone with ten years of experience.
00:22:40.480
We all know from our everyday lives that quality does not directly correlate with how long someone has been a developer. And that's where we tell ourselves a myth: the myth of the 10x programmer. You folks know this one too, right? This is the idea that Joel Spolsky wrote about in 2005, stating that there's a small number of super developers who are ten times more productive than the mass of average developers. Another way to state this is that if you look at the 10,000 hours to mastery idea as a long-term learning curve, it is, of course, a long-term learning curve.
00:23:24.240
There are some people who go up it faster, and there are some who seem to stall. The people who reach mastery more quickly are the ones we see as the 10x programmers. Now, I called it the myth of the 10x programmer, but like most myths, part of it is true.
00:24:00.480
There are huge differences in programmer productivity; that's got solid research to back it up going back 50 years. I’ve seen it in the wild; you have too, I’m sure. We’ve all seen someone who was way out of our league. But when I hear people talking about this 10x concept, there's usually another dimension to it. They say that 10x programmers have a gift that some people, no matter how hard they try, can never acquire. And that is actually not supported by the research. It’s not proven or disproven; it just isn’t addressed.
00:24:57.080
As far as I can tell, no one has done the study I wanted to read: taking people who measure average on their productivity scale and trying to get them up to the level of their 10x peers to see if it’s possible. Both of these ideas, the 10,000 hours and the 10x programmer, are unsatisfying to me. They feel like two blind men feeling along an elephant's body, trying to figure out what the elephant is like.
00:25:41.040
One runs his hands over the elephant’s leg and says, 'An elephant is like a pillar.' The other feels the elephant’s tusk and says, 'An elephant is like a solid pipe.' They’re both right. An elephant is both of those things, but it’s also way more than either of them. These ideas are true in their own way, but they are also vast oversimplifications of a process that deserves nuance and deeper understanding. Malcolm Gladwell is right; he's feeling the leg of the elephant and he sees a learning curve that leads to mastery that is not easy to surmount.
00:26:37.040
But he's drawing about the fact that his progression is purely time-based. And Joel Spolsky is right; he's feeling the tusk and he sees that people move up the curve faster, outpacing their peers. But he’s wrong in the notion that it comes from a gift that their peers cannot acquire. My theory is that you can accelerate yourself up that curve. There are natural variations in cognitive abilities, but they are not significant enough to explain the enormous productivity differences among programmers.
00:27:32.640
Just like the natural variations in cognitive abilities between men and women are not enough to explain the gender disparity that we see in our community. So why do I think that you can accelerate yourself up that curve? I’ll tell you a story and then I’ll drop some science. At this point in my career, I’ve worked with hundreds of developers. Most of them I’ve pair programmed with, and pair programming gives you an unusual glimpse into another person's decision-making process.
00:28:21.120
When you pair with someone, in less than a day you get really good sense of where they lie on the skill spectrum. And when I think through all the people I’ve worked with and paired with, who either outperform everyone else on their team or were obviously on a fast upward trajectory, there’s one common thread that stood out: they all, without exception, made a concerted effort to read, write, and understand lots of different types of code.
00:29:16.080
They did Rails, they’d spend their time studying the internals of gems they used, RSpec; they would study code tested in MiniTest or TestUnit; they’d write some themselves. If they did Ruby and they were on a JavaScript app, they’d throw themselves into learning idiomatic JavaScript. Sometimes they were in linear languages, you know, impractical ones, just to see how other people did things.
00:29:58.000
Most of this happened within work time – you know, a few minutes of digression here and there, poking a little deeper into the code and the framework and the language than most people go. And now for the science! There’s lots of great research around how people learn things. One of the most interesting studies published in 2006 talks about the effect of novel information in learning.
00:30:50.720
They gave people a set of images to study for a fixed period of time, and then later they asked them questions about the details of the images. They found that people whose images included a mix of ones they’d seen before and ones they had never seen were significantly better at recall than people who just looked at images they had seen before. They weren’t just better at remembering the novel images; they were better at remembering all of them, both in the short term and the long term.
00:31:40.920
Then it gets even more interesting because they conducted some MRI studies to figure out why this happens. They discovered that when we encounter a piece of novel information, our brain – the midbrain – responds by releasing dopamine. Dopamine is a neurotransmitter that accelerates learning in ways that we don't fully understand at the moment.
00:32:32.960
But the practical effect is that when you’re learning, mixing bits of new information into what you’re studying means that for a given unit in time, you learn more than you would otherwise. That lines up with my experience. The best programmers I’ve ever worked with don’t maximize the number of hours they spend programming; they maximize the variety of code that they work in; and that accelerates them up the curve to mastery faster.
00:33:06.720
To summarize, Malcolm Gladwell and Joel Spolsky are both right, and they’re both wrong. Our journey up the curve to mastery is more complex than either of their ideas admit, and you can hack it. So I want to bring this back to languages. Our investigation of the decision process behind gems gave us the categories of data that we collect and analyze when we’re choosing among gems. Let’s try to apply this to languages.
00:34:00.480
I decided to do a thought experiment with an example that I think a lot of us are navigating at the moment: the decision between Ruby and JavaScript on the server side. Let’s see what we can do here. Let’s start with the interface. With gems, this is the external interfacing capabilities. With languages, this is also the external interfacing capabilities. This is where we talk about things like garbage collection and threading models.
00:35:15.120
This actually is what most Node versus Rails posts focus on: Rails builds you a blog, Node builds you a chat server. But real projects are almost never that clean cut; they often include enough standard request-response stuff to merit looking at Rails and enough real-time update functionality to merit looking at Node.
00:36:32.720
But people use – and in fact, they usually focus on this category of information when they’re comparing languages. Activity, though, is also very important. Node, Rails, JavaScript, and Ruby are all very active projects. In this category, you sometimes get people reacting positively or negatively to the personalities involved in a project.
00:37:27.360
At this level, this category includes: how does the leadership respond to criticism? Popularity is also important; Ruby and Rails being older projects probably have the advantage here over Node. Certainly, on the Node side, you roll out your own code for things you could do with a gem in Ruby.
00:38:41.040
And finally, familiarity. Now this was the most complicated one when we were looking at gems, and it’s the most complicated one here too at the language level. It means: how much will my internalized assumptions from my current set of languages match up with the expectations in this new one? I think when you’re coming from Ruby and you’re looking at JavaScript, they don’t align that well.
00:39:52.920
In Ruby, we're used to thinking of software structure as being oriented around classes and objects, but JavaScript doesn’t exactly have classes; it has prototypes. That seemingly minor difference leads to a different structure in large systems than we’re used to seeing on our side. There are lots of projects that are trying to bridge this gap, right? CoffeeScript, for example, pretty much lets you import your class-based structure assumptions wholesale and apply them to JavaScript.
00:40:40.840
I tend not to recommend it because I think people should learn prototypes first. I think JavaScript applications should be structured differently than Ruby applications. And that’s great, in an ideal world where there won’t be any real live people writing your software. But sometimes you don’t have the time or the expertise to convert a team of Ruby developers into idiomatic JavaScript developers.
00:41:09.760
Because while, for gems, familiarity is usually the function of one person's brain, at the scale of languages, familiarity is the function of all the people who are going to be working with it on this project, right? Your familiarity with JavaScript might be fantastic, but what about everyone else on your team? As a result, the capabilities and interests of your team are ultimately the strongest driver of language decisions, usually even more than the task you’re trying to complete.
00:41:52.800
It turns out that software is really just people. We can't save them. This will never happen! It’s not because Ruby is slow; it’s not because Ruby’s main contributors don’t speak English; and it’s not because the most famous Ruby developer in the world spends most of his time racing cars. Ruby can’t win because language choices hinge on familiarity, and everyone who walks in Ruby’s door has given their brain a different set of training data than you gave yours.
00:42:38.480
So, not everyone is going to be a match. This is a game where there is no winning, but there is losing. There is definitely losing. Ruby could wither into a niche language like Smalltalk. None of us want that! But remember my theory: my theory is that the learning curve that leads to mastery can be hacked, and that there are things you can do that accelerate you up. I found one of them; I’m sure there are others!
00:43:24.040
If we figure out what they are, we'll be an unstoppable force. But in the meantime, given the dramatic effect that novel information has on your brain, the best thing you can do for Ruby is to go learn something else. Then come back, and I will save you an otter pop. Thank you very much!
00:44:12.080
You.
