 This was supposed to be replaced by the title of the talk. I never came up with the title, and then I thought, actually Fixed Me is a good title for this talk, so Fixed Me it is. As Evan has just said, I've been doing this for a while. In fact, I've been doing information systems, being involved in that world for 20 years, or thereabouts, which is a really weird thing for me to say because when I got started, I was about 20 years old, and this concept of being involved in an industry for two decades just seemed foreign. Now, I've been around for about two decades, and in some ways, things are no different, right? I have the same fire to fix the future, but instead of having that fueled in some ways by sort of youthful ignorance, which I think is a very valuable thing, and if one of the things I do miss from the past is that, that ignorance, that bliss, I have something else instead, which is a sense of history, and that sense of history is both a blessing and a curse. In some ways, it's an easy trap to fall into, to just reminisce and be content with what we did and where we were. In another way, it's a blessing because it gives you a sense of scale. The technology industry seems like it moves so incredibly quickly, right? Not a week goes by and something new is announced and you think, oh man, everything I knew is all of a sudden all they're outdated, when really the broad strokes, the titanic plates, they don't move all that fast. If you think about the main technology that underpins a lot of the applications that people in this room and that I work on, it's the relational database. It's basically been around in its current form for, I don't know how long, more than the 20 years that I should have looked that up, right? Like when it started in Paris, oh, the relational database was invented in 1954, but I don't actually know. So anyway, it's been around for a long time and it's still at the core of our applications, a lot of applications. We've had other forms of storage come and in many senses go and things have changed, but in an industry that supposedly moves so quickly, it's still interesting to think about the fact that one of those core pieces has been around for so long. Ruby itself has been around for 25 years now. But in that time, things have still changed. Even if some of the things stay the same, some of the things do change. One of the things that have changed since I started is this notion of the DBA, the database administrator, the person whose job it is to guard this precious data store from the savages application developers. This guardian role when I got started about 20 years ago was pretty common. You didn't have to be that big of a team before you had someone whose job was to defend the database. Now I'd be surprised if most people in this room are on teams that have a full-time DBA. Why did that change? What happened to the relational database and to our industry system we no longer needed in most teams, the DBA? It's not that this role is entirely extinct. It's just exotic. You have to go to exotic places and exotic companies, very large institutions before you find this again. It's not sort of commonplace in small and medium-sized businesses. What happened? So some of what happened was advances just in the underlying hard room, right? One of the reasons we had DBAs were to make sure that the relational database stayed performant. Now the ceiling for what a database can do without having someone who's a trained professional tinker with it all day is so much higher, right? We've raised the ceiling through technological progress in such a way we don't have to spend all day having someone just tweak the dials in such a way that it won't fall over. In fact, at Basecamp, where I work, we have a relatively large database. We've managed to launch all sorts of features with the wrong indexes to tens of thousands of not hundreds of thousands of people and not realize it until it fell over like three months later, right? That is progress. There's progress in how long we're allowed to stay ignorant about the underlying fundamentals of technology we use. And I mean that seriously, not glibly, that that is actually progress. The fact that we can push out considerations that before had to be made up front and very early in the process is a huge step forward. But the role of the DBA, I'd say, is classical creative destruction. That we used to have this role in our industry that employed as a percentage of the people who were in the industry a fair number of people. And today, we don't, right? It's kind of gone away to some notion. And it's not just the role, it's not just the DBA. It's also a bunch of techniques that revolve around this relational database, this core of our applications. One of those techniques is a technique called sharding. So sharding is this concept where when you reach a certain tipping point in how much data you store and how many people were accessing that data, you start splitting up your single database in multiple databases such that customers one through 10,000 goes to this database and 10,000 through 20,000 go to this database. And that adds a fair amount of complexity, right? Before you had one database and you had to worry about migrating one database, operating one database, accessing one database, then you shard your database and all of a sudden you have that problem times N. Now, sharding came into my world around 2007 or so. We were at base camp just getting towards the ceiling of what we could do with a single database. And we started doing our projections and we see, oh, we're sort of getting so and so much new data every month in X amount of months. Like, we're really, we're gonna have the ceiling here. We run out of cash storage for the database. If we're gonna have to hit these spinning disks, then we're gonna be in trouble. So it's actually funny. Mark Embriaco, who's speaking at the end of the day of the keynote, was, I believe at the time, the sole system administrator at base camp. And we were talking about this, oh, we really need to put time aside to do sharding. We need to figure out the techniques to do it. We need to set it up. We need to block away time. And we're like, oh, this sounds like it's gonna be a long process. It's gonna be a long project. Are we gonna take those three months or whatever it's going to be to do it? And I sort of treated this with the same approach that I treat a lot of things. Ah, let's worry about it tomorrow. And tomorrow came, right? And we're like, oh, we got a little closer to the limit. But hey, do you know what? Now we can, these boxes that we have I forget the history specifically, maybe it was a rack space. Oh, rack space now has an option that we can get some more ramps so we can extend our cash storage. And we get a little more time. But I mean, we're still gonna need to do it, right? Like for sure, there's no way that we can wait more than at least another year. All right, so then the other year came around. And again, we got bailed out by technology. I think the big bailout came when SSDs became a thing, right? Like when we were no longer spinning disks around and all of a sudden the ceiling just jumped an order of magnitude. To this day, all versions of Basecamp have avoided sharding. We don't shard any of our applications. All of our applications have one main database that's being written to. Then we have some replicas that are being read from. But that doesn't have really any material complexity compared to sort of sharding and splitting things up into separate databases. We were able to wait it out, let creative destruction and technological progress and software progress take a whole problem and basically we don't need to do that. Oh, by the way, we don't employ any DBAs at Basecamp either. Here's a human side of it and a pattern side of it that we no longer need to deal with at all. That's real progress, right? We're still dealing with the relational database, but we've taken these facets of it that used to be absolutely givens that once you reach a certain size, you had to have DBA and you had to do things like sharding and we don't need to do that anymore. Now, that progress when you look back at it now over the course of 20 years seems just obvious, like of course, right? And it's a little easier in these two cases, although I'm sure you'll find people staunchly advocate for both getting ready for sharding and getting ready for hiring a DBA. And at some point you do need to do these things. There's also plenty of, I'm sure, GitHub or other large scale applications that reach sort of close to internet scale or they're about, of course they need to do sharding, but it's become an exotic technique just like the DBA has become a bit of an exotic role. Now, some of this progress doesn't happen sort of as smoothly or as cleanly as in just, oh, we stopped doing these things. When I first started working on active record, programs were controversial. There were actually real debates about whether it was a good idea to wrap the relational database in an object interface because you know what, like how can your API, how can something like active record be as performant or as efficient as hand-ridden SQL statements? We debated these things, right? And there were a lot of people like, oh, I'm never gonna use a ORM, like you're just lazy if you don't just write your own SQL. And by the way, you're gonna hit all these problems and you're gonna hit all these issues. If you do that, like imagine all the queries that an ORM untuned can kick off, and it can. I know that because the vast majority of pages, again, at Basecamp are untuned. I've recently done a couple of performance dives and when I look at the number of SQL queries that active record will kick off on a single page in Basecamp, it's sometimes hundreds. If you told that to sort of people 10, 15 years ago that like, oh, we'd just be kicking off willy-nilly hundreds of SQL queries on a single page for a single user, they'd be like, you're out of your mind. There's no way you can make that perform. But we did, right? Progress, both in terms of technology and in terms of the API, allowed it to move to a higher level. That higher level was one where we no longer needed to deal most of the time, most of our days with SQL, even though, again, the relational database is absolutely at the core of what we do. Now there's a pattern here, that even though something remains at the core of what we do, and even though at times we do need to dive into it, and there will be use cases where we need sort of the past exotica of techniques and people and roles, most of the time we don't need to worry about it. In much the same way that like, hey, the CPU is at the core of a lot of what we do, we don't need to worry about assembler anymore, right? We don't need to worry about things like garbage collection most of the time. It used to be a huge thing that people worried intensely about all the time. There's no way a garbage collector can be efficient enough for us to be able to fit our system into the memory that we have. And now in the Ruby community, the only person who has to worry about garbage collection is pretty much Aaron and the rest of Ruby Core. That's real progress. We've taken all our problems and given them to Aaron. And now if our Rails program uses too much memory, we can just shell Aaron, fix it. That's great, right? That's real progress that we can just always be blaming one person and we don't no longer need to really learn these fundamentals. And that's what I love about that word fundamentals because usually programmers, when they speak about fundamentals, they speak in these tones about like everyone should really learn the fundamentals, right? There's a lot of fundamentals in software development that no one learns anymore. No one who just works on information systems need to know the intricacies of how a CPU works. They might still, if they want to, or they might end up in a specialized role where they need to. And we're getting to that point with other things, right? No SQL used to mean that people were using a non-relational database and losing all their data. But now no SQL really means you get to use a relational database without writing any SQL. I'd be surprised if most people in this room write SQL, fully form SQL statements on a daily basis. Right? We just don't do that anymore. When I got started again 20 years ago, I would write fully formed SQL statements at the top of my PHP script and I would embed the parameters straight from the web request, right? Thankfully we don't do that anymore. And generally speaking, we just, we don't need to write SQL anymore. It's not that we're not using it just in the same way we continue to use assembler. It's just that we don't see it and we don't write it. In some ways we've moved so far up the chain that SQL to some extent and in some capacity is like a form of a sampler. It's a low level language that we occasionally need to dig into but most of the time we can just blissfully ignore and be all the better for it. In fact, I just, as I was putting these slides together, look through the Basecamp 3 code base which is relatively large code base, hundreds of screens and multiple hundreds of models. We do not have a single fully formed SQL statement in any of that code, right? We used to when we made the first versions of ActiveRecord we're still sort of at a preliminary early stage and we still occasionally need to dip down and now we don't anymore. This is one of those things that just become apparent when you look over the arc of something like 20 years and like, oh yeah, we used to do all these things and now we don't do them anymore. Now some of that, as I said, comes automatically. It comes for free. It comes because we get SSDs, we get cheap RAM, we get faster CPUs, we get all this stuff that just sort of shows up and makes our lives easier and all of a sudden there's this tipping point that we may not even notice when certain things just no longer necessary. The other part of this, which is the part that I'm really interested in, is the part that I actually have an impact on and that we have an impact on is conceptual compression. This idea that we have a multitude of concepts that we need to worry about and tangle and juggle as we're making applications and at certain periods and times, certain concepts loom very large. SQL used to loom very large and you had to really study your SQL and figure out how to write it and have that top of mind to be able to make applications. Today again, if you ask me, can you write a fully formed insert statement on the spot right now on the blackboard? I'd probably get it wrong, right? Like I forget where the parentheses went and that's not even to speak about joint statements or any of the more complicated usages of SQL. It's just not something that's top of mind anymore. I used to write that stuff all the time and then through progress, through ORMs, through ActiveRecord, we managed to compress that concept into something that's maybe a tenth or a hundredth of the size that what it used to be. Now, conceptual compression, I think, is probably the most important thing that we're doing in the Rails development. It's the most important thing for me as I think through what should I work on and how should we progress because there are all these concepts and I'll talk about how in some ways we're losing the battle on this compression front and then there are more and more concepts that are being forced upon us that if we don't compress the ones we're getting a greater and deeper understanding of, we just won't have room in our head for the new ones we need to worry about. Now, up until this point, I think it sounds not controversial, right? Like we all want to compress concepts at least in theory, but I think in practice, it's different. I think one of the reasons it's different is because a lot of programmers like to play with Legos. And I like to play with Legos. I mean, that's not really saying that much because I'm pretty much nationally obligated as a dain to like Legos, but nonetheless, I like playing with Legos. It's fun to put things together. It's fun to build things from scratch. It's fun to build things from individual small pieces. The problem, I think, comes in is once you get used to a certain size of blocks, oh, we have this two by eight here. Like this is the size of the block I start putting together. You kind of start thinking about that, that is your world. And like this is a choice that I'm making about the size of the block that I'm putting together. And that's really important because, hey, this is what I used to be doing all the time. So of course it's important because what I do is important. Now, sometimes the size of the block changes, right? And a lot of people will be like, no, no, no, no, that's too coarsely. Like that's a toy, like that's Duplo. Like Duplo is for fucking kids. I'm an adult, I play with goddamn Legos, right? I like the size of my blocks. And I think that that's what we went through with ORMs, controversy, with the idea that like you shouldn't be handwriting your sequel most of the time. Is that like, if you were used to writing your sequel most of the time, you went like, what the fuck? Like, now you're telling me that I shouldn't be putting these blocks together individually anymore. That's just wrong, because you know what? Like I can build anything with my blocks. I can build a goddamn millennial falcon with my blocks. And look at that, isn't that cool? Yeah, it's cool. You're building things with blocks. And I mean, I appreciate the sort of memory that goes into that and the dexterity that goes into that. But if we all just want the millennial falcon, why are we all fucking building it from scratch? You can buy that shit on Amazon preassembled. And like look at the fidelity there. Like what crude imitation of the millennial falcon is that compared to that? That actually kind of looks like the same thing. But we sort of get lulled into the belief that unless I build it myself, like it's really not as brittle and as ugly and whatever as this thing. We have this sense of innate ownership, I think that comes in from when we build something from the small pieces. But it's not that helpful. And we're doing it self-indulgent play, right? You're not building the millennial falcon out of Legos because you get a better millennial falcon, right? Like it's a little bit like what we used to call like this home-rolled framework, right? You can get something that kind of works and it's fun to play with. But like, hey, if you just put industrial processes together and build on top of sort of decades of production techniques honed by people, you'll get a better product. And I think that that's sort of the hard part. That's why this notion of conceptual compression sounds appealing when you're talking about it in the abstract, but as soon as you start applying it to real concepts, concepts that you use to worry about all the time, it gets a lot more dicey. But yet we must. If you look at the history of Ruby and Rails, been around for about 15 years now, and over that arc, when I'm looking back at it in my Rose College glasses, I like to think that what we've been doing is a lot of this conceptual compression. But we've taken a lot of concepts that people use to worry about and have to figure out from first principles and then we've turned them into something that most people don't have to worry about most of the time. And by doing so, we've pushed out the need for specialization and sophistication. That a single programmer today can start sooner with less knowledge and build better things. That is a monumental improvement. The fact that we've been able to sort of collapse things to a point where a generalist can do what a team used to be able to require it to do is real progress. Because I think the problem is when you push into these areas of specialization, when you get concepts that are so large, at least uncompressed, that they have to occupy the mind of a single individual or take up a large sphere of them, you get too much mind space to worry about that thing. The DBA who used to do that as full-time job had all day to think about the risk factors and all the nasty scenarios that could happen if you just let these unwashed programmers write their own stored procedures. All of these factors that sort of could go wrong, they got to worry about that and tinker with it all day, that's just too much brain to apply to one problem. And I think we're sort of standing on that balance with a lot of concepts that the concepts seemed like, well, this is really a whole thing. We need to make this a person's job to do this thing rather than think, yeah, right now, this concept is quite large and it'll occupy most of the brain space of someone, but if we compress it, it won't. We can fit it in alongside all the other concepts that we need to do. And that that's a better model, that it's a better model to search for ways to compress the concepts that we need to juggle rather than search for people who can fathom the complexity of the problems and the concepts that we're dealing with. So when I think about, as a framework builder, what is it that I do? And where is it that I want to spend my time? It is to think about it in the sense that can we take a concept and basically compress it in such a way that we can get 80% of the value of that concept in about 20% of the effort or better, right? Like that's just one compression rate. In many cases, we've gotten even better compression rates. I'd say the compression rate around SQL right now is like one to 20. We spent like 5% of the time on SQL that we used to spend on it and that's real progress. Because as I said, the list of things you ought to know as a developer grows all the time, right? That's some of where the sense of, oh, shit is moving so fast and I can't keep up comes from because there's so many things that are constantly popping up and mostly informed of new concepts that all of a sudden, oh, I need to worry about this too now, security, right? I think security is far more at the forefront of people's mind than it was 20 years ago when we just string interpolated query parameters straight from their request most of the time when we had all these ways of injection and we just didn't really, it was there, right? The concept was there. Most people just didn't focus about it because they were so busy focusing on things like how do I write a performance SQL query. Now when we free up space by compressing the existing battery or contents that we need to deal with, we have the space to spend on other things. But yet still, the list of things you ought to know keeps growing and the problem with that is it increases the barrier to entry. The more shit, the more concepts that you're required to know before you kind of feel like you're just basically proficient in this industry of building information systems and web systems, the harder it is to get started. The fewer people feel like that's something that they could actually do. Again, if I look at the history of Ruby and Rails, the usages of the framework that I'm most proud of, the emails that I get that makes me smile the most is not some large company that Ruby is. Hey, do you know what we measured this? Rails made a 17.5% more efficient and productive and that has really helped our bottom line. I don't give a shit. I don't really care about those forms of progress. What I care about is when I get an email from like, hey, do you know what, I used to be a musician and I wanted to create a website for other musicians to do this, that, and the other thing. I didn't think I could do this at all. I was not a programmer. Then I read this Rails tutorial. I figured out how to do things and like, hey, look at my site. There's like 10,000 musicians on that now doing that. You're like, holy shit, that is really a change, right? If I go back 20 years and think about who were the people, who were the organizations that were allowed to launch like information systems and build them and the process and so on that you were required to do, those are not the same people, right? You did not get the amount of stories from people like that. The advance of boot camps, the fact that you can take someone who just has a basic understanding or none at all about programming and in about three to X amount of months, you can turn out someone who's like juniorly proficient in what we do. That is amazing. And that is a real gift that I think we're not treating with the respect that we should. That's an industry. And that the fact that we've managed to compress so many of these concepts to the point where someone can not only not need to deal with SQL on a daily basis, but not even really understand what SQL is and how it works. That's amazing. That is such fantastic progress, which is funny because again if you think about it in the sense of the term fundamentals, there'd certainly be a lot of programs that would say like that is negligent, right? Like you are not a serious developer of information systems if you do not understand the asset tests or any of the other elements of relational databases and certainly SQL is just a bare minimum you need to fully grasp to be able to be allowed to make applications. Fuck off. Absolutely not. The more we lower the barriers to entry, the wider the pool of people we can attract and allow to build applications to start on the road. How is that not a good thing, right? And I think that there's sort of some insecurities wrapped up into this that if you tie your sense of self-worth as a programmer into like this is really hard and what I do every day is really hard and you have to be so fucking smart to get this and then someone who just goes through a bootcamp of three months shows up and does sort of kind of the same thing that you do, then if your ego is sort of a little fragile, maybe that looks like a threat. But it's a good threat. It's an expanding threat, right? It's not like there's 10,000 applications that need to be made every year and those are the applications that we're all competing to be able to be allowed to work on. Absolutely not. Most of these people who are coming into the industry are expanding the pie, right? Like making more new applications. The number of applications in fact that I've talked to the founders of where they basically went like, yeah, I didn't know what the fuck I was doing but this thing totally took off and all of a sudden we were getting lots of customers and then I hired a bunch of real professionals who kind of knew what they were doing. There's a lot of those stories and those stories are good. And that is a way, I think, where we've sort of helped progress and where compression of concepts take us by lowering these barriers, by reducing the list of things you really ought to know such that you can get a basic proficiency in a three month bootcamp. Now my favorite technique to attack this problem of reducing the list of things you ought to know is leaky abstractions. So leaky abstractions was originally coined, I believe, as sort of a derogatory term against abstractions and frameworks and libraries that did not yet fully encapsulate and cover all the complexity of the thing that they were wrapping, right? For example, the first version of ActiveRecord still required you to write a substantial amount of SQL. You couldn't just use ActiveRecord and expect to get your whole application done if you didn't know SQL. It was sort of like one step up and one level above but it was quite leaky. A lot of the time you had to deal with sort of the underpinnings of it. This is how all abstractions start, right? This is why we need to embrace leaky abstractions, not hold on to the fact that no, actually for all eternity, every program in the world has to know all the intricacies of this concept because that's what makes them professional. No, leaky abstractions is how we get to solid abstractions. If you look at the path of the history of ActiveRecord, I think it's a perfect parallel to that. It started out extremely leaky as sort of just a leg up of making some things a little easier and it ended up in this magical place where it is now where people can use it and not know what the fuck SQL is, right? That is a progression that's amazing and it came through this leaky abstractions. We need more leaky abstractions, not fewer because the leaky abstractions we start today are the solid abstractions of five years from now. So unless we start planting these seeds, we're not gonna have the trees that we want. Leaky abstractions, even as they are in the initial implementation of them, are form of just-in-time learning, JIT learning, that maybe as the leaky abstraction is sort of getting rounded, there will be these obvious pitfalls that you fall into and occasionally you will have to learn something but we get to push that point out further. Again, you get to start, even with the first version of ActiveRecord, with less that you have to learn, right? Lists of things that you absolutely need to learn to make this basic form work, there's less of that, right? A lot of the sort of, I find, interesting critiques of something like Rails, which has this unending appetite for leaky abstractions, unending appetite for conceptual compression, is that there's too much of that, right? That there's too many concepts in Rails, actually. We've compressed too many things, which means that there's too much code and if you wanted to understand the entire framework and you had to read it through from start to finish, that would take a long time. Well, don't do that. Like who the hell in here understands the entire Rails framework? I sure as fuck don't. I have not read the entire Rails framework in a very long time and there are plenty of the concepts in the Rails framework that have been compressed so well that I don't need to worry about them anymore and I put them completely out of mind. If you ask me any questions about the Rails router, for example, I just go, I don't know. I know how the API is supposed to work. I know how I want it to work, but how it's actually implemented? I ask Aaron, that's his problem. And this is that buffet of just-in-time learning. You don't need to understand all of Rails, not on your day one, not on year one, and not as in my case, on year 15, right? You can push that out and reserve the time for learning whatever it is that you need to learn to the point when you need to learn it, right? When you need to do this specific thing or you've hit this problem that you want to do better at or you want to change or you want to upgrade or you simply have to deal with because your application is crashing or too slow, that's the time to learn it, it's the perfect time to learn it. If we shove all the learning up front, that you have to learn all the concepts before you're even allowed to begin, that list of things you ought to know is going to be a five-year curriculum. Who has time for a five-year curriculum? Why is that even a good thing? It's like memorizing all the states or the capitals of the world. Do you know what, I just, I don't care. I don't need to know that, it doesn't need to be in my brain all the time. I don't need it on speed recall. I can look that shit up. Most of technology is like that, right? If you just have the rough outline of a concept existing in the world, you don't actually need to internalize all that concept and keep it in your working memory on a day-to-day basis. Okay. Now, the second part of this is, one thing is we want to make it easier to learn, right? We want to make it easy to learn so that a bootcamp of three months can be sufficient, not even a bootcamp, a real tutorial for someone who's interested in just reading on nights or whatever can be sufficient for someone to learn just to bare minimum so that they can get started. Because the corollary of that is we also make it easier to launch, right? The fewer concepts that you need to operate and juggle to learn is also the fewer concepts that you need to operate and juggle to launch. Now, I think a great example of this is Twitter. So Twitter was launched on Ruby on Rails by a bunch of people who, by all accounts of what happened later, had no fucking clue what they were doing, right? No clue, not on the business side, not on the conceptual side, not on the technical side, not on the architecture side, no clue. If such a motley crew of characters can come up with Twitter and sustain it to this day, where we can all look at an application that had its roots in Ruby on Rails and think, this might be how it ends. The nuclear apocalypse might come tomorrow because of the thing we helped create. Now, that is a deep sense of satisfaction in the world. A sense of real imprint on the probability of the continuation of our species. Now, not a lot of people get to take such a pride in their work. So, the funny thing with Twitter, of course, is that it's sort of the most iconic case of someone starting on Ruby on Rails, then hitting some problems, some failed whales that they took and extraordinary amount of time to fix, and then when they fixed it, a lot of tales respond of whose fault that was because surely it was not the motley crew of people who worked on it, right? There's much easier solutions. It was the color of the Lego blocks, clearly, right? They were just the wrong color. They didn't fit together just right for the persons who were building it. And yet, Twitter, supposedly, I think, moved on from Ruby on Rails like seven, eight years ago or something and moved to a wonderful, efficient Java platform. And then in about seven or eight years, nothing fucking happened. The entire application is exactly the same as the one they arrived at through the experimentation of the early days with Ruby on Rails, which I think goes exactly to that point of easy to launch, right? When Twitter first got started, it was this thing where you would SMS your friends such that they knew which bar you were at, right? They didn't have the concept that this was, at one point, going to be the siren of our impending doom. They didn't architect it in such a way that you'd have the president send tweets out to 50 million people who then spread further still. They didn't know what they were doing, right? They needed low barriers of entry such that a few people who barely knew what they were doing could come up with a concept, iterate on it, and get to the point like, oh, okay, I guess this thing is good enough now, let's pour the concrete and change nothing for the next seven or eight years while we make it fast and perform it. That's a success story, a huge success story because if you were thinking like, hey, what if they had applied the techniques that they're currently using to operate the site on day one, right? That what if they had used the tools and the techniques that they're now using, the team sizes that they now have to build the initial version and figure out what this thing actually was, they would never have fucking figured that out, right? It would have been a concrete version of like, let me send an SMS to my friends if they didn't know which bar I'm at. Maybe that's nice, but it's not Twitter, right? And I think the summary of that point is if we want to have a broader set of people be involved in technology, we need to reduce the barriers of entry for access to that technology because it's one thing to be a user of technology and we can complain and there's plenty of users of Twitter here and they certainly use that service to complain. It's something else to be an actual maker of technology and have the tools of production in your own hands and have an actual chance of charting out new and alternative futures. And unless we widen the pool of people who have access to those tools and who are working on that future, we're gonna get the future of tomorrow be the past of yesterday. I think that's a math word. That we cannot expect different outcomes if we apply the same people to the same problems. If we apply the same people within the same confines and constraints of both technical systems and economic systems and all sorts of other systems, we need a broader base. Otherwise we're not gonna get a broader set of solutions. Now, some of this feels like I'm rehashing old battles here and it is because that's kind of fun. But it's also really not the important part. The important part is not to look like oh, what Twitter used to do or like oh, people used to think ORM's couldn't do this, that or the other thing, ha ha ha. It's more the sense that we should use history, we should use the past to inform the present and the future. That we should look back over this arc of 20 years of conceptual compression and the advances that we've made and ensure that at the very least we hold our goddamn ground. We've gotten to a great place with information technology. We've lowered the barriers of entry so much. It's amazing and it really is amazing when you look over that 20 year period and you look at the kinds of people and the resources that are required to launch something and make something today because those two worlds look quite very different and the one we have today in many ways is so much better, right? So that's worth protecting. It's worth guarding. What I see happening though, in large extents right now, is a lot of backsliding. That we have these amazing accomplishments and achievements and we're letting them erode. We're letting them sort of fall backwards. That the industry at large is currently focused a lot on conceptual expansion. That we're introducing a whole lot of new ideas which is great in some sense but we're letting them balloon and blow to the point where it's so much harder to reason about and feel comfortable about. I can build a whole thing, right? If I want to build a so-called modern web application today how much stuff do I need to know? How many concepts do I need to juggle to be sort of on par? If you look at the supposed requirements today, 2018 versus the supposed requirements of let's say, 2005 or 2008, they're much worse. We made the list of things you ought to know or supposedly ought to know much longer which is part of raising those barriers because yes, we've still compressed the compressions we did are still there but if we sort of impart the idea that you also have to do all these other things it doesn't really help that much, right? Which pushes you into sort of two boundaries. Either people just give up and say like, all right, this has just gotten too complex for me. I have to know what this spa thing is. I have to know what this microservices thing is. I have to build a native app. I have to, that's not for me. Technology's not for me. This is too complicated. Or people go the other direction which is like, I should just specialize, right? I'll just pick one thing and I'll become the best goddamn react expert there is. Now I can't do anything on my own because I just know this one part of the puzzle but at least I can get hired by a big company making big software, yay. That is a form of progress, right? It's just not the kind of progress that I'm particularly excited about and not the kind of progress that I want you to be excited about. Now, you have to be careful of course. There's a lot of sort of nostalgia about this and I'm certainly not immune to the charge of thinking like oh yeah, you like 2005 because that was sort of like when Rails came out and like there was a lot of energy around that and now it's just nostalgia and we're just harking back and wishing that yesterday still existed and it just doesn't because the requirements changed. And there's some truth to that but it's sort of not the whole picture and it's the problem is when we sort of set a new baseline, right? It's not that new ideas aren't good. It's that we have to be cognizant of what it is that we're doing and how we're approaching it. So it's that we don't end up with this new baseline that is so much higher in terms of complexity in terms of who it is we allow to make new applications that can have an impact on the world that we cut that off, right? We had these extraordinary gains. We made all these monumental leaps of conceptual compression and if we wash all that away by introducing just a avalanche of new uncompressed concepts and don't work on compressing those concepts and just work on finding more and new ones, we're gonna lose. And I think it's kind of, it's a loss that you don't sense until it's sort of too late. And that's what sort of this look back, this idea of letting history inform us can help us with, be instructive, comparative. How was it to develop things in 1995 versus 2005 versus 2015? How does the curve look? In which areas were we most welcoming, most open, most approachable and can we guard those things? Because if we don't guard these things, I'm pretty sure the WAS Death Star is going to get rebuilt. We defeated this monstrosity back in the early 2000s which WAS Death Star, which was I think my first presentation on Rails, ran it against this notion that was going on at the time which was this proliferation of crazily complicated and convoluted protocols for how web services could talk to each other, right? And you had like 45 standards and they were getting pushed by IBM and Sun and whatever, this was the future. And it was an incompatible, overly complex, complete utter mess that bred specialization and it bred all the ills that I've been talking about and it represented one possible future that this was the way and the direction that web services and websites and wherever was going to go in this complicated, overly specialized sort of way. Then the rebels mounted an attack and that attack took forms in a lot of sort of disjointed things. It wasn't necessarily a concerted effort. It was things like rediscovering REST, the basic architectural principles of the web, figuring out that you know what, XML is actually not that great and we can just use JSON. Like it doesn't matter if any of this specialization and these attributes and whatever, we could take that entire ball of complicated WAGs and just say, you know what, doesn't matter. Complex or conceptual compression for sure. We could take the whole set of convoluted protocols and basically just replace them with things like webhooks which basically just says, hey, do you know what, I'm just gonna send you some JSON to this URL when you're done. You hardly even need a spec for that, right? Again, conceptual, not just compression, but counter attack. And I think we are at that point with a lot of the concepts we're currently wrestling with in the industry that it can go either way. We can either continue to rebuild the desktop and get more complicated and more convoluted and more specialized or we can mount a counter attack again. And that's where again, you have to be careful with this notion of nostalgia because it's not that we want to go back and think like, oh, these things didn't happen or native didn't happen or mobile phones didn't happen or any of these things didn't happen is that you want to take those things and embrace them with the principles that we applied in the past. Not the actual past, but the lessons that we learned. And I think that that's some of the backsliding that's currently going on, that some of these lessons that we learned in our community, they're sort of evaporating. And I think that that's a damn shame because I think what happens when we get into these deep dives of complexity and specialization is in some part, it contributes to this idea of being alienated from the product of our labor. When the product of our labor and the things that we make become less and less tangible and your specific input on it becomes more and more diffuse because you're just working on one isolated little box of it. It becomes so much easier sort of to lose your connection to that, what you're actually working on and what that impact on the world actually is. Harry Braverman as this quote that I've liked since I started a very cursory dive into Marxist literature, which is an interesting dive in itself because there's certainly a lot of history there and some bad outcomes, but just because you don't like someone's prescriptions of what you should do about certain problems, doesn't mean that you can't recognize the insights that their diagnosis brings. And I think as of right now, the diagnosis from Marxist literature is incredibly timely for our time. Harry, who was writing in the 70s here, the red shirt in the back, thank you. While the social division of labor sub-divides society, the detailed division of labor sub-divides humans. And while the sub-division of society may enhance the individual and the species, the sub-division of the individual when carried on without regard to the human capabilities and needs is a crime against the person and humanity. Now, the social division of labor refers to the notion that we don't all know how to make shoes and be plumbers and whatever, that there are these broad industries that we fall into versus the detailed division of labor is when you take something like, oh, programmer who can build a variation system and relegates it to, oh, a spec specialist on the WS Death Star spec number 42 regarding transactions. That is a detailed division of labor that alienates us from the product of our work and makes it harder for us to sort of invite it and broaden the base. Now, the more alienated we get from the product of our labor, the easier it becomes to commit software iatrogenics. iatrogenics is this concept of, for medicine, doctors trying to do well ending up harming the patient. Nesim Taleb has written a bunch about this and how iatrogenics applies to a bunch of other professions including economics and so forth were supposedly specialized wise people end up harming their patients and their constituents. I think software right now is at its low point in that regard. Software has never harmed more people than it does right now. It's also never helped more people than it does right now but these two things aren't invariably linked. We can help a lot of people without also harming a lot of people. And I think the sort of lack of acceptance of that responsibility that we as software developers have to not harm the patient is minuscule and relegated to sort of a small subset corner that doesn't seem like it applies directly to what it is that we do every day when it's at the absolute core of what it is that we do every day. And I think that these things are linked. The more specialized you are, the more deep and narrow you are, the stronger are your blinders. The harder it is to see the bigger picture and the easier it is to defend for yourself and for others what it is that you're doing. Now, this plays in particularly I think in our time right now because we've been colonized. The new world of the internet has been colonized by a small set of very successful conquistadors. And they're taking this promise, this new world, and turning it into a kind of a shitty place. Now, they're getting fabulously wealthy in the process by extracting our attention, our privacy through monopolies and other forms. And that's bringing some progress in some regards, but I don't think we fully understood the trade that the conquistadors showed up with cheap mirrors and shitty combs and traded us our most valuable aspects of humanity. And I think that that trade needs a counter. That it doesn't have to be this way. And again, history is an instructive guide that it didn't use to be this way. The internet didn't use to be colonized in the way that it is now. Yes, in some forms actually it was colonized through Prodigy and AOL and other sort of portals at the time, but then we had sort of a glorious time in the middle where there were far more options, there was far more competition, and power and wealth in some regards was not concentrated in the hands of this little elite. Now, this is all happening in our backyard. This is not some external thing that's going on. This is us, this is our profession. This is what it's been used for. We have a responsibility to do something about that. Just to the point, Piketty author put out this very long book that basically justified this equation. That the rate of return on capital is greater than the growth of the economy. In no place is this more true than in technology. 89% of all new advertisement spending goes to two companies, Facebook and Google. While they're also busy gobbling up the rest of what was of that industry before it, that's not good for anyone than perhaps the people who happen to own Facebook and Google are the shareholders. That's a regression for the world that we're concentrating wealth and industry in this form. And again, we have a responsibility to do something about that. And I think it simply will not do that we as the implementers of these visions and these systems just close our eyes, close our ears and stop talking about it. The easiest thing we can do is just to step back, dive into our specializations, dive into our technology and say, no, no, that's it, that's just my birth. That's where I'm at, right? So when I look at what my mission is, what our mission should be, the mission that I want to inspire people to join, it's the idea of liberating the best ideas. So when Rails first got started, I had some choice words, let's call them that for the Java and J2E community. Those choice words were not based on the fact that there weren't good ideas. In fact, they were based on the fact that there were good ideas, lots of them, but they were trapped inside these conceptual cages. And then we could open those cages and we could take those wonderful concepts out and we could distribute them more widely such that more people could use these level of progress and patterns and ideas for how to build information systems, but that it had to be liberated. That the ideas trapped inside these cages were only accessible to a select few. Once we've taken these best ideas out and I want to take those best ideas out through conceptual and compression, leaky abstractions, these techniques that I've discussed, we can arm the rebels. When we arm the rebels, we get a chance, at least a chance, to fight back. Fight back on the technical level, fight back on the societal level, fight back on the economical level, fight back and return to a notion of things that worked and reject the things that didn't. Because software is eating the world. There's no denying that and we cannot turn that clock back. It's not like that's going to stop. But who's writing that software? You are. If you're writing that software that is eating the world, how do you not have a moral and ethical obligation to steer that? Of course you do. And being blind to that, not gonna help us, it's just gonna delay the inevitable. So let's do this work. Let's continue to compress the concepts that are worth keeping, reject the ones that aren't, broaden the base of people who can actually have a chance to write this software that's eating the world, such that the software that we end up with is software that benefits the world. Thank you very much.