00:00:10
Before we get started, I thought it might actually be quite nice to get to know you a little bit. I realized this is just after lunch, and everyone's feeling a bit sleepy and full of food. So if you have been programming in Rails, either professionally or otherwise, in 2018, can you please raise your hand? Okay, good! If you were a pro, keep your hands up.
00:00:29
Come on, this is an exercise! If you were programming in Rails in 2017, keep your hand raised. Otherwise, put your hand down. 2016? 2015? A lot of people have been programming in Rails for a few years now. 2014? 2013? 2012? 2011? 2010? 2009? 2008? 2007? 2006? 2005?
00:00:49
Is there two of us from 2000 and 2004? The very first release? Okay, that is amazing! You should come and give this talk! Let's give a round of applause for the old-timers. I feel so young. I was going to go down to 2003 and say you're either a “hat” or a liar, but I'm glad everyone was honest.
00:01:10
Okay, let's get started; we can take the lights down now, thanks. My name is James Adam, and I have been using Rails for a long time. I'd like to share with you some of my personal history with Rails. Hopefully, it won't be too self-indulgent, and hopefully, I won't bore you before we get to the important bit at the end.
00:01:36
I also want to apologize; apparently, every time I come to America now, I get a cold. So if I cough or sneeze or anything, please don't think I'm gross. Anyway, let's get started. So the room is nice and dark, and we need to sit back and relax as comfortably as you can. You can feel your limbs and eyeballs getting heavy, all your worries drifting away.
00:01:57
I'm going to gently regress you all the way back to 2005. This is me in 2005. I was just finishing a PhD. I'd actually discovered Ruby a few years earlier and had totally fallen in love with it. I rewrote almost all of the code that I was using to do my research in Ruby. I was so excited about Ruby when I first discovered it that I sent this in an email to my friends who had all gone into proper jobs when they left university, writing software, most of them using Java at the time.
00:02:19
Now, the nature of PhDs is that when you finish, you become a deep expert in a field that's so narrow that it can be really hard to figure out how to connect it to anything else, to anything in the real world. I was worried in 2005 that I was going to be in a similar state professionally, because I had fallen in love with Ruby, but you can't always get a job doing something that you love, and I was really worried that I would have to go back to Java or C++ to make some money.
00:02:54
But I was incredibly lucky because just as I was finishing my PhD, this excited Danish guy started talking about a web framework he was writing with the weird name Ruby on Rails. I should mention now that I'm going to show a lot of blog posts; you don't have to read them all. I'm going to highlight all the interesting bits, so don't try and read everything I show.
00:03:10
So, a long story short, a job in London got posted to the Ruby mailing list, and I took the seven-hour train journey down from Scotland to London for an interview. Then, a few months later, I was working in my first job using Ruby, being paid to use Ruby and a very early version of Rails. I think it was 0.9 at the time, which is maybe a couple of point releases after.
00:03:43
Our team was like a mini agency inside of a much bigger media company. The company used a tangled mess of Excel spreadsheets to run their business in multiple departments using all kinds of crazy stuff inside those spreadsheets. It was our job to build nice clean web applications to replace some of those spreadsheets. At least we were a small team, never more than four or five developers, but we'd work in a whole range of applications often at the same time.
00:04:06
Now, these days, Rails, particularly with Rails 5.2, which had just been released a few days ago, gives you everything you might need to build a web application. But it's easy to forget a time when Rails had almost none of the features that we take for granted now. A time before Active Storage, a time before encrypted secrets, before Action Cable, before Turbo Links, or the Asset Pipeline, before Resource REST, or even before Rack.
00:04:32
These are the headline features of Rails 0.13 in spring 2005. Migrations were brand new; can you even imagine a version of Rails without migrations? In lots of ways, Rails 0.13 is similar to modern Rails. It has all the kind of MVC things that you'd expect: models with associations and controllers with actions, and view templates and Action Mailer.
00:05:06
But in other ways, it's actually more similar to Sinatra than to the Rails that we have today. For example, if you install Rails 0.3 with all the gems it needs, in total, you have about 45 thousand lines of code. But if today you add Sinatra and Active Record and nothing else to a Gemfile and install that, you end up with over a hundred thousand lines of code.
00:05:29
So Rails 0.13 is like less than half of Sinatra plus an ORM. But the core philosophy of Rails then is exactly the same as it is now: convention over configuration, using the expressiveness of Ruby to try and make web development fun and providing most things that most people need to build a web application.
00:05:57
So, it's summer 2005, Rails is at 0.13, and in our team we’re building all these applications, and we realize that we’re building the same basic features again and again. Specifically, things like code to manage authentication, controlling who can access your application and authorizations, controlling which of those users have access to things like an admin dashboard and stuff like that.
00:06:35
I think we had at least four applications under development at the same time, which is around about one per developer, so it just seemed counterproductive that each of us would be building the same feature slightly differently for no good reason, possibly introducing our own little bugs that would differ in every application and generally making it harder for us to collaborate on these applications or move around if someone was away.
00:06:54
After all, a big part of the Rails philosophy was and is DRY: Don’t Repeat Yourself. All these authentication and authorization features weren’t particularly complicated or interesting; they had the same stuff you might expect today: logging in with an email, logging out, something about forgetting a password, a user model, and a table in the database to support that, and maybe some mailer templates to handle user lifecycle.
00:07:23
So it occurred to us that what we really needed to do was to write this once and then have a way of sharing it between all the applications we were writing so that we could all benefit from bug fixes and new features and be able to rotate around these applications in our team more easily.
00:07:45
In modern Rails, we typically share code between applications by using a gem with a railtie. A railtie is just a way of configuring how you hook into Rails initialization. Now, these weren’t added to Rails until 2009, so they don’t exist yet in 2005. Before railties, we had plugins, but they didn’t appear until Rails 0.14; we were on 0.13, so those don’t exist either.
00:08:09
Even using regular Ruby gems, which did exist in 2005, was problematic because we didn’t have Bundler. We didn’t have a way to lock down gems to individual applications, so it was fairly typical that you would deploy multiple Rails applications to the same machine, but if you upgraded the gems in one it would upgrade the system gems and that might end up breaking your other application.
00:08:31
Rails did add some rake tasks, I think for freezing gems, which is like a precursor to Bundler, but those didn’t appear until Rails 0.14 as well, so we couldn’t use that. So without any existing mechanism, we had to roll up our sleeves and invent something ourselves.
00:08:58
In the late summer of 2005, we extracted all the login and authorization code, including controllers, models, views, and so on, into a separate repository and then wrote a one-file patch library which, when Rails loaded, made sure that our controllers and models were in the load paths for Rails and then made a few monkey patches to Rails' internals to make the rest of the stuff work like you would expect.
00:09:29
Originally, this patch was called frameworks, but pretty soon after it got renamed to engines. The name engines was actually the idea of Shawn, who happened to be my boss at the time and had been programming in Ruby probably longer than either of us.
00:09:43
So that was summer of 2005. In October of 2005, a few months later, Jamis Buck added an experimental plugins feature to Rails. Now, a plugin is just a folder of code that contains a lib directory and a file called init.rb, and the Rails plugin mechanism at this time just iterated through a series of folders in vendor/plugins looking for init.rb files.
00:10:01
It then loaded them and did whatever was in them. You could do anything, and we spotted this feature being added to Rails. I emailed Jamis and DHH to say, 'Hey, we’ve been working on something similar. We’d be very happy to contribute.' We got a very nice reply, the gist of which was: 'That sounds interesting! Why don’t you package that up as a plugin, and then we’ll see how people use it?'
00:10:22
So that is exactly what we did, resulting in the engines plugin, which let you treat other plugins as these kind of MVC slices that could be shared between applications. This is the very first homepage for the engines plugin that was hosted on RubyForge. I also released the first engine, the login engine, which was super simple; it just wrapped up code from one of the existing authentication generators that we had used in our applications, along with a few other tweaks that we found useful.
00:10:53
This was on November 1st, 2005, and people got pretty excited—like, kind of super excited—which was really exciting for me as the person who was proposing this idea. There was enthusiasm for the demonstration login engine that we released, and it seemed that people understood the idea behind what we were doing. Somebody even tried to turn Typo, which was the first really popular Rails blogging platform, into an engine so that people could have blogs for their applications.
00:11:19
People got specifically very enthusiastic about never having to write their own login code again, and I think some people thought that they would never ever have to do that, that these engines were going to just solve this problem for them forever.
00:11:43
Well then, somebody got so excited that they started talking about engines within engines, depending on other engines, and I think it was this idea that ultimately pushed DHH over the edge. About ten days later, he wrote the first blog post about engines on the official Rails blog.
00:12:01
Now, in the post, David talked about his distrust of the dream of component-based development and that it is better to build your own business logic than to try to adapt something that someone else wrote. He stated that we shouldn't expect to be able to plug in or swap out these high-level components like forums or galleries and never have to build them ourselves. I agreed with him but tried to clarify that what engines were good for was taking some code that you've written and sharing it around a bunch of applications that you are writing.
00:12:30
As long as those features are relatively isolated from the rest of the application, I think David agreed with that. I could see his perspective: when you're working on a single application, like, say, Basecamp, then you probably can and should develop as much of the business logic as you can for yourself so that you can provide the best experience to your users.
00:12:54
But if you're working on three, five, or ten different applications at the same time, then chances are that the balance of value versus the cost of sharing might tip the other way. I was pretty happy with that conversation; it seemed like we generally understood and agreed with each other about the benefits and dangers of what I was proposing. I'd shared an idea, and David had just expressed a bit of caution.
00:13:18
But a bunch of people had become super excited by it, and maybe a little bit too excited. A lot of people on the other side took David’s post as a declaration that the idea was fundamentally to be avoided at all costs. That’s basically how things played out for the next three years. Every now and again, somebody would write a blog post saying, 'Maybe Rails needs something like engines,' or 'Engines aren't that bad,' only to be met with replies like, 'Oh, didn't you know that engines are too much software?'—whatever that means—and are really bad.
00:13:45
Then I would write a comment saying, 'I think it's a bit more complicated than that,' and then maybe the author would add some clarification to their post, but by that point, it was too late, and you've got people commenting that Rails engines are actually evil. This is all real—this is all real! I call this time the wilderness years.
00:14:12
During this time, I tried to respond to criticisms of the engines concept with varying degrees of success. It was occasionally quite frustrating. I spoke at a bunch of conferences about plugins and sometimes engines, and I also tried to gently steer the development of the plugins mechanism in Rails to make it easier to do the things that engines needed to do.
00:14:31
That included adding things like controlling plugin loading order, giving plugins more structured access to Rails initialization and configuration, and stuff like that. Plugins became very popular and went from originally being shared as links on a wiki page to having their own directory where you could search for different plugins to help you with the application you were building.
00:14:50
You could leave comments on plugins and so on. There's an example of a fun plugin I wrote for one of those presentations. You can see that even though maybe I’m frustrated inside, I’m actually having fun. When I did mention engines in presentations, I tried to always mention that there were valid use cases, but yes, you could get yourself in a mess.
00:15:07
But that doesn’t mean that people should never ever use them. I’d hoped that speaking at those conferences and writing those blog posts would, if not convince people totally to what I believed, at least soften them to the idea that engines weren’t a hundred percent evil.
00:15:30
But then on the official plugin directory, you’d get someone tagging the engines plugin as 'bad,' and the cycle would start again. I still don’t know who did that, but maybe we’ll find out one day.
00:15:53
So some people would go to great lengths to explain why Rails engines were bad. As an aside, there’s a thing called 'better age's love headlines,' which says any headline that ends in a question mark can be answered with the word 'no.' But I’d write a short comment to try and respond to each of their points and hopefully clear up any misconceptions about what the engines plugin was and what engines were good for.
00:16:10
In this particular case, though, what was super confusing is that the same people then released their own plugins to try and do basically the same thing as engines. I never really understood why that happened.
00:16:22
The wilderness years lasted long enough that some companies actually wrote plugins like engines themselves, not realizing that engines had ever existed. So I had a conversation with Brian, and we agreed that we should probably try and coordinate our efforts instead of both having to fight this battle.
00:16:38
All this was happening between 2006 and 2008, during which a new Ruby web framework called Merb appeared. It was designed to be extremely fast, largely because they didn’t do very much, and be particularly good at handling many simultaneous requests and things like file uploads. Unlike Rails, which at the time was a relatively tightly coupled set of web frameworks, Merb was designed to be extremely modular, and it could for example support multiple ORMs.
00:17:05
It was also designed to have clear and stable internal APIs, as much of the Merb framework was written as optional plugins that you could load or not load, depending on what you needed. One of the developers most involved in Merb was Yehuda Katz, who eagle-eyed people will have spotted as generally sympathetic to the concept of engines.
00:17:32
So it’s probably not surprising that in 2008, Merb introduced their own implementation of the idea called Merb slices, to a generally positive response from the Ruby and Merb communities. But it’s not a huge surprise to me that this is how the most popular Rails podcast at the time chose to frame that—like, 'Rails engines but it doesn’t suck!'
00:17:47
I don’t blame the presenters for thinking or saying that; it’s just a representation of the opinion of the Rails community as a whole at that time. This is a painting of Sisyphus, who in Greek mythology was cursed by the gods to be forced to roll an immense boulder up a hill, only for it to roll down when it nears the top, repeating this action for eternity.
00:18:21
These days, it’s a common image invoked to describe tasks that are both laborious and futile. So, we come to the end of 2008. Rails is about to reach version 2.3, and the controversy has largely died down. People who found engines useful were just getting on with it.
00:18:36
I hope they were happy, and the people who thought engines were evil seemed to have forgotten that we existed. So you can imagine my surprise when I received this email from DHH with the subject line, 'I repent.' I think I actually became giddy after receiving this email. I may have laughed maniacally.
00:19:42
They could provide controllers, views, and most other types of code, and this was released as Rails 2.3 in March 2009. At the same time, Merb and Rails decided to merge, and Rails 3 would be the result.
00:20:10
The goal of doing this in part was to establish some clear and stable APIs within Rails, so that other libraries and plugins could rely on them and they wouldn’t break every time Rails was upgraded.
00:20:35
This was a fairly significant rewrite of a lot of the core parts of Rails in order to create those APIs. Yehuda and Carlos did much of the work, and as part of it, they decided that rather than having a Rails application and then these engine things inside of it that looked like Rails applications and had access to the same hooks and configuration and so on.
00:20:56
Instead, the outer application itself should just be a Rails engine with a few other bells and whistles to make it work. So, I guess the engines inside of engines person actually got their wish after all. This was released as Rails 3.0 in 2010.
00:21:24
Finally, with Rails 3.1 in August 2011, the last two bits of work that the engines plugin did—managing migrations and assets—got merged into Rails, and the plugin I had written was officially deprecated. My work really was done at that point.
00:21:45
So you’ve probably heard of the Gartner hype cycle, which is a way of understanding how technology trends evolve. You have the initial creation or discovery of the technology, and then the peak of inflated expectations where everyone is super excited about it, imagining having jetpacks or living on the moon or something.
00:22:07
Then you enter the trough of disillusionment when it turns out it’s actually much harder to build a jetpack than we thought, and there’s a bunch of things that aren’t ready before we can start building it.
00:22:32
Then you start to climb the slope of enlightenment as we figure out all those problems and understand how you can build a jetpack without setting your legs on fire. Finally, you reach the plateau of productivity where everyone is zipping around in their jetpacks.
00:22:56
We look back at old movies of people moving around using their legs and laughing. I think we can use a similar cycle to understand how the Rails community reacted to the engines concept. So for engines, it took just under six years from idea to acceptance.
00:23:17
We have the same starting point and the same peak of inflated expectations, like ‘I’ll never need to write login code again!’ But then, if you just give me a second, I just need to adjust the axis here, we enter what I like to call the trough of received opinions.
00:23:42
Some big names in the community have been like, 'Whoa, whoa, whoa!' and personally, we've never used the technology, but we’ve heard that it’s bad, so basically it’s the worst thing ever. For about three years, we scrabbled up this slope of fear, uncertainty, and doubt, where quietly, some of us are like, 'Hang on! I actually would quite like to share some of this functionality between the apps I’m writing!'
00:24:03
But then you try and figure out how, and you discover some old blog posts that say it’s evil, so you just give up. Finally, we reach the plateau of 'Are those still a thing?' As you can see, at the end of the cycle, we end up basically where we were.
00:24:30
But at the very least, I can finally put the boulder down and stop pushing it up a hill. So that took about 22 minutes. If you’d like a nice summary, I found this quote in the Rails 3 in Action book: 'There was a lot of controversy surrounding engines, and James spent a lot of his time defending the decision to develop them.' Since then, however, the community has grown to accept the idea.
00:24:50
So what changed in 2008? Well, I actually only realized this as I was writing this talk, but it’s quite simple in retrospect. Rails was originally extracted from Basecamp, the software that DHH built and still works on today.
00:25:11
At the start of Rails' life, Basecamp was the only Rails application that David worked on. But between 2005 and 2008, 37signals added another three flagship applications along with a couple of other small ones, and their small team— I think it was four developers at that point— had to build and support these applications all at the same time.
00:25:34
That sounds kind of familiar, doesn't it? Really. So that was just my theory. Amazing! That’s time. I might need to go into therapy to fully process that — but I’ll keep going for now.
00:26:02
So in the Rails doctrine, which is a somewhat provocatively titled document that David wrote about two years ago, there’s a section called 'Provide Sharp Knives,' and what that means is that with some of the tools that Rails gives you, it’s definitely possible to get into a mess.
00:26:22
But instead of protecting you from misusing them by withholding them altogether, Rails says that you should trust yourself to use them in an appropriate way. Concerns are one example of this sharp knife. If you’ve ever used a read about concerns, some people think that it encourages sweeping complexity under the rug, while others think that, if used appropriately, that’s not a big problem and the benefits outweigh the costs.
00:26:43
That’s exactly what the engines concept is: it’s just a sharp knife. For around six years, it was a little bit too sharp to be kept in the Rails silverware drawer, but now it seems like perhaps we can be trusted with it. These days, a lot of popular libraries are engines.
00:27:12
You’ve probably all used or heard of Devise, which is an authentication engine. The Spree e-commerce platform is distributed as an engine. You can get content management systems like Refinery CMS, which is an engine. Even the new Active Storage feature in Rails 5.2 is implemented as an engine.
00:27:31
So that’s the end of our trip back to 2005. We’re now back in the present with Active Storage. This is a good moment to take a stretch if you need it, but before we start the third act, I wanted to mention one thing that has nothing to do with Rails or engines.
00:27:50
Most of what I've talked about happened at least 10 years ago, and as you can tell, I have some feelings about it. When I was writing, I wanted to make sure that I hadn't inadvertently distorted any of what happened. I wanted to find the actual articles and things and all of the comments and posts that you've seen are real—they're exactly as they were.
00:28:18
But when I tried to find all the original newsgroup posts and articles and blogs and so on, what I found is that almost all of the sites that I’ve referenced are either totally gone or only partially available.
00:28:42
The comments on the Rails blog are gone, Loud Thinking is gone, Ruby Forge is gone, and the Rails Engine site is definitely gone, because I'm not paying for that anymore. I think that history is interesting and important; it's kind of mind-boggling to me that information that’s only ten years old might, without Archive.org, just be lost forever.
00:29:00
I think that’s insane, especially in the Information Age. How can that possibly be? If you can, please support Archive.org; they accept donations on their website, and I genuinely believe that they’re providing one of the most valuable services on the web today.
00:29:23
Okay, back to Rails. So at the start of this talk, I did say that I didn’t want this to be too self-indulgent. I don’t want to paint myself as some kind of misunderstood genius or a hero who’s finally proven right, and I’m sure that there are many other stories like this one in many other open-source communities.
00:29:56
What I think is interesting about this journey is that it shows that the history of Rails can be viewed as a history of opinions. Rails is opinionated software, which is great because it saves us a lot of time by allowing us to offload a lot of decisions about building software in exchange for some implicit constraints.
00:30:11
Following those constraints is what we sometimes call the Rails way. Some of those opinions are about how we use Ruby as a programming language, about how you should express behavior at the level of a single line of code. An example of this is the methods that Rails adds to objects like string or array.
00:30:26
In Rails applications, objects tend to have a lot of methods, and some people believe that it’s better to minimize the number of methods on an object, but Rails’ opinion is that the trade-off is worth it in order to be more expressive.
00:30:42
There’s nothing wrong or evil about either of those positions; they’re just two different opinions. Our opinions are at a more architectural level and are ultimately about how we ought to structure the applications that we’re building with Rails.
00:31:03
An example of this is if you build your URLs and controllers in terms of REST and resources, then you’ll be able to use a lot more of the abstraction and high-level mechanisms that Rails provides. But if you like to add a lot of custom actions to your controllers, then Rails can’t stop you, and it won’t stop you, but you’ll have to do a lot more work yourself to wire these things up.
00:31:23
That’s not the same as saying that if you don’t use resources, then your code is bad. It’s just a guiding opinion that Rails has. What might not be obvious is that over the fourteen years of Rails’ life so far, those opinions have not always existed and they have not always stayed the same.
00:31:52
REST-based architectures weren’t a part of Rails for two years. Inline JavaScript was fine until 2011, when Rails decided to use unobtrusive JavaScript instead. If you wanted to send an email when a user signed up, up until Rails 4.0, you probably would have written an observer and used that to decouple user creation and everything that that’s about from email concerns.
00:32:16
But they were removed in Rails 4, and so in modern Rails, you probably handle that by writing a concern which mixes in a callback directly to your user model.
00:32:42
I think a particularly interesting example is Active Resource. It used to be a part of the Rails framework; it was an evolution of the Action Web Service framework, which supported SOAP and XML RPC, and all the acronyms that David's mentioned as WS Deathstar in his keynote yesterday.
00:33:01
Active Resource lets you load and save remote data using JSON over HTTP, using the same Ruby methods that you’d use if you were interacting with an Active Record instance. It made it easy to build things like microservices, and I think it acted as a signal that you could and should do that.
00:33:20
But it was removed in Rails 4, which might be one of the first indications of the current opinion that the majestic monolith is a more productive way to work overall.
00:33:51
The purpose of highlighting these changes of opinion is not to say that DHH or anyone who was or is in Rails core is frequently wrong. It is to show that even in the world of opinionated software, opinions can change fundamentally. What is and isn’t in Rails is driven by the needs of the people who write it.
00:34:19
To a greater or lesser extent, that means people building applications like Basecamp, but not everyone is building an application like that. I think more and more of us are working on Rails applications that have been around for a long time, in some cases more than ten years now, and those kinds of applications have different needs and experience different pressures than one where the developer controls all the requirements and is free to rewrite it if they wish at any time.
00:34:47
According to BuiltWith.com, there are almost 1.1 million sites using Rails right now. It’s statistically extremely unlikely that Basecamp, as a piece of software or as a company, sits at the exact center of all those different needs, pressures, and trade-offs that those other applications and companies might have.
00:35:08
Right now, there are differing opinions in the community about what the future of Rails might include: the majestic monolith versus microservices; concerns versus smaller object composition; system tests versus unit testing and stubbing.
00:35:31
These explorations and tensions are good because we need people to be pushing the boundaries of the Rails way to figure out what's next. If we all just sit back and wait for a relatively small group of people to tell us what the future of Rails looks like, then that future will only be suitable for their particular, unavoidably limited contexts.
00:35:54
In 2014, 37signals changed their name to Basecamp and returned to maintaining a single application, so some of the motivation within Rails core for things like engines is naturally going to diminish, and that’s understandable—it’s a niche that they no longer have.
00:36:13
But I wonder how many other software issues there are which Basecamp doesn’t experience but hundreds or thousands of other application developers do. I think we need more voices sharing their experiences, good and bad, with the current Rails way.
00:36:34
We need people to build things like Trailblazer, ROM, Hanami, and DRI-RB, and we need others to try using them and learning from them. Probably, none of these projects are ever going to usurp Rails, but they might contain ideas about how to build software or how to structure web frameworks that are new and useful.
00:36:56
Like Merb, they might end up influencing Rails toward something that could be better for all of us. They might already have found some conceptual compression, to use a phrase from yesterday, that we can either adopt or adapt for ourselves.
00:37:16
There is no reason why the people doing that exploration can't be you, because no one else is going to do it. You are the Rails community; you are the people using Rails all the time. Who better than you to spot these situations where a new technique or approach might help?
00:37:39
Who better than you to try and distill that experience into some beautiful, expressive Ruby code that captures a common need? You can be the crazy ones—the misfits, the rebels, the troublemakers, the round pegs in square holes, the ones who see things differently.
00:38:01
As it says at the bottom of the Rails doctrine, we need disagreement. We need dialects. We need diversity of thought and people. It’s in this melting pot of ideas we’ll get the best commons for all to share—lots of people chipping in their two cents in code or considered argument.
00:38:25
Okay. Wonderful! Rails now embraces all manner of opinions under its big tent. But what happens when you have your idea, but people don’t quite understand it immediately, and things get a little bit out of control, and suddenly people are decrying it as evil?
00:38:51
Well, I feel for you, genuinely, because when I was working on engines, the main way people expressed this kind of opinion was in the comment form of a blog. But these days, we live in the age of the tweet, where many people don’t think twice about unleashing a 280-character salvo of hot takes out into the world.
00:39:16
I’m not sure that we live in the age of considered argument anymore. So what can we do? Well, two things: firstly, as consumers of open-source technology, I think we could all try our best to avoid sharing opinions like that. If you’ve had a bad experience with a technology or a technique, then that is totally valid, and you can and absolutely should share that experience.
00:39:36
But just don’t do it in a tweet, or if you must do it in a tweet, at least try to be a little bit balanced or, even better than that, start a blog or write on Medium or anything and write as much as you can about your experience and your context.
00:39:56
Then share a link to that on Twitter. Where was I? Yeah, this talk sucks! But if you really hated it, don’t tweet about it; write your blog post and then post about that on Twitter.
00:40:12
Secondly, if you are lucky and generous enough to actually try to contribute a new idea to either this or any community, try not to become demotivated if people don’t necessarily understand the point at first.
00:40:40
So this is that first blog post about Rails that I showed at the start of the talk on the 37signals blog in early 2004. I have not edited this. Let’s look at the very first comment: 'Why use Ruby when you could probably have developed this thing in less time with PHP? Is it just some desire to be different than everyone else?'
00:41:06
I think what this shows is that the value of why you’re doing something differently is often not immediately obvious to other people. You will have to patiently explain it! You should see the number of comments that they've had to write after this, sometimes again and again, and sometimes for years and years.
00:41:31
You won't be able to convince everybody, but you might reach somebody who finds your idea interesting or useful, and they might reach somebody else. Before you know it, lots of people are getting value out of your idea, and it might end up making a big difference after all.
00:41:55
There’s one last thing I’d like to say. When you make something and it receives criticism on the Internet, especially criticism from strangers, it can be very hard to deal with.
00:42:15
Sometimes, so much so that we might stop creating altogether or never even try. When I was researching, I found this old blog post by DHH from 2006 that I think captures a good way of thinking about these things.
00:42:33
So I’m just going to paraphrase it for you: view your idea or the thing that you’ve made as a pearl, not a diamond. When someone responds to your idea and points out all the flaws or the situations where the idea doesn't work for them, that’s okay.
00:42:54
What they’re asking for is a diamond. They want something that is flawless; they want something that is perfect. But you need to remember that however that is expressed—whether vitriolic or constructively or somewhere in between—it's not your job to make the diamond for them.
00:43:11
All you can do is give them the pearl that you are offering, and if that's not good enough for them, then thank you very much!