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.