Opening Keynote by Hansson
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Teil | 1 | |
| Anzahl der Teile | 86 | |
| Autor | ||
| Lizenz | CC-Namensnennung - Weitergabe unter gleichen Bedingungen 3.0 Unported: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben. | |
| Identifikatoren | 10.5446/31264 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | |
| Genre |
RailsConf 20171 / 86
1
8
10
12
18
19
23
30
35
42
49
52
53
55
56
59
65
74
77
79
82
83
84
00:00
Rechter WinkelProzess <Informatik>AuswahlaxiomWort <Informatik>DifferenteProgrammiergerätNeuroinformatikQuick-SortInstantiierungProgrammierungEntscheidungstheorieVollständigkeitProjektive EbeneFramework <Informatik>BeweistheorieÜberlagerung <Mathematik>BeobachtungsstudieGamecontrollerSchlussregelOpen SourcePunktSpeicherabzugMultiplikationsoperatorFormale SpracheAnalysisDivergente ReiheInformatikCASE <Informatik>RechenschieberBenchmarkPaarvergleichTeilbarkeitParadoxonBitMetropolitan area networkKonvexe MengeEinfache GenauigkeitStörungstheorieDreiArithmetisches MittelSummengleichungFlächeninhaltKontrollstrukturBildgebendes VerfahrenMereologieResultanteComputerspielKategorie <Mathematik>ZahlenbereichTwitter <Softwareplattform>Ruby on RailsDemo <Programm>Güte der AnpassungHackerXMLComputeranimation
08:14
MAPMultiplikationsoperatorComputerspielSichtenkonzeptEntscheidungstheorieRationale ZahlLesezeichen <Internet>PhysikalismusBitGebäude <Mathematik>InformatikComputeranimation
09:01
EntscheidungstheorieKeller <Informatik>Quick-SortProgrammiergerätProzess <Informatik>ProgrammierungElement <Gruppentheorie>AuswahlaxiomTouchscreenFortsetzung <Mathematik>Rechter WinkelComputeranimationDiagramm
11:10
Rechter WinkelKopenhagener DeutungQuick-SortAppletSelbst organisierendes SystemProzess <Informatik>DatensatzProgrammiergerätSichtenkonzeptProgrammierungValiditätReelle ZahlComputersicherheitGüte der AnpassungSpieltheorieComputeranimation
12:57
Quick-SortSpeicherabzugMAPProzess <Informatik>FlächentheorieReelle ZahlFramework <Informatik>Rechter WinkelAuswahlaxiomBitRuby on RailsCodeProdukt <Mathematik>Dienst <Informatik>UnrundheitInternetworkingExogene Variable
13:47
AuswahlaxiomOrtsoperatorObjekt <Kategorie>MultiplikationsoperatorProgrammiergerätSkriptspracheMereologieAttraktorNatürliche ZahlQuick-SortProgrammierungAggregatzustandDelisches ProblemBenutzerbeteiligungBetragsflächeRuby on RailsEin-AusgabeXMLComputeranimation
15:45
SpieltheorieFitnessfunktionMereologieApp <Programm>CASE <Informatik>ParametersystemBenutzerbeteiligungp-BlockSchnittmengeRechter WinkelRechenwerkSummengleichungWort <Informatik>UnrundheitVirtuelle MaschineGrundsätze ordnungsmäßiger DatenverarbeitungVorzeichen <Mathematik>Framework <Informatik>PunktProgrammierumgebungGruppenoperationAuswahlaxiomThreadProzess <Informatik>SystemplattformEinfügungsdämpfungNintendo Co. Ltd.Web SiteQuick-SortMathematikMultiplikationsoperatorBildschirmmaskeProgrammierungProgrammierspracheGüte der AnpassungFormale SpracheModallogikZentrische StreckungKraftMechanismus-Design-TheoriePhysikalisches SystemRankingGarbentheorieOpen SourceKontrast <Statistik>WhiteboardWasserdampftafelMathematische LogikFormation <Mathematik>Ruby on RailsPolygonSega Enterprises Ltd.SpielkonsoleGeradeATM
21:30
Framework <Informatik>AuswahlaxiomFormale SprachePhysikalisches SystemCodeDivisionPaarvergleichQuick-SortSoftwareentwicklerBildgebendes VerfahrenAnalysisProgrammierspracheBildschirmfensterKontrast <Statistik>ServerSpeicherabzugComputeranimation
23:07
Varietät <Mathematik>SchnittmengeNichtlineares GleichungssystemPhysikalisches SystemOvalSpeicherabzugReelle ZahlUmwandlungsenthalpieAppletZahlenbereichKomplex <Algebra>KrümmungsmaßRichtungKonfigurationsraumPauli-PrinzipElement <Gruppentheorie>PunktÄhnlichkeitsgeometrieProgrammiergerätRuby on RailsCodeBitFormale SpracheWeb logMultiplikationsoperatorEinsAggregatzustandWasserdampftafelProzess <Informatik>StandardabweichungPeer-to-Peer-NetzMAPVollständigkeitTypentheorieSymboltabelleNabel <Mathematik>ProgrammierungRechter WinkelRundungMusterspracheXML
28:44
Euler-WinkelBitVollständiger VerbandFlächentheorieGruppenoperationProgrammiergerätWurzel <Mathematik>FlächeninhaltProgrammierspracheMultiplikationsoperatorParametersystemKreisflächeExtreme programmingBildschirmmaskeAdditionRechter WinkelUmwandlungsenthalpieGrenzschichtablösungSoftwareentwicklerQuellcodeServerKonfigurationsraumProgrammierungPunktMereologieMAPPhysikalische TheorieMenütechnikComputerspielSpezifisches VolumenGamecontrollerSoundverarbeitungPhysikalisches SystemDifferenteIdentitätsverwaltungMaßerweiterungSoftwareSpielkonsoleObjekt <Kategorie>Offene MengeFormale SpracheRuby on RailsFundamentalsatz der AlgebraComputeranimation
34:21
COMHinterlegungsverfahren <Kryptologie>EinsSchlussregelObjekt <Kategorie>BitrateQuick-SortBasis <Mathematik>Rechter WinkelPunktWurzel <Mathematik>Metropolitan area networkComputeranimation
35:35
Quick-SortComputerspielSteifes AnfangswertproblemKonstanteLesezeichen <Internet>SchnittmengeComputerunterstützte ÜbersetzungÄhnlichkeitsgeometrieSinusfunktionElement <Gruppentheorie>GruppenoperationMereologieMusterspracheInformatikUmwandlungsenthalpieEinsPhysikalisches SystemTwitter <Softwareplattform>Keller <Informatik>ProgrammierungGüte der AnpassungNP-hartes ProblemProzess <Informatik>KohäsionVerkehrsinformationSoftwareFormale SpracheSchlussregelBetrag <Mathematik>Gebäude <Mathematik>Leistung <Physik>RankingRechter WinkelWiderspruchsfreiheitHilfesystemFaserbündel
41:36
Einfache GenauigkeitPunktRechter WinkelDifferenteInformatikTypentheorieWort <Informatik>DatenstrukturSoftwareentwicklerProgrammierungFokalpunktIdentitätsverwaltungMultiplikationsoperatorSoundverarbeitungQuellcodeMinimalgradQuick-SortInhalt <Mathematik>SpeicherabzugAeroelastizitätNeuroinformatikAnnulatorProgrammiergerätComputeranimation
43:53
Dynamisches SystemTypentheorieMereologieBeweistheorieHydrostatikProgrammierungQuick-SortComputerspielDifferenteSoftwareFunktionale ProgrammierspracheEinsResolventeCodeAnnulatorObjektorientierte ProgrammierspracheBitBeobachtungsstudieSchreiben <Datenverarbeitung>Klasse <Mathematik>Automatische HandlungsplanungFlächeninhaltRechter WinkelRhombus <Mathematik>Computeranimation
47:15
ComputerspielWasserdampftafelSummengleichungBildschirmfensterNeuroinformatikMetropolitan area networkXMLComputeranimation
47:59
MultiplikationsoperatorTeilmengeProgrammierungBus <Informatik>PunktProgrammiergerätGesetz <Physik>Bildgebendes VerfahrenGeradeRechter WinkelPhysikalisches SystemQuellcodeHochdruckTermSchlussregelPartikelsystemMomentenproblemZahlenbereichGruppenoperationVollständigkeitTaskComputerarchitekturWürfelKontextbezogenes SystemQuick-SortMathematikArithmetisches MittelGeschwindigkeitGüte der AnpassungMultigraphEntscheidungstheorieMereologiePerfekte GruppeSummierbarkeitSoftwareentwicklerMusterspracheEntropie <Informationstheorie>Ganze FunktionWurzel <Mathematik>Digital Rights ManagementTropfen
52:14
Perfekte GruppeElement <Gruppentheorie>Ruby on RailsTabelleNeuroinformatikHill-DifferentialgleichungMultiplikationsoperatorDifferenteDateiformatQuick-SortSchlüsselverwaltungArithmetisches MittelProgrammierungGleitendes MittelMereologieBildgebendes VerfahrenSchlussregelVorzeichen <Mathematik>Mathematische LogikLogiksyntheseDivergente ReihePunktWurzel <Mathematik>InformatikComputeranimation
55:23
JSONXML
Transkript: Englisch(automatisch erzeugt)
00:00
I'm really excited to see the show of hands of just how many people are here new and fresh
00:21
and excited because I woke up this morning. 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,
00:40
let's just put it by that, about what you're going to see. 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 nut of Rails feature that I have to turn off every single time I start a new Rails project. And I thought like that's just heartwarming
01:01
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.
01:21
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. It's whatever the job is, you pick the best tool.
01:42
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, I remember many people are here, if I didn't pick the right thing. We all pick the right thing. We're pretty great, aren't we?
02:03
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.
02:22
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 on Rails community. No?
02:42
Shit. Okay, well, don't let that spoil the party. I'm, as I said, here to reaffirm. Everyone is here to validate that however 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.
03:01
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 like, 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.
03:22
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 utter bullshit. And it's a story that programmers like to tell themselves
03:43
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.
04:02
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, right? 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,
04:26
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
04:42
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 gonna do a lot of other things, right? Like if you showed up here, Ruby on Rails, you're probably not going to DjangoConf next week.
05:02
Show of hands, how many are going to DjangoConf next week? I don't even know if there's a DjangoConf 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.
05:22
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.
05:41
But of course, gusts of wind come in. They kind of just throw you off 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.
06:01
And I think that that's the smash, the paradox of think of ourself 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 community to focus on, they're not based on anything of that at all, right?
06:22
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 me, I want to be in control.
06:42
But every now and then, it's hard not to look down and get a little scared, right? Because we keep hearing that technology moves so incredibly quickly. And we're reaffirming 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?
07:02
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 cold fusion programmers, right? And that's pretty scary
07:24
because then you're like, well, I made that choice, right? Even if I didn't do all the due diligence, like, it's still my fault. No one told me to use cold fusion, I hope. So at some point, you sort of just picked something and you went with it,
07:41
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 COBOL programmers are right now. If COBOL's been around for a pretty long time, you'd still be a very successful COBOL programmer.
08:04
Who knew? So perhaps this risk is a little sort of overinflated, 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
08:21
because sometimes you think, as Bo 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
08:40
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.
09:02
So it's easy to retract into this notion of just putting up your shit. I really have no idea what I'm doing. And 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.
09:22
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 thing 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
09:43
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 undeniable, right? But it's not because we all make these flimsy choices.
10:02
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,
10:20
it's a main contributor to this emotional rollercoaster that a lot of programmers go through. There's this large picture of like, oh shit, 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?
10:42
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 bar as we're walking
11:01
across the tightrope to even out the rollercoaster 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.
11:22
As I walk out of here, I will know more about views or SQL or active record or Rails 5.1 features or any of these other concrete skills 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.
11:42
I remember back to the first major programming conference I went to. It was a conference in Copenhagen called Yau 2003. And what was monumental about Yau 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
12:03
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 programming 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.
12:25
And that was sort of just 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
12:40
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.
13:01
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 ended up with what is the real core job of RailsConf? The real core job of RailsConf is not necessarily
13:22
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
13:41
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 want to write an iOS app, you pretty much have to go with Objective-C or Swift.
14:03
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.
14:21
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
14:41
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 sort 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
15:03
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
15:20
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
15:41
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 let's grab that one. Easier and simpler because those weren't necessarily words
16:02
that people used about J to E, 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.
16:21
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
16:40
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, we sort of, in the early days of Ruby on Rails, we had it easy because we had this bear we could poke at, Java, and we could say, like, look at that XML5, did you know
17:01
that that is 4,000 lines wrong? 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 on Rails. Which brings us back to this, oh my god, then how do I pick again, right? In some ways, Ruby on Rails, and Ruby in particular,
17:23
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?
17:44
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 things. They do say the same things. This is easier. Look at all these wonderful apps. Look at all this web scale that's happening in our community.
18:02
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 comment section before the comment section.
18:22
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.
18:42
Where people were arguing which is the better machine? Was it the PlayStation 1 or was it the Sega Saturn or was it the 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?
19:04
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
19:20
because all these proponents of the 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,
19:40
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? How the fuck can you make any music in 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.
20:01
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
20:22
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,
20:42
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 mode of picking.
21:00
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 science of the solution, in most cases, unless they're at these edges, then what can we use? What can we use to even validate our own choices
21:22
and feel good about that we made the right one that fits for us? What are the games and the philosophy of the programming languages? Well, even though a lot of these programming languages are very alike, and I'll do some contrasting and comparison in a second,
21:41
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.
22:03
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 Albert Camus on,
22:20
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.
22:42
But like with novels, it's kind of hidden. And if you're new to it, 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. So it'd be nice if there was something a little more concrete that you didn't just
23:02
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
23:20
for programmer happiness. There was a specific goal that Matt 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
23:40
or clarity or simplicity, 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 underpinning it.
24:02
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 that drive Python. And what I loved about finding this
24:20
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.
24:41
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,
25:01
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 contact and just by itself, that also sounds like beautiful is better than ugly.
25:21
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. It's based on deriving elements of the code, inferring those, rather than spelling them out.
25:41
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.
26:02
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.
26:23
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 only 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. Where do we place the conditional at the beginning of the sentence?
26:41
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.
27:00
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,
27:21
because I actually completely respect someone who would look at this and go, that's me. 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.
27:41
And that is why Python doesn't work for me. It's not about the meaningful indention. 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.
28:02
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.
28:20
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
28:41
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?
29:02
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.
29:21
We can see whether it fits who we are or not. And I wish I kind of had jotted this down 10 years ago, because it would have saved a lot of meaningless debates. In, 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
29:41
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 an 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.
30:01
It doesn't reflect any of these things. We have that to get these other things that we care about. An Omakase 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.
30:21
They're all debates about, 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 in circles.
30:43
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.
31:01
A bunch of, funnily enough, you can almost see them out here. Dave Thomas is on the second to top left. Martin Follow is in this group. A bunch of these people who had a huge influence on the Ruby on Rails community were present at this meeting where they decided basically to encode their values
31:20
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,
31:43
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.
32:01
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.
32:22
You can't plant roots in features. You can't plant roots in easier, in 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.
32:41
There's longevity in that. I think a lot of the people who've 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
33:01
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
33:21
and I don't really care which specific community I'm in. I'm just a programmer. Again, one of those things, when you hear it the first time, oh yeah, yeah, totally, that makes sense. It shouldn't be tied to anything. What? Why? I think, actually, a main source of that anxiety that we feel, the openness we have to fud,
33:41
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,
34:01
perhaps because they've been told that, 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, blah, but I still find that unless you place your roots in something specific, you're just gonna waver around.
34:24
Emil Durkheim was a 20th century sociologist and philosopher and he has this great quote where he's reflecting on sort of what was going wrong in society at the turn of the century, why suicide rates were going up,
34:41
and all these ills that he saw 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
35:02
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,
35:21
then 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 alert to
35:42
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
36:02
often leads us exactly to Louis C.K. 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,
36:24
you're probably not going to be as likely to be constantly scared about missing out, right? Because you based yourself in something that's deeper than just easier, faster set of features that could be duplicated or changed tomorrow. Okay.
36:42
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
37:02
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, who's the architect famous for pattern languages of how to build buildings, was a huge inspiration for pattern languages and software,
37:21
for the agile movement, for a lot of the Kent Beck and Ward Cunningham, took a lot of inspiration away from that and I said, 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.
37:43
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.
38:01
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,
38:22
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,
38:41
of being stable in a group and not being sort of 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.
39:02
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.
39:22
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 programming world to learn from that.
39:42
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
40:01
and shine a light for how others should be and behave. And if I think of my two favorite patron saints of the Ruby community, they're Y the Lucky Stiff, the patron saint of weird, who wrote a introduction to Ruby
40:23
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 Y the Lucky Stiff is weird and it's pretty cool.
40:41
Unfortunately, I think this is also part of the patron saint thing is they're not here anymore. So Y 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
41:02
is Jim Weirich, 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
41:22
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 religions 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
41:42
and it doesn't have to be that way either, right? We can still, someone can read the Rails Doctrine and go like, oh yeah, like most of these things, totally me, 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.
42:03
And there's still also differences. Sushi buffet versus the 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
42:21
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,
42:45
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
43:01
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,
43:20
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. Like we kinda settled a 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 is no.
43:40
And we arrived at that answer a long time ago. The focal point of attention, where we have the battlegrounds of principles and practices around these faith-based ideas, like TDD. I called this out in 2014, and I just watched that
44:02
talk back again, and one of the things I sort of used as a way of squarning 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,
44:20
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.
44:41
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. If you can't resolve something in about 30 years,
45:02
like, probably you're not gonna resolve it. We're very not gonna come to a conclusion of like all programs henceforth should be either dynamically typed or statically 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.
45:23
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 find me pure and happy
45:42
and a responsible adult? And the answer's probably not. It 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
46:02
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
46:21
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.
46:41
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
47:00
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
47:21
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.
47:42
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
48:01
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.
48:23
You got to no completion. This is completely absurd. You're trying to make a change over here and 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.
48:42
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.
49:02
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?
49:21
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 barcode, basically DRM the food and make sure that it was valid food and that there hadn't been a spinach recall. They probably worked on that for like 18 months.
49:42
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.
50:04
There's something depressing in that. And I don't just mean that to rack 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.
50:20
The number of features I built at Basecamp where I fucking spent two weeks, built it all the way to conclusion 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
50:41
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 the new one.
51:03
This is not, perhaps, where I'm gonna 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
51:21
in a puddle of disappointment. Lots of programmers 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.
51:42
Not a drop would have fallen out of 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 he or she is tracing some
52:01
transitive dependency that broke. I 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
52:24
and that's bound to disappoint you. And there's sort of different ways of coping with that absurdity. Mr. Peanutbutter from Bojack Jackson has this great quote that the key to being happy
52:40
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
53:00
is actually heaven. Sergeant Apoc from Aliens. A day in the Marine Corps is like a day on the farm. Every meal's 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
53:21
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 that that sludge on the table in front of you is a banquet and all of a sudden your entire world falls apart. Now, I think that Camus and the myth of Syphysis
53:41
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
54:02
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 gonna be better off.
54:20
And finally, I think if we can accept that A, we're not computer scientists. None of the people in this room who do work on Ruby on Rails or with Ruby on Rails most of the time do anything that resembles science most of the time, I think we're gonna be better off. If we accept that it's the passions
54:42
that drive us most of the time. It's not the passions here in this image, which is the elephant and logic, reason is the rider. You're along for the ride a lot of the time. You're along for a ride with your anxieties, you're along for the ride with your insecurities, you're along for the ride with the absurdity
55:01
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.