- [Interviewer] How are you? Hanging in there? - [David] I'm pretty good
now, better than I was two or three weeks ago, I'd say. I think just the acclimation
that always happens, has happened.
- Yep. - For me at least, to a large
extent, I mean the world is still fucked up.
- (chuckles)Yeah. - And life is not back to normal but, it's I think Week Five, or Week Six, of our quarantine
at the house, so yeah. - Yeah Zoe, my eight year-old,
asked me that yesterday, "What week is it? "Like, how long since
we've been doing this?" I was like, "Honey, I don't
know, I'd have to figure it" (laughter) I was like, "You're lucky
I know it's Thursday." - Yes, yeah, it's almost
like we're in the new time calculation, like, time started at zero, with the quarantine. We're now in week of the seventh. (laughter)
- Yes, pretty much. All right, so we gotta bunch of questions, I thought we'd kinda wander
around, in the questions, and just talk about various
things, we obviously won't make it through the whole topic list,
and I figured we'd go about 45 minutes or so. - What I can do just first,
perhaps, is just, I kinda hyped my keynote and what that was
going to be about, and I just wanted to sort of address
that a little bit, which was, our plan was to launch a brand
new product, right the week, actually, before RailConf. (laughter) So, we were gonna launch Hey.Com
the week before RailsConf and we just had a bunch
of new tech, in that app, that I wanted to talk about. And then, when all this sort
of happened, well I went three weeks where I did nothing
but rant on Twitter and try to pressure companies
into doing the right things, and all sorts of the other
things, except program Ruby and make progress on the
product and therefore also make progress on the things
I wanted to talk about. And that was kinda how I ended up with, "You know what, I don't have
the product out, I want to talk "about, I don't have the
technology wrapped up." So, rather than do this
kind of half-assed thing, where I can't actually show
and tell, I could just tell, we're gonna save that and
kind of do that whole reveal of how we do the front-end
differently in Hey, once Hey is out.
- Sure, okay. - Yeah, that question got
asked on Twitter, like, "Hey, what's going on with that thing?" - Right.
- So, yeah. I mean we've got some kind of,
maybe adjacent stuff we get into on there. For instance, like if
you wanna get into it, one of the questions we can,
I guess we can just dive in, what that is, you know,
people are interested in stuff like, have you been doing
anything different on mobile? Like, you're building a
- yes. You're building a email app,
we presume it's an email app, and people read email on their
phone, so that may be a good, like, have you been working on that? I mean, I know that
Basecamp has an app still and that's been, and I remember
when you first came out with that, there's been no evolution there too. So, yeah, any thoughts on - Yeah, no that's a great question. And, I mean it goes directly
to what I was going to talk about, like our whole
philosophy of making apps, at Basecamp, is first of
all the majestic monolith. That, at the center of,
not just the web app, but at the center of all the
apps, lives this majestic monolith, that's not just
an API server either, right? Like for Basecamp, for example,
when you, in our native iOS app, go to a message, that
rendering comes straight from that majestic monolith,
it goes straight through a controller, straight through a erb view, and it spits out HTML. Now, what has changed over
the years and has changed even more so perhaps in Hey,
is where is the border, right? Like, how much of the
work comes from HTML, in terms of the majestic
monolith, and how much is sort of a native, fully native application. And, we've added more and
more native stuff, but still that was taking it from
like one percent, like our, I had a write up, I think
four or five years ago, maybe even a little more,
where I talked about, "Hey 99% of Basecamp is just
the web and then there's 1% "of native stuff that wraps it." Now, it's perhaps a little
more like 10% is native, 90% is still the majestic monolith. And we followed the same approach in Hey, but we've just kind of doubled
down and expanded upon it, in a large variety of ways
where, with Basecamp the native apps were kind of, weren't an
afterthought, we sort of had it in mind but, with Hey, we
started with the native apps from day one.
- Right, right. - I mean, this whole idea of
building an email app that, isn't nice on the phone, makes no sense. So, for Basecamp, I think
It's something like 70 or 80% is still actually desktop use. And then we have 20 to 30% on
mobile but, you go to email and it's probably the
other way around, right? Like it's probably 80% is
going to be on the phone and 20% is going to be on the desktop. So, we went from the start and
said like, "These don't just "have to be good, they have
to be great and we gotta "do the full native thing
right from the get go." And, I think perhaps there,
it's interesting where we picked a different path than some. Like, our native app wrappers,
they're written in complete native, we don't use a ionic,
or some other way of kind of getting to the native stuff,
we have fully native teams that work on iOS, they work
in Swift, and they use all the default Apple stuff, and
then they just put web views everywhere right?
- I was gonna say, yeah. - Not just web views but,
Turbolinks web views, Turbolinks sort of forms the
core of all this interaction, since it is fast, and it's
not continuously reloading, and all these other things. And we do the same thing on Android, on Android we use Kotlin,
and we use, again, the standard Android set up. And we can do that because
we have native teams, our native teams are still
tiny though, we have two programmers on each side. Two Android programmers,
two iOS programmers, and a designer for each
team, so it's teams of three. On iOS they handle both
the iPad and the iPhone, and probably also gonna
handle the Mac app for Hey. And then, on Android,
well it's mostly Android, the phone, right? But, kind of like the
philosophy of the approach has remained the same, like,
for me, what I want to write? I wanna write Ruby.
- Yeah. - And not only do I wanna write Ruby, I want to write as little, sort
of, I want to write as much of the application in Ruby as possible. So that's the other thing,
where we've kind of taken, a different path than the
rest, most of the rest, of the industry, is that our
majestic monolith, again, is not just about an API
server, it really has HTML under it's core. And we try to do as much as
we can such that we can write applications in kind of
like the vintage style. I like to think of it
like, in terms of developer ergonomics, the peak of the
web happened in like 2004, - (chuckles) Sure.
- in terms of the board, right? And, think about it like,
"Oh, well that means "you're just stuck in
your ways, this is just.." Fuck no, like look at what it
takes to develop a modern app with like a full API,
split distributed system, React on the front-end,
the whole shebang, right? The number of moving
pieces is just enormous. Now, some people go like,
"Well, that's just what we have "to do, that's what modern
is" and we just went, "No". We can get virtually all the
benefits you get from that model, in the traditional
approach, with the traditional ergonomics, that just makes
for that wonderful Rails productive experience,
by going through things like Turbolinks and, I mean
then the rest of the picture was sort of what I was
gonna present, and I'll talk about that later.
- Sure, yeah, yeah. - But, the whole philosophy is that. - I think, you know it's
such an interesting approach too because it allows you
to keep, I imagine I guess, Hey imagines the ability
to keep your design team small, right? 'Cause you imagine, if you
have all native, like no, none of this, if you're like, "I'm gonna build a completely native app" then you're like, "Okay great,
like, I have three different "design teams, cause I gotta
design the one, and I gotta "design the other one, and I
gotta design the third one." - Yes, yes. That really probably is the
number one benefit here, is that, we pick this architecture, not just because we think
it's a good technological approach, I think it
is, I think it's great, I think it's a lotta fun. But, we picked it because it works for our company size.
- Sure. - We are 56 people at
Basecamp, 15 of those are, even a little more, are on support, we have very small teams. As I said, Android there's
three people, for all of it right?
- Right. For iOS and iPad, three people, all of it. Could they rebuild an app
like Basecamp from scratch, in native?
- Right. There's like 260 screens, or more, never ever going to happen. You'd need a team of
tens of people, right? That's our entire development
team is tens of people, right? - And then you'd have to
duplicate support again too, you have to have a different
support for iOS two, then too. - Yes, yes, and we didn't
want to do that, right? You look at our, we call it
Core Product, that's the team that developed all the
features on the web, it's four developers. - Yeah.
- That's it! And the reason we can have
such small group, you count all that up right, so two
developers on Android, two developers on iOS, and then four, that's eight developers
basically making the whole app - Right.
- right, for everything on all the platforms, at once. That's just not compatible
with like recreate everything, everywhere, do the whole thing as like this big distributed app. And, I'm glad you asked about
the designers because I think that's also which, weirdly
unique, I look at like, why aren't more people doing it? All of our designers,
they don't just like draw, that's not what design means at Basecamp. They make, all of our
designers, they write their own JavaScript, they write their
own Ruby on Rails code. Now, it's not necessarily the
final thing but every single designer we have, they can
stand up like, "Hey, here's what "the feature's going to look"
and now, if it's complicated on the backend, then
obviously programmer's gonna come in and they're going to help with it, but a lot of features we
actually have, they'll end up fully shipping just off a designer. - Yeah absolutely
- They just jump into the boat, because they can, right? Ruby on Rails is approachable enough that, if you're a designer who
knows how to make HTML, you know how to make CSS,
you can jump into it, you can figure it out. And, I think that that's
also one of the things that's unique about Ruby, and
why it's just such a wonderful language, is it, it allows
people to make that small jump from JavaScript like,
"Hey I know a little bit "of JavaScript" to like "Hey,
I also, I could do it in Ruby" and then they can pursue
perfection because they own the whole stack.
- Right. - One generalist, at Basecamp,
can ship an entire feature to everyone, on every platform, at once. - Right, absolutely! - You compare that to a
lot of other organizations, and how they're set up, and
it's absolutely not how it is, right, like I've been ranting about this idea of specialization. We've really gotten to the point where, in a lot of organizations,
the layers are getting sliced thinner and thinner, "Well I am a front-end
engineer for this platform." - (laughing) Yeah. - Shit, that is just such a
small slice compared to Hey, at Basecamp there might
be sort of leanings, or you have a preference, but
everyone can do everything, and they do it, most of the time. - Yeah, so it's like a segue
way into another kinda question I had which is, Basecamp has
been, well, 37 cycles prior, has been around for how long? It's been..
- 20 years almost. - 20 years, yeah, so it'd be interesting, we don't have to go
super long on this but, it'd be interesting. If you think back on where you
were and where you started, do you feel like you've,
obviously things have changed as technology's changed,
we've all gotten older, we're stuck at home now, we
weren't stuck at home 20 years ago, but it'd be interesting
to kinda get your feeling on, do you feel like, if you
were to project forward, or look backwards, either
direction, say like, "Did I think it would look like this?" Are you there, or what has surprised you? Has it been really
consistent in that time? - It is a good question. I think, my overall take,
and maybe it is just because I'm getting old, and
a curmudgeon at heart, it's just like things just
don't change that rapidly. I look at the original Ruby
on Rails code, that I wrote like, what's that like 16, 17 years ago?
- Yep. - You don't have to squint
that much to see how we still write apps,right?
- Yeah - In fact, if anything,
and maybe that's, again, just nostalgia, and I can
just imagine kind of like, "Well this just proves that you're old "and you can't evolve from the clock." But, I'm holding back to that
and like, do you know what? It's funny, it's kinda like
the same thing with music, a lot of people they'll
go with their most, the time in their life
that was most formative, that's when they track the most
sort of stubborn preferences for music they're like, "Hey,
if your life was great in '84, "fuck you love 84 (laughter
drowns out speech) music." right?
- Yeah. So, I think I have perhaps
some of that and I'll accept that right up front,
but some of this, again, goes back to the sense that,
like that developer ergonomics experience, that we had in
the early days 2004 to 2008, before kind of the pressure,
of what you needed to do on the front end with Javascript, was kind of tearing things
apart, I'm holding on to that like a fucking '84 hair band, right? This was the peak, in many ways,
of the developer ergonomics experience, and that's
a lot of why I'm here, why I'm still here, right? So, I'm an executive at
a company of 56 people, that have this CTO hat
on, a lot of other people who have that hat on, like,
they don't program that much every day, anymore. All, blessed be with that,
like, I would just go nuts if that was me, right, I
need to program every week, at the very least. And I've been, I just had two
weeks in a row, that's why I was in such a cheery mood
when you asked me about like, "Hey how are things going?" They've been going great
because for the last two weeks, I have had basically
nothing but Ruby programming in my head, I've been programming
like four or five hours a day and it's just like, I
shut my computer at five PM and I just go outta my office
with a goddam smile on, that wide.
(laughter) And the reason the smile is
that fucking wide is that there is that, just joy of the work. And the joy of the impact, and
the joy of kind of the dance, the aesthetics, everything
that, sort of hopefully, we all love about Ruby, although
I just got into a tangle on Twitter the other day
where someone was like, "Rrr, people only care
"about programmer aesthetics" or something "they're toxic." All right, I feel for that, toxic I am. I care so deeply about that
and like, that hasn't changed that much, right? Like, we continue to fiddle at it. It's the same thing when I
look at the evolution of Ruby, you look at, I just did it
the other day, I was like, "Oh, I wonder actually what
could have added in Ruby, in the last few versions"
that I would, sort of use and I looked at 2.7, 2.6,
2.5, 2.4, you're like, things aren't changing that
radically because they're great, - Yeah.
- right? It reminds me of, I
think it was Johnny Ive, who was remarking something
about like why some design, either for a Mac or
something, hasn't changed and he was like, "At Apple
we're not just looking to make "change, we're looking
to make things better." So, I really internalized that
since then like, you can get to a certain point where,
if you don't have an idea for making it better, the
most likely thing you'll do is you'll fuck it up, by changing it. Right, like you'll make it worse. And there's so many things
we keep making worse all the time. This industry is just sort of
a group hug of amnesia where, we learn all these things, it's
funny, obviously with Ruby, when I got into that I
would talk to people, who were in Smalltalk, for
example, and they were like, "All the things we had, like
the refactoring browser, "the live IDE, it's like
it was lost to the ages "and it still hasn't been rediscovered." (laughter) And now, now like, in some
ways, some of us Ruby folks are sitting in that camp shouting
to the JavaScript people, "But the things we had,
the things we had", right?
- So true, yeah. - And so, I look at all that
and you go like you know what, the world hasn't changed that much. Really the main thing, when
I look back over the 20 years of doing web apps, the things
that changed was the iPhone, that's pretty much what I
could point to and, like, that was the big change, for
me, that you really needed to tackle in a different way. And, what's kind of ironic
is that like, that change has almost petered out, to
some extent, because when the iPhone first was introduced,
it was just a horribly slow machine and you had to build
web apps in a different way, you couldn't do it in the same ways, the cpu was just terrible, right? Now, I just benchmarked my
iPhone 11 Pro yesterday, it was putting down like
160 on the Speedometer 2.0, which as compared to like, I
have an iMac Pro with, I dunno, fucking 12 Cores that does
like 130, my Mac Book 16 does like 120. Now, the fastest computers we
own, for operating the web, are our phones.
- Yep And it's getting crazy like,
the Apple just released that, the new iPhone, what's it called?
- The SE. The SE right, a 38 $199 phone
that has that chip that does 160 on the Speedometer 2.0, just like (imitates head exploding), right? So, in some ways, that mobile
change is now more of a UI change, it used to be a thing
we needed to care about. Like, when we built Basecamp
2, we built an entirely separate JavaScript model
for the web views we needed on the phone because we couldn't
run the real JavaScript, it was just too slow,
this was 2013-14, right? So, like, there's some convergence
where things are getting sort of back and they're getting better. So, anyway, on the tech side,
I don't think things have changed that much, I think a
lot of people think they have changed a lot and that now we
have to do all these things, now we have to have 15 people
just to stand up a CRUD app, because you slice it into all
these different specialties and it's a fucking blind alley. And I think it's a terrible
way to go and it's such a weird thing where we, in the Ruby
on Rails community, it's like it all exploded 2005-6,
people go like, "Oh wow, "this is new, this is change,
this is different", right? And then we had sort of,
I dunno, five years until JavaScript kind of got a second
wind, where everyone just internalized and adopted
this idea that like, "Hey productivity's good,
having one developer being able "to do a lot of progress is
good" and then we got to this point where like, "Oh no, no,
we have to make a basic thing, "yeah that'll be 15
developers and nine months (laughter) "plus tax." And it's just kinda like, "Wha, what?" And, I think perhaps,
what did happen was that Silicon Valley started sloshing
so much fucking money around that it just didn't matter,
it just didn't matter whether your MBP needed 15 people plus tax, right? Because you could just hire whatever. Versus Ruby on Rails and the
whole ethos was born out of, "Hey what can you do with one developer?" Right, like I built
all of Basecamp myself, I installed it on the
servers, I operated it, I did the whole thing. I needed a toolkit that
could do that, right? And we've kept that ethos
going, up until now. And, I think perhaps now this
pendulum is gonna swing back, where someone goes like, "Yeah,
I can't do the 15 developers "plus tax anymore" right? Like, "We just don't have the
money, now things are" anyway, that was a long winded speech. - No no, that's great, I
mean I think that what, one interest I had on here, that I had added this morning
on my list was this interestng of the swing is, I think
that, couple of things. I was thinking back on
when you were trying, at RubyConf in San Diego,
that time when you were trying to get Rails one out. And I was thinking back
on it and being like, if you were to look at an
app now, that DHH would look at an app now, you'd be like, "Yeah this looks basically the same. "Like, oh what's a concern?" There may be a few concepts
in there but it looks effectively the same. So the other thing that's
interesting is we had that like sort of, we're talking,
you had mentioned like the monolith, the majestic monolith. And I think it's, it feels
like even just the last few months we've all of a
sudden we've seen again, you know we had the monolith,
then we saw the microservices and now, like everybody's
like, "Hey you know what? "Let's just go back to monolith again." I feel like that zeitgeist
has become again, which is, it's so interesting I feel
like, I feel like there's a lot of things that, you personally,
as well as Rails have been like kind of just a steady,
like the small sine wave, and that the rest of the
industry has been the big sine wave, and then like it matches
back up sometimes again. - Yes, yes, so there's all
these very interesting theories and kind of like the historic
dialect taken, you swing back from theses and antitheses
and hypotheses and like, back and forth. And, I think, some of it is,
not to get this too political but, I look at someone
like Bernie Sanders, right? Dude's been saying the
same shit for 40 years, no one gave a crap in like
the 80s, the 90s, and then all of a sudden like 2000
and something such, 2006, all of a sudden people show up, "Hey, that dude's got some points", right? It's like, no new points, you
look at a clip from like '72 and you're like, I mean
slightly more hair perhaps, otherwise same dude, same shit, right? The pendulum swung to him
and I think of the same way with Rails, it's like the
pendulum keeps swinging, you're never going to be
in the sweet spot forever, that's just not how
the world works, right? So, we were swung in, in like
2006 to 2010 or whatever, then the pendulum starts swinging back, we kept going, right? Now, the pendulum is switching
back again and we're like, "Yep, still here." (laughter) Just got a bunch of hipsters. So, like all these questions
you're rediscovering, right, like that amnesia
sometimes it runs in cycles and that's partly why the
pendulum keeps swinging. I saw this thing about like,
the number of developers, in the world, doubles like
every three years or something? So just the influx of new
people, like the average age someone has spent in the
industry is very short, so that's the explanation for the amnesia, in large part, right? Like someone comes into the
industry and they go like, "What's hot right now?" Rails used to be just the hot thing and that used to be the default. Now it's, it was no longer
the default, now you go like, "Oh React is the default", right? And then, some point people
sort of grow up through that and they go like,
"Nyah, this kinda hurts, I wonder if someone has
some massage tools here "that we can use, can we
stop some of this hurt? "Like, why does my neck
have to crane like this." And we go like, "Hey, hey
we're still over here, "it's still good." And I think that that's where
things are coming back to. And the other thing too, with
that, is if you're investing your ego into like, "I
wanna be the hot shit" and "We always gotta be the
hot shit" like, you're gonna have a bad time, 'cause nothing
stays the hot shit forever. - Yeah.
- So, for me personally, like why am I
still working on Ruby on Rails after 17 years? Because the hot shit was like
a sideshow, the main shit was what I just talked about,
that bliss of me getting to do Ruby on Rails for two
weeks straight, walking out with the biggest grin on
my face at five o'clock because I got to work in
this amazing environment, like that's the main attraction. With the main attraction it's
your own intrinsic motivation, the other stuff can come and go, right? Same thing like we said with
Sanders like, if he's saying the shit he actually believes,
he's not trying to sort of focus group his way into like, what should the message be. It's so much easier to stay consistent, it's so much easier to stay in the game. And, I think that's the
game we've stayed in and the other thing
there too is just like, things just don't change
that much, we love to believe that they do, "Oh man technology's
so fast", no it's not. Like, you look at the broad
scheme of like what has happened in programming over the past
60 years, there's these blips where shit did happen, right? - Yeah.
- But like legitimately, when I look at, functional
programming is another great tip, right?
- Yeah. - Functional programming is a
huge rise, obviously, but like it was also there before, right? So it's, again, it's sort of this amnesia where we kind of just feel
like to make our own lives interesting, on a broad scale,
we kinda have to run around in these circles.
- Sure. - That's actually a good,
that's another good segue way into sorta like maybe, not
a lighter topic necessarily, a little bit of a
slightly different topic, which is so you've, yeah
you're going in, you're working on your stuff and are there
things that you look at, like other technologies,
stuff that you would look at and be like, "yeah this is
just" like it sorta, to sate that crave in some way and be like, "Oh maybe I wanna go write
Assembly" you know like, "M68K Assembly today". Is there other things like that, you know we have some questions about Crystal, or
truffleruby, or TypeScript, things like that. Are there things in there, they
don't necessarily have to be stuff that go into Rails,
but stuff that maybe you like to dabble with, you like
to play with at times? - Yeah, it's a good question
because I think I'm a misnomer in that sense. Like, I, the way I approach
a lot of things is, when I don't know what to
pick, I try all the options and I try everything
and I figure it all out. And then, at some point,
I'll reach my conclusion, and those conclusions can stay
stable for a very long time. I have not found a better
programming language than Ruby. And, I've tried a fair number
of different things but, I'm so intently enamored,
by what we have in Ruby and how that model works, that
the pull of a lot of other things is just not really there. And a lot of the things
that to me, for example, makes Ruby special is the fact
that it's dynamically typed. So, typing for me is
really, I mean I'm allergic. And I don't say that
with necessarily pride, because I do recognize the
benefits you can get from static typing, or inferred typing,
in different ways but, you know what, I'm not
willing to pay any of it. Like, TypeScript is probably
the closest, where you can go, there are a number of people,
the JavaScript crew we have at Basecamp, they're
pretty fond of TypeScript. I look at TypeScript and
like, I'd rather not, like I'd rather not today. So, we actually don't, we
use TypeScript to write some of our library code, we
don't use TypeScript to write our application code, at Basecamp, we still just use JavaScript. JavaScript I'd say, modern
JavaScript, like ES6 plus is probably the closest where
I'd go like, "You know what, "this is a good time, I'm
not having a bad time", I used to have a bad
time writing JavaScript, I used to really dislike
JavaScript very intensely, that 6+ JavaScript, not bad at all, right? And then some of that is,
I'm an OO programmer, right, like you have these sort of
leanings, functional programming is great, I like a bunch of
it, it has influenced my code style, and Ruby is this
wonderfully poly paradigm language, where you can mix and match
in such a great way but, like my emphasis is very
much on the object oriented side of things. So, in that sense, I'm not
like super interested in that and then I look at some of
these other things like Crystal or other, sorbet or these
other things that can add type to Ruby, and I go like, I love
that we have such a big tent, that people can play
- Yeah. - with that, there's no
fucking way I'm gonna do it. (laughter) - And Matz, Matz, Matz,
if you are listening, do not put this into Ruby,
the Ruby we have right now and it's relationship
with typing is wonderful, do not fuck it up. Like, I look at something
like php and I go like, I have fond memories of php. The php I look at today, no. Don't try and be something
you're not, like, there are endless amounts
of environments and so on, that already do these other
things, we don't need to turn Ruby into another version
of that, Ruby is beautifully unique for what it is and the
core appeal, of what that is, is the dynamic typing, at least for me. Now, I've had some conversations
with other teams like, the teams at Shopify, they're
experimenting with sorbet, they have legitimately
different concerns and, like, the kind of bugs that they
see in Production, I go like, "Hunh, okay, that's fascinating",
I guess different things happen when you have 100+
programmers working on a single code base and like, whatever right, like they have different concerns. And I fully accept the
limitations of my preferences are born within, like,
long running code bases made by small teams of stable
crews who work together for a long time. You can do different things,
you need different safeties on your knives, right?
- Yeah. Like, we can have the
sharpest goddamn knives, in the drawer, that are really
good and precise and like, yeah they can cut a finger
off, right, that's the whole thing about the rope to hang yourself. Yeah, you can use the rope to
hang yourself or you can use it to climb up to a more
beautiful vantage point. We're using that rope all
the time to climb up to the beautiful vantage point
and I'm not fucking giving up a rope just because someone
can use it to hang themselves with, right?
- Right. The same thing with the sharp knives. So, in that regard, yeah
I'm boring like that, like I'm really intently focused
on finding the right thing and then, once I do, I
move on to other things, like there are other
things that interest me. Finding another programming
language is not high on my list of sort of hobbies. - Sure, so one thing you
mentioned that would be a good sorta track to take is, so
in addition to working on Basecamp for as long as you
have, you've basically been the head, the top of the
Rails open source project for, basically, about that same length of time. And so, it'd be interesting
to hear sort of how your role, with the larger project,
has evolved over time, but also like, kind of what
you look for in people who work on the project. I mean the core team, the
people who come and go from the core team over time. And, in some ways, the core
team, sort of some of the things that you espouse today, sort
of map towards things that you look for in people who are on
the Rails core team as well. So, anyway, so, so I'll let
you talk about that, yeah. - That's great because it
totally did change a lot, like when I started working
on Rails, or when I started extracting Rails in 2003,
obviously I wrote it all myself, because that was what it was. And then, for about a year
after it was made public, I just took patches, I still
committed everything myself. These days, I write the minority
of Rails, directly, myself, by my own hands. Like, I am, the role that
I play now is more like the biggest fan, the biggest user right? Like, I care extremely
deeply about how it feels to use it, I care a
little less about like, necessarily how it's implemented. Like, if you ask me, "How is
the Active Record relations "model set up and implement?" I couldn't tell you,
off the top of my head. Or, like, "How is the view
optimizations, how do we do "caching for templates and so
on" I have this fuzzy rough idea, and I could look it up,
I can probably follow the code but, I can't recite and I can't
write it on a white board. And that has changed because
we just got such an influx of people who care very deeply
about very specific things, and I go like, "Wonderful,
now I don't have to care about "that anymore"
- (laughs) Right. - There's someone who now knows
the depths of the relation model in Active Record, and I
could go, "Wonderful, you know "what, I'm just gonna park
that shit outta my brain" like, I'm gonna pour it out actually,
like I'm gonna just go banging on my head and it's
just going to flow out. And then I can fill in some new shit. - Yeah.
- I can fill in some new stuff and I can let
that play around and then we'll have someone else who
winds up to kind of do that. And I think that that, to me,
was always my hope for Rails, that we would have people
who individually cared about different things and then
we'd all come together and we'd go like, "Hey, this is better" I can share my part like,
"Hey I care a lot about Api "design, lemme do some designs for you." I care a lot about
extracting new frameworks, everything from Action
mailbox to Active Storage, all these things come from me
using the framework and going like, "You know what, I don't
want this shit in my app, "this should be in the
framework" so that I have it next time we do another app. And so, I do that and then we
have all these other people show up with all the other stuff. I think, the experience
with Merb, which was this, sort of alternative framework
that was doing a lot of the similar things
to Rails, back in 2000, I think nine, eight, but
from a different care. Like the people who were
working on it cared about some different things, Ezra
and Yehuda, like there's a lot of things about performance
and extensibility and so on. And we thought in the beginning like, well I dunno if I ever thought, but there was a
misconception that like well, it's Rails doesn't want these
things, they don't care about speed, they don't care
about extensibility. And I was like, "No, I just don't", it's not that I don't care,
it's just not, that's not my focus, right?
- Right. - That's not the main thing I want to do, so you could do it. If you want to do it like, "Wonderful, come, please come
in here", right? (laughter) That's what we have right now
in the Rails core group a lot is, we have a bunch of people,
who care about different things, like Aaron and
Eileen have worked a bunch on performance stuff, they
worked on making Active Record work better at Github. And then we have a bunch of people also, from Shopify and so on,
that kind of bring all that stuff in and we go
like, "Hey this is great, "we're sitting at this big
table and we're sharing "all the plates."
- Yeah. - So that is really, that
has been the philosophy, I think it's been like
that for a long time and I think that that's
the, the most successful, or easiest, path to get on
the core team is just start caring about something that
no one else has cared for for a while. And, like, show up with
the work and go like, "Hey, here's a bunch of
stuff that I care about "and I made better. "Do you like it?" And like we all can go, "Yes!" - That's super great to hear. I love the idea of thinking
about you as just like the super fan, right? Like, just the person who's
like, "Hey I have an opinion "about this because I want
it to, like it works the way "I like it to work so let's
maybe not change it because "I want it to work that way", right? I love that idea that you're
sort of the person who arrives at the amusement park and was like, "What new rides are there today? "I love these old ones, don't
take the old ones down but, "what new rides are we going to do today?" And it's not like I'm
building all the rides myself. - No, totally, and I
think that has changed, like I've gone a lot where
I'll put on like an idea of how I'd like to see something
work and I'll just open a pull request. Like, I'm kind of using the
Executive privilege there. Like, normally we don't use
pull requests for future requests but, I'm like, "I
really want this thing, is there "someone who's interested in doing that" and I'll pop it on there. And, another tactic I often
use, which I found very rewarding is, I'll make
a really shitty version of what I want and then
I'll put it up there. And, if there's something
programmers love to do, it's point out shitty code, right? Like they're like, "Whoa, here's a thing "that's kinda shitty,
I can make it better", I think I'm good at not feeling embarrassed about shitty code. Like, I'll write some
shitty code, actually, usually it's not necessarily
the code is shitty because I do care about
making it nice, but it's like it's very incomplete, or it's slow, or it's all these other things, right? And you put it out in the open
and like a bunch of people show up and they wanna help,
they want to make it better. So, I pulled back from more
and more, like the drafts, that I share now, they're
so fucking rough, right? Like, I remember when I first
published Ruby on Rails, I pored over it to, like,
the point of perfection. Partly I could because I think
the first version of Rails was literally a thousand lines of code. - Sure, yeah.
- I read those thousand lines of code, I mean, hundreds of
times, changing everything and making it perfect, right? Now Rails is not a thousand
lines of code, I don't even know how many lines of code it
is but, it's a lot, right, it does a lot. And I've just gone like, "Hey
lemme just make the rough "draft, let's get someone else involved, "let's work together with someone else "and then we can move forward with it." - Note snipes, so you just
love to like go out there, do a little note snipe like,
"Here's a thing that kind of, "it sort of does the right
thing" people are like, "No, I'm the expert on this,
it needs to go exactly like" "Perfect, can you just do it for me then?" I'm very susceptible to
those, as my coworkers will tell me as well, so. - Yes, it's a honey pot. - Yeah, (laughs) exactly. You know, as thinking about
like just the evolution of Rails as well, are there things,
if you look back on it, things that you've added and
taken away, or things that like, patterns maybe,
that don't work as well as they used to. I think that like, one of the
questions that somebody had was like, "What are we doing
with asset pipelines and how "that has migrated or changed over time?" And, I think I added in
here, do you still use table polymorphism and stuff like that. It's just like this was
good for now and now, eh, maybe you don't use it
anymore, that kinda stuff. - Yeah I think that's good. I think, with the asset
pipeline, we ended up building, essentially, like the transpiler approach, that has since taken off
immensely in JavaScript, before the JavaScript community
was really that interested in working on it, right? And, now they are and now
there's a bunch of great tooling for it, Rails doesn't have to
do that anymore, so we could pull back and go like, "You
know what the asset pipeline "doesn't need to be on the forefront "of the JavaScript development." Now, it's funny though
because then people go like, "Well why don't you just shift
completely, insist that all "assets are run through
that, CSS and everything else "goes through it" and I'm
like, "Because it's not better, "like have you tried actually
including CSS in web pack?" Fuck no, it's not a nice
experience, it's not great, it's not better than what we have. So, in that regard, I'm
very much like Ruby with the poly paradigm approach, like I'm a poly solution approach. Like, "Hey, let's keep the
asset pipeline in place "to do things like copying
images and dealing with CSS, "as long as it does that
better, in a nicer way to use "than the alternatives." I like Webpack for what
it does for JavaScript, we don't really tinker with
it, I think we use something that's pretty close to the
standard Webpack or config, it does that great, wonderful! And then, we use the
asset pipeline for CSS and a combination of
useful things, it's great! Like I don't have, there's a
lot of people, in programming, who have a very pure approach, right? Like, "I think that's part
of the appeal of JavaScript, "it's like I can use the one
language for both the backend "and the front end. "And like that means a lot to me." And I go like, "That means
nothing to me, nothing." I don't give a shit, in
fact it's even more militant than that, I think it's bad. There's a good group who've
been working on making essentially a Ruby to JavaScript
transpiler and I've heard a lot of the pitches
for it and they're like, "But it's Ruby and like
isn't that better?" And I'm like, "No, like
JavaScript is great "for what JavaScript does." I don't have this idea of
just, like, there's the one approach to everything. The same thing, and that goes
all the way back to thinking like SQL is not a bad language. Active Record has never taken
the approach that like SQL is this sort of demon that
needs to be exorcized. We've reduced the amount
of SQL you need to write, on a regular basis, I
don't write a lot of SQL, we used to write more because
Active Record didn't do as much, but it's not from
this perspective of like we have to eradicate it. We do the conceptual
compression but, when I look at something like, Ruby to
JavaScript transpiling, there's limited amounts
of conceptual compression, 'cause you still have to
understand the model of what it outputs into and like,
it's just, it's not for me. So, there's that, and
there's something else, which is sorta funny,
since we just talked about microservices, in I think about
like 2007 we had a framework called Active Resource, which
was essentially a service oriented approach like, "Hey, make a bunch of maps,
tie them together, you can talk "to them over http, boom, right?" And like, I used that
framework and we built a bunch of things on them and it's
in those scars that I draw the fierce opposition to microservices, and service oriented app
architectures in general, right? 'Cause I ran that shit and it sucked. And, you know what? It hasn't gotten materially
better, this idea that we replace a method call, or a SQL query with an http call, fuck no. As far as we can avoid it,
it doesn't mean always, - Sure.
- like there are times where it makes sense, I think
just the times that it makes sense, it's like 1% of the
time, compared to, sort of, this infatuation we've endured
over the past like five plus years, which is so funny
because it was in, sort of, version 1.0 of those, not even 1.0, 2.0, perhaps you can think Corbett before this, but like it was in a past
version of this same battle that Rails was born. The WS DeathStar was literally
the first kind of big ideological battle that Rails
picked up the other side of. Like, you have WS DeathStar,
which was this whole service oriented thing. - I remember it well, yeah. - Terrible sort of approach
to it right, it was J2E, it was a local and remote with Java Beans, it was all the same shit, right? And you go like, all the bad
ideas, all the zombie ideas of software development, they
are on the same treadmill as the good ideas. And they come in vogue, just
as frequently as the good ideas (chuckles) come back in
Vogue, and we go like, "Fuck night, I mean.." Yeah so this, it's interesting
to have been through a full clock cycle of that right? Like, I obviously, I got
started with Ruby on Rails, I hadn't gone through
any of the clock cycles, I'd just been on the first one. Now I've been through
a couple of the loops and you just go like,
"Yeah, it just does repeat." But anyway, Active Resource
was a thing that essentially was like, "Well, maybe there's
an okay way of doing services "oriented architectures"
and conclusion was, "No, no, don't." (laughter) Like, don't pretend that
what happens over the network is the same as what happens locally. - Sure.
- Like, that's one of the immutable laws of
distributed computing. Well, Law Number One is don't do it. Law Number Two is, if you
do do it, don't pretend that a method call is the same
as a service invocation, they're different time scales and they should actually feel different. That's the other thing
of this transpiling, making it all be the same
language, that I don't like. Like, different things have
different pressures like, when I'm calling a remote object, it shouldn't have the same
taste as calling a local, - Sure.
- it should look foreign, - Yeah.
- it should look weird, preferably it should even look bad, right? - Yeah.
- This is what the idea of syntactic vinegar comes from, the things you shouldn't do too often, they should look annoying and bad. - Unhmm, yeah, you know those
days of trying to make SOAP feel like it's just a thing
you call over the network, it's like we learned
like, yeah I mean, yeah! What's funny is I don't
think it takes either of our opinions to say that
it didn't work because, if you look around, like no
one writes SOAP apps now. Like, every single SOAP app
is like the far Legacy ones and I would say there are
probably more COBOL apps than there are SOAP apps,
at this point in time. (laughter) -Yes. - 'Cause COBOL being in
the news again today. - Yes, and I think the
same is going to be true for Microservices, people are
going to look back and like, the funny thing about
microservices is like, I don't even always know where
the limit is between sarcasm, and comedy, and reality. Like, I think I saw a
write-up where Uber had like thousands of microservices - Yes.
- I'm not sure - that's an actual, maybe
that's an overstatement, is that the actual
- No, no that was legit what that thing said, so. - Gotcha, okay, like that's
a thing that like people are going to find like in the ground, like 20 years from now,
like excavating things and you're like, "We did what? What?" Uhmm, yeah. - Yeah, I think that article
also talked about Uber starting to do macroservices,
to which a bunch of us said, "I think we already have a
name for those" but, anyway that's a different conversation, so. I think, you know, this has been great, I think we're getting
towards the end here. Oh wait, I guess I have
two, maybe, quickish ones. One was, you know, we were
talking about sorbet earlier, sort of typing and stuff like that. We have some questions about formatters, like syntax formatters
and stuff like that. I want to know, like, would
you, is that something that you'd be in favor of, I
mean, like Ruby's never really had that and so, it's sort
of becoming more a thing, in various programming languages. Just maybe give your
quick thoughts on that. - First thing I'm gonna say,
I do not have quick thoughts on that, I only have long thoughts. - (laughing) Okay, okay. - I have such a twisted tormented
relationship with linters and formatters, in general. And if there's one thing I
swear, sort of, at most in Ruby, it's probably RuboCop. We run RuboCop at Basecamp,
with an extremely limited set of rules, it's nothing
like the default thing but, even the extremely limited
set of rules has me swearing at the computer like almost
nothing else that I can imagine, and I'm at the point where
I'm like, I understand some of the benefits but I don't
actually think they're worth it. Like, I'm more on the side that
like, the amount of things, I'm willing to let a
formatter lecture me about, can fit on a fucking dime. Like you can tell me about
some spacing, maybe, at the end of the thing, start telling
me about how I line up my things, or where I use
parentheses, or whatever and you're in for a fight. In fact, Ruby, to me, so
much of the enjoyment in Ruby is these incredible
subtleties, of how many fucking different ways you can
structure a conditional. Like, Ruby has, I don't know
even the count, there's gotta be 60 different ways you
can say if something, right? And it is in those 60
different ways that I find half the enjoyment of writing Ruby. Like, it was one of those
things where I knew, very early on, that Python was
not a language for me because it said, right in the manifesto,
there should be preferably one and only one way to do things. Ruby has the exact opposite approach, there should be preferably
ten thousand subtle different ways of doing things, that
will allow you to write just that particular conditional,
with just the right emphasis, do you write it in the front,
do you put it at the back, is it multi-line, is it single line? Like, there's so much variety
and it's in that variety that I find poetry.
- Yeah. - And it is the poetry
of writing Ruby code, of making those subtle
distinctions where, at the end, you can like, "Ehh, should
we move it around" like, where I just go like,
(neighs like a horse), right? Like, this where like we
talked about that big smile, right?
- Yeah. - So much of that big smile
comes from, not just like solving the problem, but
solving it in a poetic way. And, this is where, (chuckles) it's funny, like, for me, Ruby is almost like the Torrent Test. By the time you can write a formatter, that can accurately appreciate
all these subtleties, like, we're gonna have general
purpose AI. (laughter) General purpose AI is just going
to be able to run the world because all that intricacy
is really difficult, it really is. And it's funny, where I know
that this is particular about Ruby is like, I don't quite feel the same thing about JavaScript. We also use a formatter on
JavaScript and JavaScript is just more constrained,
like it doesn't have as much of the subtlety, there
aren't 10,000 different ways of writing a conditional,
and sometimes that's the part that bothers me, right?
- Yeah sure. - But at least you have
some sort of constraints, but I think it also
goes to the root, right? The thing, the one most people
point to is the one from Go, I think perhaps that was the
one that kind of like started it, where a whole community went like, "Boom, we're gonna have a formatter." Go is fucking a new speak kind of language,
- Yeah. - it tried to reduce the
scope of the whole thing down to like, "Hey, could there
just be like five words, "that we say different ways?" And you have to build
everything down into the tiniest blocks and you build
everything up yourself. Ruby is English, in the sense of like, there's fucking 10,000 different
adjectives that mean just a subtle different slice or so. It's like the joke of, I don't
even know if this is true, but I remember hearing
it like in Newick or, I forget what the language
of Greenland is called, but there's like 13
different words for snow. - Yeah, right.
- Right? - And this is beautiful,
like this is not an error, like that language would be so
much worse off if it had just one word for snow.
- Right. - Ruby would be, Ruby would
suck if there was a formatter that said there's one way
you can say if something, I'd stop writing Ruby. So, yeah, not a big fan, very
much hope that it doesn't get included in the official
language in any way because, the other thing too is
Ruby has fucking dialects, this is like a cultural treasure, there's like Seattle style, there's like, I remember when I first read
the Ruby statement library and I could see all the dialects, in all the different
libraries, and I went like, "Here's what I like,
here's what I don't like", and then I wrote my own dialect, right?
- Right. - Not only could you
write in your own dialect, in terms of what Ruby you wanted, Active Support is the
Rails styled like the Ruby and allowing me to have my own
dialect and control over it, is just fucking spectacular. And, like there's so much
enjoyment out of that, I have such deep appreciation for that. It's one of those things
too where, we talked about, "Hey, what do you like,
what do you don't like?" You don't always know up front like, what turns out to be significant. The fact that Ruby is so
expressive and has 60 different ways of saying 'if', if that. It's one of those things
where like, in the beginning, maybe you didn't bring so
much thought into it but, now you see the blossoming
of culture that comes from that decision and you go
like, "Do not fuck with it", right?
- Yeah. - And it comes in turnkey,
it's the one way I try to very much restrict my commentary
on what goes into Ruby core because A. To me, almost all
of it is optional, I can just choose not to do it. And B. It's optional in the
ways where, if I have a better way I can just put it in Active Support, and I do it all the time. (laughter) For example the new _1 we
have for implicit yields in the box, it's one of
those things where like, you know what, I wish that didn't happen. And, I can imagine a fucking
formatter going like, "Hey, you're yielding a neg variable here, "let's replace that with
_1" and me just going like, "Shut the fuck up, it's
not going to happen, "over my dead body", right? - Or "This day is over,
close this laptop." - "This discussion is over!" Yeah, I think um, no, I have
a very tormented relationship with formatters and I very
begrudgingly use them. And, in fact, if anything,
I think, whatever formatting rules should be, they should
be far more constrained. Like, I like the one that
enforces, or that pulls me back from the temptation of
using single quotes, versus double quotes. Like I finally, after 15 years with Ruby, I came to the realization
that trying to do the subtle distinction, between single
quotes and double quotes, was not worth anyone's time and
even I kept getting it wrong so I committed to just
always using double quotes. - Yeah
- Uhmm, I'll take that. - The solace of formatting,
of linting then, yeah. Well this has been great, thank
you so much for your time, for doing this, I hope that
everything's going well at home and everybody's staying safe, and sane. And, I'm hoping that
I'll get to see you again in person soon and yeah.
- Likewise. Anything, you want to add,
per a, some kind of podcast, anything you'd like to
promote, here at the end. - Well, the funny thing is,
is that was like I'm a kind of, like, an involuntary
promoter, like an involuntary marketer, I just can't help it. Because I just get excited
about the things that I work on, right?
- Yeah. - It's why I work on them. I keep telling myself this
everyday, when I get up, like, "You know what, if you
don't wanna go to work "you don't have to." And, I tell myself that every
day because it ensures that, when I show up to work,
I work on the things I wanna work on. 'Cause why the fuck else
would I do it at this point? I don't have to, so that, it
kind of means that I end up working on things I'm
really interested in. Because I could just totally not do any of this fucking shit, right? So, the things I'm really
interested in right now is obviously Hey, it's our
new email service and email client, baked into one
thing, it's Hey.com, it's where I'm doing all my
work, research, extractions for new things in Rails. Like, whenever anyone sees like my byline, in the change logs, it's
always because I'm working on the next product, or
something else like that, and I'm just extracting shit out. I never just sit back
like, "Ohh, Sunday morning, "lemme put some new
features into Rails", right? That's not a thing that
happens, it is like I'm really excited about working on Hey
right now, so I work on Hey and then I go like, "Hey, to make Hey" ha! "To make Hey, Rails should
do this for me" right, "like why am I putting this
into my application code?" Bam, yank it out and put it in. Like, that's how we actually
already ended up with two frameworks, Action Mailbox
and Active Storage, both of those things were
extracted because I wanted to do Hey and we had that code in
Basecamp and we hadn't extracted it and like, I'm not fucking
pulling that shit over, I don't do copy/paste. Ah, sorry, so let's just put it back in. So, Hey is it, we're gonna
push it out hopefully, I dunno, this summer, maybe, lets
see where the world goes. And we were gonna put
it out, as we said, now. And I was gonna go talk
about it at RailsConf. But, like, hey, it'll come
soon enough and we'll pull all these things out and
I hope that this pendulum, that's swinging back on
the majestic monolith, there's another pendulum that's
also swinging back on APIs and on how to do the front end. And the pendulum's going
to come fucking back and we're gonna be ready,
with Turbolinks six and a bunch of other shit that
there's a complete cohesive story on it, I even have
a snazzy new name for it, that we're gonna put together. It's a whole unified theory
of how to build apps, like we build them at Basecamp,
I can't wait to share that. But, Hey, when that
comes out, is going to, it's going to show all of
it because it's all going to be in the box, that's
where it comes from. - I can't wait to see it, I know that most people can't either. So, thank you so much for
your time and I will see you when the world can travel again. - Yes, please, sounds great. Thank you so much for having
me, this has been a blast. - I agree, bye bye.
Already started? Yeah, timezones.
Damn I was really hoping to get a gleams of Hey.com and its tech stack.
Whoops!