00:00:13.000
I'm really excited to be here. I'm really excited to see the show of hands of just how many people are new and fresh.
00:00:20.080
I woke up this morning, 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 develop a little bit of a harder shell, a little more skepticism, let's just put it that way, about what you're going to see. You've been here before; maybe you've been to RailsConf a couple of times.
00:00:32.119
Then the tweet I woke up to this morning was, 'Oh man, I really wonder if DHH's keynote is going to announce another Rails feature that I have to turn off every single time I start a new Rails project.' And I thought, that's just heartwarming to get that kind of sentiment because it shows that that's a grizzled veteran, right? They're already skeptical and cynical about being here.
00:00:56.399
As the answer to almost all programming questions: have you tried turning it off and on again? This of course applies here as well. RailsConf is always a celebration, and the main thing it celebrates is you. It celebrates that you had the wisdom and diligence to pick the absolute best tool for the job.
00:01:09.200
It doesn't really matter what the job is; it's whatever the job is, you picked 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 see that there wouldn't be 500 or 300, or however many people are here, if you didn't pick the right thing. We all picked the right thing. You're great, right? And I want to say, yes, you really are great. You picked the right thing because, of course, you went through careful analysis to pick Rails.
00:01:47.200
This wasn't just a fly-by-the-pants kind of thing. You did all the pros and cons, you read all the benchmarks, and you probably did a lot of demo projects in about five to seven other frameworks and languages before you picked Rails, right? This was a hardcore scientific exercise for you to end up here in the Ruby on Rails community.
00:02:24.320
Of course, don't let that spoil the party. I'm here to reaffirm that everyone is here to validate that you, however little due diligence you did, did indeed pick the right thing. This reminds me of how I came to Ruby and how I picked the right tool for the job.
00:02:36.799
Of course, I also did none of those things. Back in 2002, 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, I would have written it in Ruby.' And I went, 'Yeah, good enough due diligence for me.' So that's how I ended up starting with Ruby.
00:03:04.440
It wasn't through careful analysis; it wasn't about picking the best tool for the job because I think that's basically, in almost all instances of major technology decisions, a complete and utter fallacy. It's a story that programmers like to tell themselves that they are these rational beings who do careful analysis, and only after all this due diligence do they make their choice. And when they make their choice, it is surely the best choice because it's the choice they made. I don't really subscribe to that.
00:03:47.600
Whenever I hear the phrase, 'We picked the best tool for the job,' it's a tell. It's a sign that someone is trying to cover up something. They're not trying to articulate the real process behind how they arrived at that choice. The reason we have this shield, this notion that we have to project, is because it can be scary. Taking a leap and deciding to invest a major part of our careers, our lives, into this one thing means we're not going to do a lot of other things.
00:04:19.920
If you showed up here for Ruby on Rails, you're probably not going to DjangoCon next week. Show of hands, who's going to DjangoCon next week? I don't even know if there's a DjangoCon next week, and neither do you, because you're not in a shopping mode. You're not really looking around, wondering about all the other things you could do—at least not as a serious endeavor. But you're still trying to walk this tightrope, figuring out and validating your own sense that, yes, I'm doing the right thing. I'm being a responsible adult making sound career choices.
00:05:10.360
As long as you believe that and keep walking straight, everything is going to be fine. Of course, gusts of wind come in that throw you off balance. Maybe you read something on Hacker News and say, 'Hey, have you seen this hot new framework? This is the best thing ever!' And you go, 'Whoa! I thought I had already picked and figured it out. I thought I had the best tool for the job.' That’s the funny thing; that’s the paradox.
00:05:56.320
We think of ourselves as a profession of computer scientists, people who make sound rational choices when the most important, defining choices of our careers—like which community to focus on—aren't based on anything at all. They are based, as in my example, on hearing someone say nice things about Ruby, and I kind of liked what those people said. Huh, good enough for me, let's go with that.
00:06:28.720
On this tightrope, you are trying to think, 'I want to be in control,' but every now and then, it's hard not to look down and get a little scared. We keep hearing that technology moves incredibly quickly, and we're reaffirmed in this belief because every three days there's a new JavaScript framework out. People ask, 'What? You're still using blah-blah? That's just crazy!' 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.
00:07:14.680
We could end up as C++ programmers, and that's pretty scary because then you're like, 'Well, I made that choice!' Even if I didn't do all the due diligence, that's still my fault. No one told me to use CFusion! At some point, you sort of just picked something and went with it, and perhaps you wake up one day and realize that wasn't the right thing. Now, I don't think this actually happens very often.
00:07:50.720
Most major open source and programming communities last for a very long time. I just read this article last week about how in demand COBOL programmers are right now. COBOL has been around for a long time, and you could still be a very successful COBOL programmer. So perhaps this risk is a little overinflated, but I think it's important for us to address it head on and recognize that the dangers of being responsible for your own happiness can be overwhelming.
00:08:55.360
You might think, as Bojack Horseman, one of my favorite characters, often reflects, 'I can’t even be responsible for my own breakfast! How am I supposed to be a responsible adult making serious life and career decisions?' That's when that rational illusion starts to crack a little bit. The industry and our communities, based on computer science and, beneath that, physics, start to feel less secure.
00:09:30.400
It's easy to retreat into this notion of saying 'I really have no idea what I'm doing,' and I think that's a mistake. The easy way out is to look down, freak out, and think, 'Well, I don’t know what I’m doing, anyway!' I think this is why FOMO (Fear of Missing Out) can be such a toxic thing for our minds. If we'd made all these decisions about which community and which programming ecosystem to be in based on sound principles, we could rest easy.
00:10:03.680
If the answer is 44% and the other tool had only 39%, we’d conclude that this is clearly the best. But it's not, because we all make flimsy choices based on flimsy justifications that are really rickety. This leads to anxiety when these gusts of wind blow at us, contributing to the emotional roller coaster that a lot of programmers go through, with questions like: did I pick the right thing? Am I moving too slowly? Should I know more stuff?
00:11:18.480
I'm supposed to be full stack, and I don't fully understand all elements of SQL outer joins yet. Does that mean I'm a terrible programmer? You end up on the other end, thinking, 'I got this thing to work; this is amazing! I have some stuff on the screen. I implemented a real feature. Hooray me!' Then the emotions go up and down, and we need something to stabilize that.
00:12:06.080
We need that balancing bar as we’re walking across the tightrope to even out the roller coaster a bit, and I've been thinking about what things can help us in that regard. Clearly, RailConf can help us with that. One of the main jobs of RailsConf is not necessarily for someone to show up here and learn a lot of serious stuff. As you walk out of here, you will know more about views or SQL or ActiveRecord or Rails 5.1 features or any of these other concrete skills, which is great.
00:12:47.760
However, I don't think that's the main job to be done for a place like RailConf. I remember back to the first major programming conference I went to; it was a conference in Copenhagen in 2003 called Javaday. What was monumental about Javaday 2003 was that it was primarily a Java conference, and I couldn't afford to pay tuition, so I worked as an intern and helped out with the organization.
00:13:32.920
I wasn't really that interested in Java; I knew that already then, but I was interested in going to a programming conference because it gave me this feeling that I was a real programmer. Real programmers go to conferences; they learn, and then they're adults. That was just the mindset—I thought, 'This is what I'm supposed to do!'
00:14:09.120
In that context, the main job of the conference today is closer to giving you the validation that you're a real programmer, that there is a community of other people who picked the same thing as you, and that's great. It's kind of like a soothing communal experience where we can all just say ‘Yay us!’ And yay us making the right choice!
00:14:56.280
There's this framework for analyzing products and services called the jobs-to-be-done framework, which points out that the real core job of RailsConf is not necessarily to learn technical skills. The core job of Rails is more about the feeling you walk away with. The real job of Rails is not just about productivity or code; it goes deeper.
00:15:57.560
Ruby on Rails is an ecosystem of choice, which is in opposition to ecosystems that are mandated—like if you want to write an iOS app, you pretty much have to go with Objective-C or Swift. In some ways, that lack of choice can be liberating; the fact that Apple just tells you what to do, providing this toolset, alleviates a lot of that anxiety over whether you might pick the wrong thing.
00:16:53.440
With Rails, though, we're in another boat. We can make things for the web using whatever we want: we can use VBScript, PHP, Ruby, Python, or any number of other languages. I think that's a huge part of the double-edged sword of communities of choice—it's wonderful that we have choices, but it's also a little scary.
00:17:57.760
In the early 2000s, when we kicked off Ruby in the West, no one picked Ruby as their first language. Everyone in the community at that time were refugees fleeing from other programming communities, which were oppressive in nature—namely Java. I remember I showed up at the first Ruby conference, where there were 30 or 40 people. The vast majority of those people had picked Ruby because they were trying to escape something.
00:18:55.440
Back in those days, it was enough just to say, 'Ruby is easier and simpler.' We never really said Ruby was faster; that doesn’t make much sense. So talking about ease and simplicity contrasted with other languages like J2EE was appealing. Now, however, almost any open-source language or framework claims these same values of easy and fun.
00:19:51.760
This has been commoditized to the point where everyone claiming it doesn't feel unique anymore; it’s simply a common selling point that anyone can claim. In the early days of Ruby, we had it easy; we could poke fun at Java and use it as an easy target. That’s not true anymore; many languages can legitimately claim these same values.
00:20:50.680
Ruby on Rails was always about making the best choices, but the choice is much tougher today. Those of you here for the first time and who made the choice recently are faced with a much tougher decision compared to those who made the decision earlier. Because everyone is saying everything is easy, you can see wonderful apps and hear about web scales happening in various communities.
00:21:40.960
So how do you choose? This reminds me of a time in the mid-90s when Ruby was just being created, and I was getting into the web. One of the first things I got into was Usenet, essentially the precursor to online discussion forums. I was interested in gaming—writing about games and making them. Back then, one of the main things on Usenet was the console wars, where people argued about which was better: the PlayStation 1, Sega Saturn, or Nintendo 64.
00:22:38.640
I learned a lot spectating those arguments. The main lesson? No one ever changes their mind in online discussions. No one ever says, 'Oh, that’s a really good point! I'll throw out my PlayStation and buy a Sega Saturn instead.' That just never happened! These discussions went on for weeks, even years, because proponents of each platform passionately defended their choices, often with technical arguments.
00:23:25.960
They would argue things like, 'Did you know the audio chip on the Saturn has 16 channels while the one on the PlayStation has just 12? How could you even make music on that machine?' It was a game of trump cards, with both sides believing their arguments would win over everyone else, yet it didn’t change anyone’s preferences.
00:24:21.760
Just as with programming languages and frameworks, people don’t choose based on technical details; it's about the games and the ethos that come from their respective programming languages. The belief systems behind the choices we make are what drive us. Many times, the final decision isn’t necessarily about who has the better statistics, but rather about personal resonance with what the concepts represent.
00:25:47.440
The belief systems, values, and principles we subscribe to when picking a coding language reflect on our choices in life and careers. Even if you dig into languages and consider the technical merits, the decision often comes down to values and how they resonate with an individual programmer. The same applies in the Ruby community; we might have different preferences, but if you climb down to the foundational values, it becomes clearer where you belong.
00:27:02.160
Last year, or maybe the year before, I tried to remedy this for Ruby on Rails by coming up with the Rails Doctrine—a set of principles and values that I felt best express why I continue to love working in Ruby on Rails after 14 years. For instance, convention over configuration reflects the idea that you don't have to specify everything explicitly.
00:28:06.760
But 'explicit is better than implicit' has a valid counterargument too; many believe Ruby leans more towards implicit code. We often favor convention over configuration. Principles such as these help draw lines between our choices and highlight the places where we differ and can reflect on where to fit.
00:29:02.080
Products and cultures in programming aren’t built on technical specs; they emerge from an interplay of values and the belief systems we adopt, which helps make those technologies meaningful. The joy in naming concepts in programming combines with the tradition of values, both of which shape how we understand programming languages.
00:29:55.160
For instance, the Python community has articulated many of their principles in things like PEP 20, which outlines core values for programmers. Beautiful is better than ugly; explicit is better than implicit; simple is better than complex—these values resonate widely. Conversely, the Ruby community may have different perspectives, but that's what gives it its richness.
00:30:51.920
When we find out what these principles are within our communities, it opens our minds to better understanding ourselves. Both Ruby and Rails, alongside others in programming, contain shared values that many members of those communities can examine. When the values don't align, it becomes apparent where one might not fit. Understanding that not all traditions need strict adherence also frees us to appreciate diversity in approaches.
00:31:47.680
Both the Agile Manifesto and Extreme Programming serve as examples of how codifying values can help structure a community. By engaging with this practice, we're able to dig deeper into what matters and realize that community and cohesion stem from shared beliefs. For Ruby on Rails, reaching clarity in values helps new and old members alike understand their place.
00:32:45.160
Our roots are essential in a world where features can come and go. You can’t plant roots in abstract terms; the core of our community is built around philosophy and shared values. I've seen many people maintain commitment to Rails beyond productivity; they resonate with what they value. This commitment creates a deeper connection, reinforcing the community's strength.
00:33:41.160
In conclusion, when we address major questions in programming, whether in this community or any other, we need to derive our understanding from beliefs that aren't always provable. The world of programming isn't founded solely on science. Most everyday decisions we confront stem from feelings of passion, which can ultimately guide us better than strict adherence to logical reasoning.
00:34:51.760
Acceptance of the chaotic nature of our work—with its absurdities and challenges—helps us embrace the craft. Such an understanding allows us to navigate this complex landscape and ultimately leads us to a place of stability. Keeping our roots firmly planted under our feet and acknowledging the absurdity can give us the strength to move forward.
00:35:40.200
Ultimately, this is where I think we can thrive—navigating in a world filled with uncertainty, rooted in our community values, knowing that our beliefs shape the software we create. Thank you all for being here.
