RailsConf 2014 - Keynote: 10 Years! by Yehuda Katz

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.