YEHUDA KATZ: So it's been ten years.
Unlike DHH I can't get up here and
tell you I've been doing Rails for ten years.
I've been doing Rails for nine or eight or something
like that. But, Rails has been around
for ten years, and so it's not surprising
that a bunch of people are gonna get up here
and do a little bit of a retrospective.
So this is sort of my feeling. Oh my god,
I remember sort of thinking back in 2008,
when DHH was, was giving his talk about sort of
a look back around the same year that Merb
was becoming a thing, and DHH, and we were
eventually gonna, you know, merge a little bit later.
But in 2008, when DHH gave the great surplus
talk, that was sort of a retrospective year too,
because we had gotten to the point
where Rails was big enough that it couldn't
actually host a competitor.
And I think it's really great that we ended
up merging in and we ended up getting another
five, six years of, of, of great, a great
framework community. But now it's another opportunity to look
back and think about sort of what, what the
Rails community is and how you should think about
taking the lessons of Rails to other environments. And
that's sort of what my talk is about today.
So, I'm gonna start by saying, I think, if
you think about one thing about Rails, if you
want to think about what Rails is above anything
else, I think Rails popularized the idea of convention
over configuration. And you've been hearing the term convention
over configuration for ten years now. So probably it's
sort of, it's a meaningless term. It's sort of
like when you hear the same word over and
over and over again, eventually you reach semantic saturation.
I think we've all reached semantic saturation of the
term convention over configuration.
I want to unpack it a little bit. I
think one way of thinking about it is, is
this other term called the paradox of choice. This
idea that people, well I'll let DHH say what
it is, people like choices a lot more than
they like having to actually choose. Right, so there's
this, I think this sort of narrow point, but
it's still a very important point, which is that
people go into environments, they go into programming environments
or groceries or whatever, and they like the idea
of having a whole lot of choices, a lot
more than they like having to actually choose what
to do.
And this is sort of the state of the
art, this is what we knew in 2008 when
David gave the great surplus talk back then. And
what I want to do is go a little
bit beyond sort of these, these pithy points and
talk a little bit about what, what's happening, what
is actually going on that's causing this idea to
occur. What's hap- causing the paradox of choice? And
actually there's been a lot of science, even in
2008 there was science, but in between 2008 and
now, or certainly 2004 and now, there's been a
tremendous amount of science about what is causing the
paradox of choice. What is causing convention over configuration
to be effective.
And if you want to Google it, if you
want to go find something, more information about this
on Wikipedia, the term is called ego depletion. Sometimes
the idea of cognitive depletion. And in order to
understand what's happening here, you first need to understand,
you first need to think about sort of, like,
your everyday, your everyday job, your, how you feel
during the day.
So you wake up in the morning. You get
out, you go out of the house, and you're
pretty much fully charged. You're ready to attack the
world, you, hopefully it's sunny and you can skip
down the street. And you're, you're ready to do
anything. You're ready. You have all the, the, the
cognitive resources in the world.
And then, you know, you get to your desk.
I find it amusing that, that character is a
programmer. It's so perfect. So you get to your
desk and you know you've, you've done a little
bit of work, and you're cognitive resources start to
deplete a little bit. You got a little bit
fewer cognitive resources. You know, eventually something happens during
the day that you might not, that might not
be so pleasant, and your cognitive resources deplete and
then you reach a point, at some point during
the day - this is a Van Gogh painting
- you reach a point some time during the
day where you're really flagging. You're feeling like you
don't have a lot of capacity to left to,
to do anything or to think hard. And eventually
you totally run out. You run out of cognitive
resources entirely and you're done.
And so the idea here is the concept of
cognitive depletion or ego depletion, you have a certain
amount of resources and they run out. And I
think most people think about this in terms of,
like, you're day job. Right, so you wake up
in the morning. Throughout the day your resources deplete.
You get to the end of the day, you're
out of resources. Rinse and repeat. I think that's
how most people think about it and that's sort
of how I framed it here.
But the really interesting thing about ego depletion or
cognitive depletion is that what actually turns out to
be the case is that there's sort of this
one, there's this one big pool of resources, this
one battery, that's actually used for a lot of
different things. And so there's a lot of studies
about things like grocery stores, right. So why is
it that when you go to a grocery store,
why do you find yourself so willing to buy
something at the impulse, at the impulse aisle? Right,
at the end of the, at the end of
the grocery trip.
And the reason is that you spent all this
time in the grocery store doing not very difficult
activities, but you're making a lot of choices. So
you're making choices the entire time, as you're walking
around the grocery store. And eventually your brain just
runs out of resources to do anything else, and
it's actually drawing from the same pool of resources
that will power comes from. So even though choice
making and will power feel like two totally different
things, when you get to the end of the
grocery trip and you've used all of your resources
on choice making, you're out of resources to not
buy the candy bar at the, at the impulse,
from the impulse aisle.
And the same thing is true about a lot
of things. They've done studies where they'll just take
two halves of a room, like this one, and
they'll say, you guys memorize two numbers, you guys
memorize seven numbers, and then when they're totally done
and you've done the memorization, they'll take you into
a processing room and they'll say, OK. You have,
you know, cookies, and you have some fruit. And
you get to basically decide which one to eat.
And it turns out that the people who did
the not much more difficult job of memorizing seven
numbers are far more likely to eat the cookies.
And the same thing is true in the other
direction. If you have people eat cookies first, and
then go and do a cognitively difficult task, so
a task that requires. One of the most famous
experiments has to do with an impossible task. How
long can people persevere doing a task that you
can literally never finish? And it turns out that
people who eat the cookies first actually have, spend
a lot more time trying to do the impossible
task than the people that, that were, had, had
to sit in front of a tray of cookies
and were told not to eat it.
And so there's, there's all these experiments, there's, by
now in 2014 there is a ton of them,
and basically what they show in aggregate is that
there is this pool of resources that we have
to do our job, challenging tasks, to do cognitive
dissonance. So there's studies around, if you just tell
people, you need to get up and give a
speech about something that's different than what you actually
believe, people who do that actually have less will
power afterwards. They have less ability to do challenging
tasks. They have less general cognitive resources than people
who are asked to give a speech about something
they do believe. Even if the actual act of
giving the speech is equally, is equally difficult.
And so I think what's kind of interesting about
this is that, really what we want in programming
is we want to be doing, having as much
time as we can for the challenging tasks, right.
We want to be spending all of our time
on challenging tasks and as little of those very
scarce resources as we can on things like the
will power to write your code in exactly the
right way, or making a lot of choices.
And here are some terms that you might have
heard, basically, about this paradox of choice or ego
depletion or the concept of decision fatigue. These are
all ways that you've heard that describe this general
concept, this general concept of you just have this
battery, and it runs out at some point, and
there's all these really counter-intuitive things that don't seem
like they're very hard but are taking away resources
that you need to work on hard problems.
So, how do we, how do we solve this?
How do we actually solve this problem? Because obviously
it's the case that you, if you want to
be spending a lot of time on your challenging
problems, if you just ignore the problem of will
power or the problem of, of choices, you're just
gonna end up making a lot of mindless choices
all day. And, so what we need to do
is we need to find some psychological hacks that
we can apply that will keep us doing the
right thing, basically all the time. Keep us from
wasting cognitive resources.
And I think my favorite study about, about this,
about the kinds of cognitive hacks that work effectively,
is the idea of what happens to organ donation
if the organ donation requirement is opt in, in
other words, you go to the DMV and there's
a form that says, yes, I agree to donate
my organs and here are the ones I agree
to donate. And when the organ donation is opt
out, in other words, you have to explicitly say,
I do not want, I, I do not want
my organs to be donated. And what you can
see is that, in the countries where it's opt
in, it's actually a very, very low rate and
in the countries where it's opt out, it's a
surprisingly high rate. It's basically almost universal.
And I, and I think to, to some degree
you might expect that this is the case. But
I think this difference is really counter-intuitive, because you
would expect that if somebody, you know, goes and
they're sitting at a form and the form says,
Do you want to donate your organs? And the
excuse that they're telling themselves in their head for
not checking the check box is, you know, my
mom would be super angry if she found out
or my religion tells me that I shouldn't do
this or, you know, growing up, I heard people
say negative things or whatever, whatever the excuse is
you tell yourself to not check the check box,
you would think that some of those people, more
than, you know, zero point one percent of those
people, would pick up the pen and opt out.
But the interesting thing is that, by just changing
the default from yes to no, all of the
sudden, all those excuses, all those things that people
tell themselves about the reasons that they really shouldn't
check the check box, suddenly go away.
And what's, I think even more interesting about this
is that, these choices are actually made on, on
really big DMV forms. So you basically what you
can see is that people have already gone through
this really complicated, somewhat trivial but very choice-heavy process
of filling out this DMV form, and by the
time they get to the bottom and are asked
about organ donation, they're so cognitively depleted that they
have no energy left to even really think about
it. They basically just do the defaults.
So I think, honestly, defaults are our most powerful
psychological hack, our most powerful weapon in trying to
deal with the pro- the fact that we have
this limited source of cognitive capacity that we want
to make good use of when we're programming. And
the really cool thing about defaults in general is
that defaults are actually really effective on both sides
of the spectrum. So some days, you get to
work, you're ready to go, you're like, in an
amazing mood. Everything is perfect. Everything is awesome.
And on those days, the defaults, you have a
big store of cognitive resources, and the defaults keep
you high up. They keep you in the charge
state of a longer time. You don't have to
make choices that would go deplete, and remember the
choice-making doesn't deplete per minute. It's not every minute
of choices depletes. It's every choice depletes your cognitive
resources. So, having a set of defaults that tells
you, here is what you're gonna do in general
and, you have to, you know, you have to
think hard to opt out. That's really great when
you're in a good mood, when things are charged.
But it's actually also really great when you're in
a bad moon. When you're really depleted and you
still have to go to work and do your
job, because the default keeps you on the straight
and narrow, right. You don't have enough energy left
to really think about what you're doing, and so
everybody has bad days. Everybody works on teams with
developers who aren't great. Let me say it a
different way. Everyone has at some point worked on
a team, hopefully not. But you have junior developers.
You know, you hire people who are, who are
new to whatever it is that you're doing, or
you have a bad day, or you're stressed out
because your mom gave you a call at lunch
and now you're in a bad mood.
Right, so everybody gets to a point where they
have cognitively, my mother's gonna be so angry now.
Let's say, an ex-girlfriend or whatever. So everyone has
days where they're cognitively depleted. And on those days,
defaults are also really powerful, because they keep you,
when. Instead of having you be sort of in
a bad mood and you'll just sort of do
whatever, you know, you feel like, you're basically kept
on the straight and narrow. You're kept on the
right path.
And I think this actually helps to explain why
yak-shaving doesn't feel as good as you might think.
So, yak-shaving isn't the most terrible activity in the
world. I think sometimes you need to yak-shave. But
I think if you think about doing, like, four
hours of yak-shaving in an eight hour day, pretty
much after four hours, if you, you know, let
me set up my, you know, my vagrant box,
or let me go set up my testing environment.
After like four hours of that, you're totally cognitively
depleted. Doesn't matter that you only spent four hours
out of an eight hour day. Basically you have
no more cognitive resources left. And I think this,
this means we should be very careful about yak-shaving.
Because yak-shaving may feel good and it may be
important in a lot of cases, but we need
to be very honest about the fact that there
is, there's a certain amount of cognitive resources that
we have and yak-shaving takes up more of them
than you would expect. And they don't leave us
time after, even two hours or three hours, they
don't leave us a lot of cognitive resources to
actually do the task that we were yak-shaving towards.
So, obviously, occasionally you know you need to refactor
and, and do all kinds of these kinds of
tasks, but you should be careful about thinking that
you'll get a lot done afterwards.
So, I think this is sort of the unpacking.
This is a scientific unpacking of what it is
that we're talking about. But, and I think everyone
in this room can nod their heads along with
what I'm saying. They can agree with what I'm
saying. Makes sense. But what ends up happening in
the rest of the world, and also there's usually
a devil on your shoulder, is that people find
all kinds of excuses to argue against the thing
I just said.
So I just outlined sort of an unpacking of
sort of the conventional reconfiguration story, and somehow, we,
as a human race, actually find a lot of
ways to, to argue against these things. And one
of these, one of these ways that we find
to argue against it is to tell ourselves that
we're unique and we're special, and I'll just let
David from 2008 talk about this for a second.
DHH: One point I keep coming back to, over
and over again when I talk about Ruby and
Rails, is that we confessed commonality. We confessed the
fact that we're not as special as we like
to believe. We confessed that we're not the only
ones trying to climb the same mountain. And I
think this is a real important point because it's
somewhat counter intuitive, I think, for a lot of
developers to think that they're not that special. I
think it's counter intuitive for humans in general to
think they're not that special.
But, when they do think that they're special, when
they do think that they're the only ones climbing
that mountain, they kind of get these assumptions that
they need very unique and special tools that will
only work for them. And I think that's a
really bad way to approach getting greater productivity. Because
I think what really makes this special and makes
it work is all the points where we recognize
that we're exactly the same.
Y.K.: And I think that's really the point, is
that the way we gain better productivity is by
pushing back against this impulse. I think, we have
it in the Rails community to some degree. I
think it's especially significant outside of the Rails community,
where people didn't already come together around the idea
that we're gonna build shared tools and shared solutions.
But I think we really do have to push
back against this idea.
And I think my favorite example of this sort
of, taken to an absurdist extreme, is sort of
famous interview. What is your most surprising app on
the home screen? Well, it's Operator. It's a custom-designed,
one-of-a-kind bespoke app I had built for my assistant
and I to communicate and collaborate. Did this person
need a custom bespoke one-of-a-kind application to communicate with
their assistant? No. Almost certainly not.
But they decided they were so special, they were
so, they themselves were so one-of-a-kind, such a unique
snowflake, that they needed a special tool to communicate
with their assistant. And I think this is sort
of how, this is how we act. This is
how we behave. And if you look at, sort
of, how people talk about software, you see things
like, this is a tool set for building the
framework most suited to your application development. Your application,
your company, your industry is so special, that you
can't use general-purpose tools. You need to use a
tool set to build your own framework.
Or, in an ecosystem where overarching, decides-everything-for-you frameworks are
commonplace, and many libraries require your site to be
reorganized to suit their look, feel, and default behavior
- we should continue to be a tool that
gives you the freedom to design the full experience
of your web application.
And, who could be against freedom? Right? Freedom is
a really effective thing to put on the wall
to say, this is the thing that we're arguing
for. We're arguing for freedom. But this is just
another way, it's just another way that you, that
peoples' brains sneak in arguments against that, that helped
us create the paradox of choice in the first
place, right. People say, you know, I'm special. I
can't use these shared tools. I can't use these
tools that were built for everybody. I need to
use special tools. I need to use small libraries
that help me build my own abstractions. I can't
share with the community.
And then, even if people come to the conclusion
that maybe abstractions, maybe shared solutions are a good
idea, then you get another argument. The devil on
your shoulder or the devil in your community. It
makes another argument, which is the law of leaky
abstractions. And this is not, this is sort of
like the law of Demeter. It's not a suggestion,
or an observation. It's a law. The law of
leaky abstractions.
And I think any time somebody couches an observation
about software development as a law, you know something
fishy is going on. You know that something's not
right. Because software development isn't a science. You, basically
people want you to put on your science hat,
and say, aha! It's a law! It's like the
law of gravity. I can derive some conclusions from
this law. What, what, what conclusions do they want
you to derive? Abstractions are bad. You should never
use abstractions. You should do everything yourself.
And, so this law of leaky abstractions was originally
built by, or written by Joel Spolsky, and Jeff
Atwood, who was his partner at Stack Overflow, actually
responded, I think, kind of brilliantly to this. And
he said, you know, I'd argue, that virtually all
good programming abstractions are failed abstractions. I don't think
I've ever used one that didn't leak like a
sieve. But I think that's an awfully architecture astronaut
way of looking at things. Instead, let's ask ourselves
a more programatic question: does this abstraction make our
code at least a little easier to write? To
understand? To troubleshoot? Are we better off with this
abstraction than we were without it?
It's out job as modern programmers not to abandon
abstractions due to these deficiencies, but to embrace the
useful elements of them. To adapt the working parts
and construct ever so slightly less leaky and broken
abstractions over time.
And I think people use this idea, these excuses,
things like the law of leaky abstractions, to give
an excuse for themselves to not share solutions. And
I think sort of the hilarious thing, and this
is sort of a compressed super conflated set of
abstractions. Every single one of us is sitting on
top of abstractions that maybe occasionally leak, but really,
how many people ever have to drop down into
the X86 or the arm level? Or even the
C level? Right. People. We can build higher and
higher sets of abstractions, and we can keep, we
can keep building on top of these abstractions, and
build, and, and allow us to sort of eliminate
more and more code that we had to write
before. That we had to write in 1960, 1970,
1980. Sort of every year is another set of
things that we have discovered as a community that
we don't have to worry about, that were shared.
And I think, sort of, people look at us
and they say, oh my god it's a pile
of hacks. It's hacks on hacks on hacks on
hacks. But actually it's not. Actually what's going on
here is that every single time you start off
with this sort of experimental playground, people are building,
you know, at the bottom layer, people were building
their own hardware. And eventually people came to the
conclusion that you don't have to build your own
hardware. We can standardize around things like X86.
And then we standardized around it and people stopped
worrying about all the craziness that was underneath. And
then people said, we can build C, and if
we build C, people can stop worrying, most of
the time, about what's below it. So really every
one of these layers is not a pile of
hacks built on a pile of hacks. It's us,
as a group of people, as a community of
programmers, deciding that 90% of the things that we're
doing, we've figured out we don't actually need to,
to worry about.
And, I think, fundamentally, this is about, sort of
the history of programming is that we have shared
solutions. We make progress by building up the stack.
By eliminating code that we didn't have to write.
And Steve Jobs actually talked about this in 1995.
Sort of exactly the same thing. So let me
let him talk.
STEVE JOBS: Because it's all about managing complexity, right.
You're developers. You know that. It's all about managing
complexity. It's, like, scaffolding, right. You erect some scaffolding,
and if you keep going up and up and
up, eventually the scaffolding collapses of its own weight,
right. That's what building software is. It's, how much
scaffolding can you erect before the whole thing collapses
of its own weight.
Doesn't matter how many people you have working on
it. Doesn't matter if you're Microsoft with three, four
hundred people, five hundred people on the team. It
will collapse under its own weight. You've read the
Mythical Man Month, right. Basic premise of this is,
a software development project gets to a certain size
where if you add one more person, the amount
of energy to communicate with that person is actually
greater than their net contribution to the project, so
it slows down.
So you have local maximum and then it comes
down. We all know that about software. It's about
managing complexity. These tools allow you to not have
to worry about ninety percent of the stuff you
worry about, so that you can erect your five
stories of scaffolding, but starting at story number twenty-three
instead of starting at story number six. You get
a lot higher.
Y.K.: And I think that's fundamentally what we do
as software people. For all of the complaints that
people make about, you know, oh my god, every
abstraction leaks. All we've ever done, even in, even
as far back as, you know, in the 60s,
but even in 1995, Steve Jobs was already talking
about this idea that we can build higher by
building shared solutions. And I'm gonna let him speak
one more time, because I think, really, it's really
fascinating how much this idea of how you get
better programmer productivity hasn't really changed, fundamentally, since that
time.
STEVE JOBS: But, on top of that, we're gonna
put something called open step. And open step lets
you start developing your apps on the twentieth floor.
And the kinds of apps you can deliver are
phenomenal. But there's another hidden advantage.
Most of the great break through, the page makers,
the illustrators, et cetera, the directors, come from smaller
software companies. That's been said a few times today.
They don't come from the large software companies. They
come from the smaller ones. And one of the
greatest things is that using this new technology, two
people or three people in a garage can build
an app and get it from concept to market
in six to nine months, that is every bit
as feature-rich, every bit as reliable, and every bit
as exciting as a giant software company can do
with a hundred fifty person team.
It's phenomenal.
Y.K.: So, I think what's kind of cool about
this is that, this idea that we can take
shared problems that everyone has, shared problems that a
community of people have, solving the same problem, and
we can build up shared solutions. This is not
new. It's not, it shouldn't be controversial. It's kind
of fundamental to what we do as software developers.
And yet, if someone isn't up here telling you
this, it's so easy to forget. There are so
many excuses that people tell themselves.
Sort of what happens in reality is you have
this bulk of shared solutions, you have an area
of experimentation - sort of the wild west -
and you let the area of experimentation fold back
into shared solutions. This is sort of how Rails
works, right. So you build higher and higher and
higher stacks. You get to a point where you,
you know, you could build something like Devise in
the Rails community, because there's so much of what
underpins Devise, you know, everybody uses the same set
of model abstractions, everyone has similar ways of talking
about users, right. So you can build an abstraction
on top of that because everyone has sort of
built up this shared understanding of what it is
that we're doing.
And, it's so easy to let yourself be confused
by the fact that the area of experimentation is
the wild west, and forget that that area of
experimentation is sitting on top of huge, a huge
stack of abstractions. And this is sort of, I
think, to me, the answer to why the node
community seems, they're sitting on top of maybe, you
know, the most advanced dynamic language git in the
world, on top of all kinds of abstractions. And
they sit on top and they say, oh my
god, we need to build a lot of tiny
modules, because if we don't build tiny modules, this,
the abstraction's gonna kill us.
But, for me, this has always been a paradox.
You're sitting on top of a stack of abstractions
that's far higher than anything that you're claiming to
be afraid of. So, why are you so afraid?
And I think it's because of this area of
experimentation, right. When you're in an area of experimentation,
of course abstractions are gonna leak. You're still figuring
out what it is that you're doing.
But the goal of a good community that's gonna
help people be more productive is to eventually notice
that the area of experimentation is over. And move
into a conventional system where you can say, we
don't need to argue about this anymore. It was
a worthy thing for us to discuss when we
were thinking about the problem, but we can take
that and we can roll it in, into our
set of shared defaults, and we can climb up
the ladder, right.
And this is what, this is what Steve was
saying. He was saying, you know, instead of having
everybody start from some, some floor, sort of this
is how iOS programming works today, right. Ironically. Is
everyone starts from the same base. There is not
a lot of shared programming. A lot of shared
solutions. And I think, fundamentally, open source has been
something that has really kick started this idea of
experimentation merging through the shared solutions.
Because trying to essentially plan it the way big
companies like Apple or Microsoft do it, is just
not gonna get the job done across the board.
It'll, it'll solve some problems, but getting the open
source communities, the power of the open source community,
means that you can have all these little verticals,
all these little areas where people are trying to
build higher abstractions for shared communities.
And interestingly, it's not enough to make these abstractions
cheap. I think when you think about how people
actually go and they build on top of these
stacks, it's not enough, if every layer in the
abstraction, in fact, if x86 and then C and,
you know, Linux, and Posits. If every one of
those things cost a little, by the time you
actually got to build software, you would be so
overwhelmed with the weight of the abstraction that you
would never be able to do anything.
So, it's really fundamental that the abstractions that we
build eventually get to the point where they're basically
free. Where they have no cognitive capacity. So that
we can keep building higher and higher and higher,
right. And the Rails philosophy is basically, how do
you do that? How do you, how do, how
do you say, you know, we're gonna experiment for
a little bit, but eventually we're gonna work really
hard, we're gonna push really hard at making the
cost of that thing that everyone was just experimenting
with a minute, a little, a minute ago free,
so that we can go build another level up
and another level up.
And, I have a few sort of closing points
to make about the ecosystem. So, first of all,
Rails is not the only way that we have
to share. I think I was pretty sad when
the queue abstraction didn't end up in Rails, but
I kind of am sad that we didn't get
to see sort of what you can build up
on top of the queue abstraction, there's really no
reason that all the queue guys didn't get together
and say, you know, we're gonna build some abstraction
on top of that. And once you build the
abstraction on top of that, then you can see
how high you can go, right.
And a sort of similar thing happened in the
JavaScript community. In the JavaScript community there were a
lot of different promise implementations, and what happened over
time is that people realized that not having a
standard way to talk about this was actually making
it hard to build up.
So we said, let's actually get together and let's
decide that we're gonna have a standard way of
talking about that. We'll call it PromisesA+. And now
Promises are in the DOM. And now, you know,
we can build up another level and make asynchronous
things look synchronous. And then we can build up
another level, and we can put that idea into
the language.
And, you know, I don't know where we're gonna
go from there. But we can start building higher
and higher abstractions. But it requires taking the first
step. So I, I guess what I'm saying is,
getting something into Rails core is not the only
way that you can build these abstractions. It, it
requires some discipline to actually get to the point
where we're agreeing on something, but I think if
you find that there is some topic, like, for
example, jobs or, you know, queuing or jobs, and
everybody does them or a lot of people do
them but we don't have a good way of
building on top of them, that's a good opportunity
for someone to go and say, I'm gonna do
the hard work to say, let's create a shared
idea of what it is that we're doing.
And sometimes it's via an inter-op player and sometimes
it's via standardizing around one solution.
And, another part of this is, when I started
working on Ember in the JavaScript community, I thought
a lot of these ideas were obvious. I thought
it was gonna be, you know, a slam dunk.
Everybody should agree that building a shared set of
solutions is the right thing. And what I found
was that, what I found instead is how powerful
the unique snowflake bias is, and how powerful the
leaky abstraction fallacy can be in communities that don't
place a high value on shared solutions.
So, if you don't see the power of shared
solutions, if you're not familiar with the idea, with
the wins, it's really easy to pull out those
olds canards, the I am a unique snow flake,
I can't use a tool like Ember, because I
have special needs. I need to use a toolkit
that lets me build my own framework, because my
needs are oh-so-special.
Or, you know, you know, I looked at Ember
when it was new, and Ember leaked all over
the place. So the law of leaky abstractions means
you can't build in JavaScript a shared solution. But,
of course these things are not true. And I
think, what I want to say is, I think
Rails, ten years on, has basically proved that these
things are not true.
Before Rails, people spent a lot of time working
on their own bespoke solutions, convinced that their problem
was just too special for shared solutions. An when
Rails came out, they looked at the very idea
of convention over configuration as a joke. And then,
one day, Rails developers started beating the pants off
those people. And I think, in closing, if you
find yourself in an ecosystem where developers still start
from floor one every time, learn the lessons of
Rails.
Everybody should band together, push back, both in your
own brain and on other people, on the excuses
that drive us apart instead of the things that
bind us together. The legacy of Rails isn't MVC
or even Ruby. It's powerful ten years of evidence
that by sticking to our guns, we can build
far higher than anyone ever imagined.
Thank you very much.