Why Hasn't Ruby Won?

Ruby

Sarah Mei

#programming-languages

#community-engagement

#developer-experience-dx

#diversity-inclusion

Why Hasn't Ruby Won?

by Sarah Mei

In her presentation at GoGaRuCo 2013, Sarah Mei explores the reasons why Ruby, despite its popularity among supporters, struggles to attract and retain new users. She opens with an insightful reflection on the discrepancy between dedicated Ruby conference attendees and the many who have tried Ruby and moved on, often sharing their grievances online. The talk aims to uncover social and non-technical influences impacting language adoption decisions over technical features alone.

Key Points:

- Ruby's Community Perception: Mei highlights a culture within both the Ruby community and external perceptions reflected in platforms like Hacker News, where Ruby is often criticized, and potential users are dismissed based on prior programming experiences with languages like PHP and Flash.
- Evaluating Languages and Gems: Mei discusses the process developers undergo when evaluating programming languages, which often draws upon subconscious expectations shaped by previous experiences. Her investigation into how developers assess Ruby gems reveals insights into how social factors more profoundly affect decision-making than technical merits.

- Factors Influencing Decisions: Mei introduces four categories that emerge from her findings regarding gem evaluation:

- Interface: The gem's external functionality.

- Activity: The activity level of the project, including how often it is updated and community responsiveness.

- Popularity: Consensus among other developers and ease of finding support or documentation.

- Familiarity: How similarities in coding practices influence preference, emphasizing that people lean toward code that feels familiar.
- Learning and Mastery in Programming: Further, Mei connects the concept of successful programming not just to time invested (the 10,000-hour rule) but rather to the diversity of programming experiences. She asserts that exposure to different coding environments accelerates learning and development far more than solely accumulating hours.
- Conclusions on Ruby's Future: Ultimately, Mei emphasizes that Ruby's ability to compete with languages like JavaScript hinges not just on technical capabilities but deeper social familiarity and collective team experiences. She asserts that bridging diverse programming backgrounds will be vital to Ruby's retention and growth. To this end, she encourages developers to explore other languages to enhance their coding intuition, thereby enriching their return to Ruby.

Ultimately, the takeaway is that, to revitalize Ruby's standing, a more inclusive and exploratory learning approach is essential, which can positively shape the language's community dynamics and user experience.

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.

GoGaRuCo 2013