 I'm really excited to see the show of hands of just how many people are here new and fresh and excited because I woke up this morning and I was sort of getting ready for my talk and I realized sort of as an image of how I act myself sometimes that when you've been around for a while you kind of develop this sort of a little bit harder shell a little bit more skepticism. Let's just put it about that about what you're gonna see because you've been here before and maybe you've been to RailsConf a couple of times and the tweet I woke up to this morning was, oh man, I really wonder if DHH keynote is going to announce a not a Rails feature but I have to turn off every single time I start a new Rails project. And I thought like that's just heartwarming to get that sort of sentiment because it shows that that's a grizzly veteran, right? Like they're already skeptical and cynical about being here. As the answer to almost all programming and computer related questions, have you tried turning it off and on again? Works here as well. So this is a celebration. RailsConf is always a celebration and the main thing it celebrates is you. It celebrates that you had such wisdom and diligence to pick the absolute best tool for the job. It doesn't really matter what the job is, whatever the job is, you pick the best tool. Of course, that's why you're here, right? And you get reaffirmed and validated in that choice when you look around and you see yeah, that's right. There wouldn't be 1500 or 1300 or remember many people are here if I didn't pick the right thing. We all picked the right thing. We're pretty great, aren't we? And I just wanna say yes, yes, you really are great. You picked the right thing because of course you went through careful analysis to pick Rails. This wasn't just a fly of the pants kind of thing. You did all the pros and cons. You read all the benchmarks. You did all the comparison studies. You probably did a lot of demo projects in like what five to seven other frameworks and languages before you picked Rails, right? This was a very hardcore scientific exercise for you to end up here in the Ruby and Rails community. No, shit. Okay, well, don't let that spoil the party. I'm, as I said, here to reaffirm. Everyone is here to validate that part of a little due diligence you did, you did pick the right thing. Because this reminds me of how I came to Ruby and how I picked the right tool for the job. I of course also did none of those things. Back in I think 2002 or something like that, I was reading Martin Fowler and Dave Thomas in a couple of magazines and they just kind of said hey, if I could have written this in whatever I wanted to write it in, I would have written it in Ruby. And I went like, yeah, good enough due diligence for me. I'll just pick Ruby. So that's how I ended up starting with Ruby. It wasn't through this careful analysis. It wasn't through picking the best tool for the job. Because I think that's basically in almost all instances of major technology decisions, complete and other bullshit. And it's a story that programmers like to tell themselves that they are these rational beings who do careful analysis and only after all these due diligence they make their choice. And when they make their choice, it is surely the best choice because it's the choice they made. And I don't really subscribe to that. I actually, whenever I see this or we pick the best tool for the job, it's a tell. It's a tell that someone is trying to cover up something. They are not trying to tell you how they picked that. It was just like, oh yeah, I did things and I arrived to the solution. And I think the reason why we have this shield, this idea that we have to project that we are rational people who pick tools and make technology decisions based on facts and proofs and whatever else it is that scientists are supposed to do, is that it's kind of scary, right? It's kind of scary just to take this leap and decide, okay, well, I'm going to invest a major part of my attention, my career, my life, into this one thing. Because that means I'm not going to do a lot of other things, right? Like if you showed up here, Ruby on Rails, you're probably not going to Django Conf next week. Show of hands, I'm gonna go into Django Conf next week. I don't even know if there's a Django Conf next week. And neither did you. Because you're not in a shopping mode, right? You're not still sort of looking around and let me see all the other things I could do, at least not as sort of a serious endeavor. But you are still trying to walk this tightrope. And this tightrope is a lot about sort of just figuring out and validating your own sense that like, I'm doing the right thing, right? Like I'm being a responsible adult here that's making sound career choices. And as long as I believe that and just keep walking straight, everything's gonna be fine. But of course, gusts of wind come in. I kind of just throw you up battle, balance. Maybe you read something on Hacker News and say, okay, have you seen this hot new framework? This is the best thing ever. And you go, whoa, I thought I'd already picked and figured it out. I thought I had the best tool for the job. And that's the funny thing. And I think that that's the smash, the paradox of think of ourselves as a profession of computer scientists, of people who make these sound rational choices when the most important choices, the major choices, the defining choices of our careers like which communities to focus on, they're not based on anything of that at all, right? They're based as in my example of just like, oh, I heard someone say some nice things about Ruby. And I kind of like what those people were saying in general. Good enough for me, let's go with that. Now on this tightrope though, you're walking up here, you're trying to think to be, I wanna be in control. But every now and then it's hard not to look down and get a little scared, right? Because we keep hearing the technology move so incredibly quickly. And we're reaffirmed in this belief because every three days there's a new JavaScript framework out and people go like, what? You didn't even know about whoosh, whoosh, whoosh? Are you still using blah blah? That is just crazy, right? So we get this constant sense that the world is moving really quickly and we could fall down at any time and we could have made the wrong choice. We could have ended up as co-option programmers, right? And that's pretty scary because then you're like, well, I made that choice, right? Even if I didn't do all the due diligence, it's still my fault. No one told me to use co-option, I hope. So at some point you sort of just picked something and you went with it and perhaps you wake up one day and you realize that wasn't the right thing. Now, I don't think this actually happens very often. Most major open source and programming communities actually last for a very long time. I just read this article last week about how in-demand co-opal programmers are right now. Co-opal's been around for a pretty long time. You'd still be a very successful co-opal programmer. Who knew? So perhaps this risk is a little sort of over-inflated, but I think it's important for us to address it head-on and just recognize that the dangers of being responsible for your own happiness can be overwhelming because sometimes you think as Bojack Jackson here, one of my favorite characters of all time, I can't even be responsible for my own breakfast. How am I supposed to be a responsible adult making these serious life and career decisions? And that's when that rational illusion starts creaking a little bit. That's when these underpinnings, the industry in our community is based on of computer science and below that even physics. All these truths we're building on top of, they start feeling not so secure because we're at a level just one step above that, one step above that rational truth. So it's easy to retract into this notion of just putting up your shit. I really have no idea what I'm doing. I think that's a mistake. I think that's the easy way out is to just look at that, look down and then freak out and think, well, I don't know what I'm doing anyway and that's just how it is. I'll never know what I'm gonna do anyway or what I'm doing anyway. I think this is also why FUD is such a toxic and dangerous things for our minds is because if we had made all these decisions about which community and which programming ecosystem to be in and they were based on sound principles of like, this is actually the best tool for the job. Like the answer is 44% and the other tool had like 39. So this is clearly the best. We would have something solid we could rest with and say like, I arrived at a conclusion that's indeniable, right? But it's not because we all make these flimsy choices. We all make these choices based on these flimsy justifications that are really rickety. And that leads to I think a lot of anxiety when people then start blowing these gusts of wind at us. And it leads to sort of, it's a main contributor to this emotional roller coaster that a lot of programmers go through. There's this large picture of like, oh shit, and did I pick the right thing? Am I moving too slow? Should I know more stuff? I'm supposed to be full stack. I don't fully understand all elements of SQL outer joins yet. Does that mean I'm a terrible person? And you end up in the other end of like, shit, I got this thing to work. This is amazing. I have some stuff on the screen. Like I implemented a real feature, hooray me. And these things go up and down. And I think we need something to stabilize that a bit. We need that balancing bars. We're rocking across the type rope to even out the roller coaster a bit. And I've been thinking about sort of what things can help us in that regard. Well, clearly RailsConf can help us in that regard. As I said, one of the main jobs of RailsConf is not necessarily for someone to show up here and like, I'm going to learn a lot of serious stuff. As I walk out of here, I will know more about views or SQL or ActiveRecord or Rails 5.1 features or any of these other concrete scales that you totally can pick up here and I invite you to do and that's great. But I don't think that's the main job to be done for a place like RailsConf. I remember back to the first major programming conference I went to. It was a conference in Copenhagen called Jiao 2003. And what was monumental about Jiao 2003 was, first of all, it was a majority of Java conference. I couldn't afford to pay the tuition, so I worked as an intern in helping out, doing the organization. And I wasn't really that interested in Java. I knew that already then, but I was interested in going to a program conference because it gave me this feeling that now I'm a real programmer. Like real programmers, they go to conferences, they learn shit and then they're adults. And that was sort of that mindset I was in, like this is what I'm supposed to do, right? And if you look at it like that, then the main job of the conference as a conference here today is closer to that, closer to giving you the validation that yes, you are a real programmer. Yes, there is a community of other people who pick the same thing as you do and that's great and I did the right thing and that's good. It's kind of like a soothing communal experience where we can just go like yay us. And yay us. Yay Rails and yay us making the right choice and yay these jobs. So there's this framework for analyzing products and services called the jobs to be done framework, which sort of hinted at what is the real core job of RailsConf, the real core job of RailsConf is not necessarily like I'm gonna learn a lot of technical skills, it's more whatever sort of feeling I walk out of there from there. The real job of Rails too, is not necessarily just productivity or easier code or any of these sort of surface level bits of understandings. There's a deeper job I think here hidden in the fact that Ruby on Rails is an ecosystem of choice. So this is in opposition to ecosystems that are mandated like if you wanna write an iOS app you pretty much have to go with Objective Swift. In some ways that lack of choice is liberating. In some ways the fact that Apple just tells you what to do, tells you this is the tool set that you need to go with, relieves you of all this choice, relieves you of a lot of that anxiety on the wire that you might have picked the wrong thing. With Rails, we're in this other boat, right? We're in this boat because Ruby on Rails is about making things for the web. And when you make things for the web, you can use whatever the fuck you want. You can use the B script, which was one of the early things I got started with. You can use PHP, which I also used a bunch and some people still use. And you can use Ruby or you can use Python, you can use all these other things. And I think that that's a huge part of the double-edged sword of these communities of choice. That it's wonderful that we get to have these choices, but it's also a little scary. Now, this is cemented I think by the fact that at least when we kicked off Ruby in the West in the early 2000s, no one picked Ruby as their first thing. Everyone in the community at the time, they were refugees, fleeing other communities of oppressive nature that I will not name Java. And I remember I showed up to the first Ruby conference, I think there was like 30 or 40 people there. And the vast majority of those people, obviously they came from other programming backgrounds, they weren't first-time programmers. They had picked Ruby because they were trying to escape something. And in those days, it was enough just to say, hey, Ruby is easier, Ruby is simpler. Well, we never said Ruby was faster actually, that doesn't make any sense at all. So subscribe to that one. Easier and simpler because those weren't necessarily words that people used about J2E, right? No one was like, hey, you should use WIP logic because it's easier. That was not part of the sales material. So just saying those things and talking about those outcomes actually had some attraction, right? Because they were in contrast to something else. Well now, not so much. If you look at basically any open source language or framework today and you go to the website, they will all claim the same thing. They will all claim that it's easy, that it's fun, that it's simpler. And it's become banal and commoditized to claim these outcomes because anyone can say them. It's not like it's a protected title, right? Not like you can say, well, it's easier than what? That question is usually not posed. For us, in the early days of Ruby and Rails, we had it easy because we had this bear we could poke at, Java. And we could say, look at that XML5. Did you know that that is 4,000 lines roll? That was such an easy, obvious target and that's not true anymore, right? Today, there's lots of other communities that can legitimately claim many of these same values as we claim for Ruby and Rails, which brings us back to this, oh my God, then how do I pick again, right? In some ways, Ruby and Rails and Ruby in particular, it was always the language of choice, but the choice was much easier. The choice today is significantly harder. The people who were here for the first time who made this choice recently, they were faced with a much, much tougher choice because everyone is saying everything is easy. Everyone has these major apps on their credit roll, right? No matter pretty much which environment, whether you're picking PHP or Python or JavaScript or whatever, all these domains, they can say the same thing, they do say the same thing. This is easier. Look at all these wonderful apps, look at all this web scale that's happening in our community, so how do you choose? Well, this reminds me of back in the mid-90s when Ruby was just getting created, I was just getting into the web and one of the first things I got into back then was Usenet. So Usenet was basically the common section before the common section. Online discussion groups where people would talk about all sorts of shit and at that time, my reason for getting into programming was I was interested in games and writing about games and reviewing games and maybe someday making games. So I went into this group called Alt Console and one of the main things on Alt Console was the famous console wars where people were arguing which is the better machine? Was it the PlayStation one? Or was the Sega Saturn? Or was Nintendo N64? And I learned a lot from spectating that spectacle. And the main thing I learned was no one ever fucking changes their mind about anything. In online discussions on forums, right? Like no one ever went like, oh yeah, that's a really good point. I'll throw out my PlayStation via your Sega Saturn instead. That just never happened, right? But yet these threads would go on for weeks or years even and repeat over and over again because all these proponents of their individual platforms had these really vocal proponents who would talk about why the Sega Saturn is the best. And the arguments that they were using were just awesome because they were all technical and which meant they were all pretty much bullshit. The arguments would go like, hey, did you know the audio chip on the Sega Saturn have like 16 channels and the one on the PlayStation you don't have 12, 12 channels? Oh, the fucking you didn't make any music on that kind of shit machine, right? So it would be this game of Trump where you go like, ha ha, 12 channels, 16 channels. Well, 950 polygons a second. Well, 1.2 million polygons a second, right? And you think like they legitimately thought every time they played that Trump card, I got you. Now you can only accept the truth that my system is better and you have to switch tomorrow. And of course no one did that, right? Because consoles like a lot of use for programming languages and frameworks are not about the technical details. They're about the games. They're about what people make with that. And they're about the ethos that's come out of that because these aren't just three similar machines even though they are similar in many ways. And the technical spec at least in the day was quite similar, but they were still very different. The kind of person who like Yoshi and Mario, picked Nintendo, right? It didn't really matter whether the PlayStation had another four audio channels. That was not their motive of picking. So if we can't convince anyone to either pick another console or pick another programming language or environment based on these technical specs, based on the underpinning signs of the solution in most cases, unless there are these edges, then what can we use? What can we use to even validate our own choices and feel good about that we make the right one that fits for us? What are the games and the philosophy of programming languages? Well, even though a lot of these programming languages are very alike and I'll do some contrasting in comparison in a second, they're also quite different. The belief systems that underpin the choices that we make, the features that we implement, the APIs, how we structure them, the code how it's formulated, the division of the systems and in which chunks and how large, all these choices come and stem from something deeper. They come from belief systems. And sometimes when those are done really well and when those are implemented sort of fully and all out, you can just see them in the code. Here's a great quote by Aber Camus on, a novel is never anything but a philosophy expressed in images and in a good novel, the philosophy had disappeared into the images. I think that is completely true of programming languages and frameworks as well. When there is an underpinning philosophy and when there are some underpinning values to drive the development of these systems, you can see them in the code. But like with novels, it's kind of hidden. And if you're new to it, like it's not necessarily sure you wanna do a full textual analysis of a given programming language or framework to figure out whether these values actually resonate with you, right? So it'd be nice if there was something a little more concrete that you didn't just have to derive from first principles by reviewing code or community and so on. And I think Ruby put one of those big stakes down early, which put it on the map. And that big stake, that big value was that it was going to be optimized for programmer happiness. There was this specific goal that Matt's had creating Ruby. And at the time when he announced that, that sounded ludicrous. No one was talking about programmer happiness in that sense. Now of course, as we talked about a lot of these things like happiness or clarity or simplicity, there's kind of been commoditized and a lot of people talk about these things in the same way. So it's not quite enough. I think actually Ruby is not doing itself fully justice by lacking this elaboration of the values and principles on depending it. Other languages do though. This is the send of Python, which is PEP 20 from 10 Peters in 2004, explaining some of the specific values and principles to drive Python. And what I loved about finding this was both on the one hand, I could see why there are at times cultural similarities between Python and Ruby. And I could also see why we totally disagree in a lot of ways. So in some ways, reviewing the send of Python was a way of deriving the ideas of Ruby. I'll read some of these out. Beautiful is better than ugly. Okay, the one thing about belief systems and values is unless someone wants to say the opposite, that's probably not like a major element that's gonna resonate with someone. Who's going to say ugly is better than beautiful? Well again, maybe the Java people, but let's leave that out of the equation for a second. The next one is much better because the next one has real opposition I'd say. Explicit is better than implicit. Now if you read that just in void of context and just by itself, that also sounds like beautiful is better than ugly. But I actually believe that for Ruby, usually we pick the opposite. We actually pick implicit code a lot of the time. Convention over configuration is based on implicitness, is based on deriving elements of the code inferring those rather than spelling them out. So that's a great point because that's a point where we differ. And I think the same is true in Ruby in general. Here's another one, simple is better than complex. Again, not a lot of people would say the opposite. Java joke. Flat is better than nested, blah blah blah, readability counts, blah blah blah. There should be one and preferably only one way to do things. I love that because that was the first piece of philosophical nugget I got from the Python community. And again, on the face of it, it sounds reasonable. But the more I dug into it, the more I realized that I don't agree at all. I don't think there should be any one way to do things. I think the beauty of Ruby is that we have fucking a million ways to do the same things on subtle contextual variety, right? Where do we place the conditional at the beginning of the sentence? Do we use if, do we use unless? Do we place it at the end? Do we place it in the start? There's a lot of lovely subtleties for you to dig into that gives Ruby its beauty. And that's where this becomes even more interesting to me is that these belief systems are interlocking and interdependent because they're often in opposition. When you say beautiful is better than ugly and then you also say there should only be one way to do things, I feel tension. Okay, so by reviewing this set of Python, you can learn a lot about the kinds of people who would be attracted to Python. And no Python joke here because I actually completely respect someone who would look at this and go, that's me, like this totally resonates with me. I want to write Python. And I also fully respect, surprise, people like me who go like, no, I don't want to do things this way. These are not my values. I cannot adopt this. And that is why Python doesn't work for me. It's not about the intention, meaningful intention. It's not about these specifics because each individual specifics is kind of like, 16 channels of audio versus 12 channels of audio. Yeah, you can have an opinion on those particulars but they all derive from a core base of principles. And if you dig all the way down to those, it becomes much easier to decide. So last year, was it last year? Maybe it was the year before. I tried to remedy that for Ruby on Rails a little bit. By coming up with the Ruby or sorry, the Rails doctrine, a set of principles and values that I felt best expressed why it is I after 14 years still continue to love working in Ruby on Rails. Number two here, convention over configuration is one of those things that's in direct opposition to explicit is better than implicit. That's what I love about it. I love to compare these value systems and these principles between different communities because that's where we find the dividing points. That's where someone can go look at those and see at least after some experience and some exposure to the communities, what is for me? Where will I fit in? The great thing about enumerating these principles and enumerating something like a Rails doctrine is that, well, first of all, it makes it explicit, which means that it's hackable, right? We can change this. We can reflect on it. We can see whether it fits. We are not. And I wish I kind of had jotted this down 10 years ago because it would have saved a lot of meaningless debates. Especially in the early days of the Rails community, we had a lot of clashes over fundamental principles such as, hey, how big of a surface area should an object have? For some people, having a very small surface area was really important as in having just one way to do things, right? For me, it was not important at all. And I said, I don't care whether action controller has, I think, 350 public methods maybe. That's not a concern that I have. It's not part of the value system. It doesn't reflect any of these things. We have that to get these other things that we care about. An Omicasa menu, convention over configuration, these serve a purpose. So if I share the purpose with you, at least you can understand where I'm coming from, right? Because a lot of these debates I find in technology, they're all debates about tactics. They're all debates about like, oh, should we do this? Should we do that? And they very rarely, like the console wars, resolve themselves by people being persuaded by just purely technical arguments. If there's not a shared sense of values, if there's not a shared base for us to form these opinions from, we're gonna keep running around circles. Now, neither obviously Python or Rails were particularly pioneering in jotting down values for technical endeavors. This is the manifesto for the agile software development. I think it was published in 2000 and 2001. A bunch of, funnily enough, you can almost see them out here. Dave Thomas is on the second to top left. Martin follows in this group. A bunch of these people who had a huge influence on the Ruby and Rails community were present at this meeting where they decided basically to encode their values for how software methodology should work. And this is in part what inspired me. Not just the agile manifesto, but at that conference in 2003, the single most influential speaker there for me was Ken Beck talking about extreme programming. Extreme programming, true to its worth, is also quite extreme in how it spells out exactly its values, principles, and practices. Basically, the extreme programming book is a manifesto in the same sense that this is. It's not so much about specific techniques, although those practices are there. They're more about those values. They're more about those principles, which brings us to the whole, well, at least part of the point of going through this whole exercise of trying to uncover what our values are and what we believe and what we don't believe is that it gives us a foundation to plant roots. You can't plant roots in features. You can't plant roots easier and faster. There's nothing there. There's no soil that's gonna hold it down. What you can plant your roots in is philosophy and values. You can say, this is me. There's longevity in that. I think a lot of the people who stuck around in the Rails community, again, have not stuck around just for those auxiliary benefits of, oh, I'm more productive or this is easier. No, they stuck around because the values resonated with them, which is kind of also a counter to another prevailing role model, I should say, in the software development world, which is that of the nomad. I find there's a lot of hero worship around people who learn seven programming languages in seven weeks and everything is just syntax and we can just move freely from one world to the other and I don't really care which specific community I'm in. I'm just a programmer. Again, one of those things when you're here at the first time and, oh yeah, yeah, totally, that makes sense, like I shouldn't be tied to anything. Well, what, why? I think actually a main source of that anxiety that we feel, the openness we have to fud, of fear, uncertainty, and doubt comes from the fact that if we have no roots, it can just all blow away. So actually taking up roots, actually taking on even an identity from those roots and saying proudly, I'm a Ruby programmer, it's not a bad thing, I find quite the opposite. I find a lot of people are very afraid, perhaps because they've been told that like, well, programming languages come and go and you should just learn as many as possible and all those things are true to some extent as in source of intellectual curiosity and expanding your mind and blah, blah, blah, blah, but I still find that unless you place your roots in something specific, you're just gonna waver around. Emil Durkheim was a 20th century sociologist and philosopher and yes, this great quote where he's reflecting on sort of what was going wrong in society at the turn of century, why suicide rates were going up and all these ill studies all in society. If society lacks the unity based upon the commitment of man's will to a common objective, then it is no more than a pile of sand that the least jolt or slightest puff will suffice to scatter. This is exactly why we need those roots. As a counter to that, as a counter to that modern rootlessness of us just moving around constantly, us just following the next shiny thing as soon as it blinks. I think if we have that, if we dare say, this is where I stand. If we dare say, these are the roots that I have, these are the things that I believe and yeah, everything is eventually up to reconsideration but not on sort of a day-to-day basis, right? Like your values are probably not values if you're changing them every 48 hours. Then you also have a chance to give counter to sort of what I learned to with that early tweet I woke up to this morning, the cynicism that everything is amazing and nobody's happy. Rails has never been more amazing than it is right now. We have never had it better. We've never had more people caring about making it better and yet this rootlessness, this anxiety often leads us exactly to Luis CK and to that tweet of this morning that everything is so wonderful and we walk around pissed constantly. Not a great place to be. I think it's also the antidote to the fear of missing out. If you actually have roots, if you have a core, you're probably not going to be as likely to be constantly scared about missing out, right? Because you base yourself in something that's deeper than just easier, faster set of features that could be duplicated or changed tomorrow. Okay, so as I was thinking through all this, I was sort of looking for inspiration of other places to see the similar patterns or thoughts and so on. And I think one of the wonderful things about computer science and programming in general being such a young discipline is that we get to build upon wonderful thinking from other disciplines that went before us. So Christopher Alexander, for example, the architect famous for pattern languages of how to build buildings was a huge inspiration for pattern languages and software, for the agile movement, for a lot of the Kent Beck and Warth Cunningham took a lot of inspiration away from that, wonderful. When I think about belief systems, about sort of interlocking values to help guide us, well, what do I think about? I think about the original full stack belief systems. Religion. Religion has thousands of years of perfecting communal cohesion. Thousands of years of perfecting these ideas of committing to a set of values and principles and practices to give you roots. To create communities based on kinships of the mind, not just kinships of blood or other earlier ways of how groups would organize themselves and figure out who's in and who's out. And that was sort of a funny realization for me because I'm an atheist. I don't believe in religion in that sense. What I do believe is things that work. And I think religion works when it comes to all these elements that we've been talking about or I've been talking about for the last half hour of getting rooted, of having values, of committing to something, of being stable in a group and not being constantly on the run for something. And what I like too about religion is this rich history of the pattern language of religion. The rich history of the vocabularies. One of my favorite things in programming is naming things. Both because it's hard and also because it's really rewarding of carving out a concept, giving it a specific name and sort of seeing a complete world spin up around that. Well, religion has done that better than anyone. The names are just evocative, absolution, salvation, sin. It just sounds good, right? There's just someone thought about this for a couple of thousand years and the things that kind of came out at the other end of it, pretty good. I gotta say, a lot of respect for that whole process. And I think a lot for us in other communities and especially in the programming world to learn from that. So I sort of thought quickly through like, what are the main things I take away from that? What are some of the examples that I could use? Well, one of the ones I really like is this notion of patron saints. People who set out specific examples for this group that really represent their values and shine a light for how others should be and behave. If I think of my two favorite patron saints of the Ruby community, they're why the Lucky Stiff, the patron saint of Weird, who wrote a introduction to Ruby that included things like chunky bacon and arguing cats. And it was one of those, I think 2006, early definitional pieces of who are we going to be like a community? Well, we're going to be weird because why the Lucky Stiff is weird and it's pretty cool. Unfortunately, I think this is also part of the patron saint's thing is they're not here anymore. So why the Lucky Stiff retired from public life, Ruby life at least in 2009, but I seriously encourage you to look up his work. It's deeply inspiring. And the other patron saint that I hold really dear is Jim Wyrick, the patron saint of Wonder. I've never seen anyone light up in their eyes like Jim when he was telling someone about a new idea. And when he was teaching new commerce to the community about the things that we do here. He's also the creator of Rake and Builder and a bunch of other tools. And it was just an example for me of leaning on that pattern language of religion to identify things that matter to us in our community. Well, like most religion, though, of course, it's kind of a buffet, right? Like there's not a whole lot of people who subscribe to all of it. And it doesn't have to be that way either, right? We can still, someone can read the real doctrine and go like, oh yeah, like most of these things totally mean this one thing, not so much. And we can still get along just fine, right? It's still a buffet, even if you don't eat every single fucking dish that's being served. And there's still also differences. Sushi buffet versus a Thai buffet. Yeah, they're both buffets, but they're quite different. And the only people who try to sort of eat fucking everything are the fundamentalists. And again, I think that that's one of those wonderful things fundamentalists is generally not a word we say with sort of embracing notions. But the one that really gets me, the one I think struck to the heart of why I wanted to give this talk is faith. Believe in ideas for which you have no proof, of which you may not ever be able to have proof. I think this underpins a whole lot of things that we argue about in technical communities. We argue about a whole lot of ideas and principles and practices for which there will never be a final answer. For which you will have to rely on faith to get something out of it. And that goes straight to the core of this identity crisis that I think a lot of programmers have, where on the one hand they see themselves as computer scientists. They might have gone through a computer science degree. And then on the other hand, they're constantly faced with the fact that the big questions in software development are not about the science. They would kind of sell the while ago which was the better sorting algorithm, right? It's not a major source of contention these days. Whether you should use bubble sort or not. The answer's no. And we arrived at that answer a long time ago. The focal points of attention where we have the battlegrounds of principles and practices are around these faith-based ideas. Like TDD. I called this out in 2014. And I just watched that talk back again. And one of the things I sort of used this as a way of squirming that and then overplaying that principle was TDD was a faith-based methodology. And I used that in kind of a derogatory term. And I've come to a little bit regret that because as I realized all these things we talked about in the Rails doctrine, they're all faith-based. We're not gonna have any final proof. There's not sort of a experiment that we can set up and reasonably run and then come to a conclusion which is definitely better or not better. Same goes for TDD. Same goes for a lot of software methodology that it doesn't subject itself well to science. It doesn't subject itself well to controlled experiments. Does that mean it's not important? Of course not. Static typing. Static typing versus dynamic typing. I think that is one of the, we've been at this for what, 30 years, maybe longer, going back and forth, dynamic typing, no static typing, no dynamic typing. You can't resolve something in about 30 years, like probably you're not gonna resolve it, right? We're very not gonna come to a conclusion that all programs henceforth should be either dynamically typed or static typed because it falls back to these values. The people hold different values and they come to different conclusions on questions like dynamic versus static typing based on those values. Immutability. Functional programming right now is hot, right? It's one of the gusts of wind that if you've been doing object-oriented programming for a long time, you're going like, whoa, did I miss the boat totally here? Should I switch all my shit to functional programming? Will immutability make me finally pure and happy and a responsible adult? And the answer is probably not. Doesn't mean it's not a worthy idea. All these ideas are worthy. Not only are they worthy, they're the most important ones. As I said, these are the ones where it's actually interesting to interrogate where you land up yourself because there is not a uniform answer. You are forced in some ways to choose. The same goes for Ruby. We have this obsession in Ruby. Well, I have this obsession certainly that beauty is the promise of happiness. That writing beautiful code in itself is something we should do not because it's more productive. I believe it is, but it's fair to say someone would believe the opposite. But simply because that's my faith. My faith is in beautiful code. That's where I derive a huge part of my happiness. So this resonates perfectly with me. So I think the conclusion there is when we look at these major questions of programming life and software communities, we have to look to faith to answer them. We have to look to values to answer them. There's not going to be the possibility of an experiment that men can conduct and come to a final conclusion. Okay, so why go through all this, right? Like, where's this journey going to take us? And for me, this journey is mainly as a bulwark, as a strengthening of the balancing bars is that when those gusts of wind come in, not just from, oh, new things popping up, but from daily life and daily absurdity, I have some ballast. I have some way of not being knocked over and falling down from the wire easily. Another quote here for Albert Camus. Man stands face to face with the irrational. He feels within him longing for happiness and for reason. The absurd is born in this confrontation between the human need and the unreasonable silence of the world. You can replace unreasonable silence of the world with unreasonable silence of the computer very easily. And you can replace a lot of this absurdity with some of these things that we do all the time, like shaving the yak, right? We set out in the morning with these grand aspirations of doing a good day's work and 15 minutes into it, some transitive fucking dependency broke, and you spend the next of that goddamn day trying to fix it. And you got no further on your original task. You got to no completion. This is completely absurd. You're trying to make a change over here because someone broke a gem, five steps down, you're forced to spend your entire day in this, right? That's enough to drive most humans mad. And it's intrinsic in the development. It's intrinsic. We cannot escape this, right? We can try, but I think it's rather more likely that we simply come to terms with the fact that the absurdity is part of what we do. Lots of programming is just patently absurd and the sooner we accept it, the better off we are. And it's not just on the technical side of things. It's also on what we're trying to do. I love that Juicero is not just a joke that you don't even need to deliver a punchline, you can just show the image. But imagine Juicero, right? Like they've been working for, I think, what, three years and part of that was a fair number of software developers and some of those software developers were tasked with the fact of building a system that would check the bar code, basically DRM the food and make sure that it was valid food and there hadn't been a spinach recall. They probably worked on that for like 18 months. Imagine sort of the absurdity of working with something that has so little meaning will never really be used in any reasonable context. And like that's what you have to look back on for the last 18 months and say, yep, that's what I did. I'm the Juicero spinach alert guy. There's something depressing in that and I don't just mean that to rag on Juicero because there's a little Juicero in all of us. We all work on features and systems from time to time that end up not mattering at all. The number of features I build at Basecamp where I fucking spent two weeks build it all the way to conclusion and then Jason says, yeah, I don't like it anymore. A lot of that, right? A lot of absurdity in what we're trying to implement where it just doesn't go anywhere. We have nothing to show for it. And if you, again, if you don't have some roots to base that into sort of make sense and give yourself an acceptance to the larger world, that's going to be really depressing. And I've seen lots of programmers go through this with both shaving the yak or working on something that doesn't ship. And at the end of it, they go like, yeah, that's it, I'm out. Programming thing, I'm not so happy with them anymore. This is not perhaps when I'm going to stick around. Same thing with entropy. If you have this belief that you can keep the ice cube perfect as soon as you take it out of the fridge, you will eventually end up in a puddle of disappointment. Lots of programmer have this exact notion that we can maintain these pristine systems if we just use the rice architectural pattern. No, no, no, that messy system that's five years old, you just use microservices. It would still be an ice cube. A beautiful ice cube, not a drop would have fallen off it. Because there's this quest constantly to sort of deny the absurd, that we can somehow fix the absurd, that there will someday be a day where no programmer evermore shall have to shave the yak because she is tracing some transitive dependency that broke. I'm hate to break it to you, it's not gonna happen. People have been trying for a very long time to take the programming out of programming, but the programming is the absurd. I think the important thing is to learn to live with one ailment, not seek this perfect cure that's nowhere to be found and that's bound to disappoint you. And there's sort of different ways of coping with that absurdity. Mr. Peanut Butter from Bojack Jackson has this great quote that the key to being happy isn't a search for meaning, it's just to keep yourself busy with unimportant nonsense and eventually you'll die. Which is sort of one way of denying the absurd and just distracting yourself and then you're dead. That's a little gloomy for me. Another one is to pretend that the absurd is actually heaven. Sergeant Apoc from Aliens. A day in the Marine Corps is like a day on the farm. Every meal is a banquet, every paycheck a fortune, every formation a parade, I love the Corps. I have more sympathy for that. I think this is more of a sort of optimistic way of the world but still a denial of the absurd and still one that's going to lead to disappointment because you will wake up and one day you just can't tell yourself to that sludge on the table in front of you as a banquet and all of a sudden your entire world falls apart. Now I think that Camus and the myth of Ciphosis is much closer to where we need to end up. To embrace the absurd that we will roll a rock up the hill every day and every night it will fall back down. And if we can come to accept that that is just what we do. A lot of programming work is rolling a boulder up the hill and watching it fall down the next day. It's a lot easier to cope with. That we can embrace this absurdity and we can embrace sort of the details and like, oh, I took a slightly different path up the mountain today. Yes, the rock will still roll down but that's okay. I think we're going to be better off. And finally, I think if we can accept that, hey, we're not computer scientists. None of the people in this room who do work on Ruby and Rails or with Ruby and Rails most of the time do anything that resembles science most of the time. I think we're going to be better off. If we accept that it's the passions that drive us most of the time. It's not the passions here in this image, it's the elephant and logic reason is the rider. But you're alone for the ride a lot of the time. You're alone for a ride with your anxieties, you're alone for the ride with your insecurities, you're alone for the ride with the absurdity of what it is that we do. But at least you stand a chance to last if you find solace in your roots, if you find solace in your faith and if you learn to cope with that. All right, that's it, thank you.