 All right, let's start by establishing my program of credentials. Hello, world. How come I used to say hello? All right, so I kind of enjoy reading about all sorts of random stuff, which basically means I spend a lot of time just clicking on hyperlinks in the web. And I'm interested in publishing, and I came across an interesting article about one of the leaders in international publishing. Which is the Jehovah's Witnesses. They actually publish in, I think it's 47 different languages. And back when they started doing it, there was no software that let them do that. So they actually wrote their own software to be able to publish in these 47 languages, and they actually created their own fonts in order to let them do that, because this was before Unicode and everything else. And that led me to like a whole stream of memories from my childhood. Because back when I was growing up, my parents subscribed to The Reader's Digest. And the link between The Reader's Digest and The Jehovah's Witnesses is they actually used the same publishing system. Well, the rumor is they actually used the Jehovah's Witness publishing system to be able to publish in all the languages they published in. So The Reader's Digest started about 100 years ago, and it was designed to bring the word to the masses. It was interesting reading. They would take articles from other magazines and other sources, sometimes abbreviate them, and then publish them. They were there for kind of educational purpose. There was always the thing about it pays to increase your word power. And this kind of thing, how to speak better, was one of the articles they used to have. They always had exactly 30 feature articles in each issue. Because the idea was you're supposed to read one a day. And that was your assignment for the month. And then in the next month, you get a fresh 30 to read. So The Reader's Digest was pretty cool. And as a kid, I always used to like reading. Down the bottom of the pages, they had little anecdotes and jokes and stuff. And I always remember just that was kind of like my reading. It was just like these little small snippets. Now, that then led me to Lord Twinsmuir, who is actually the son of a guy called John Buckham. Now, how many people have heard of John Buckham? Cool, excellent. Nobody. If you had grown up in England, my father's generation, that would be, that's trivial. Because he's like the Tom Clancy in England of that kind of period. He's actually a lord, but he wrote, John Buckham wrote all these kind of spyish fiction things, quite popular. The one you may have heard of is 39 Steps, which Hitchcock turned into a movie. His son, this is I think his second or third son, John Buckham was like bigger than a life character, like a Hemingway kind of character. So he would like, he would go do crazy athletic things. He wrote all these popular books. He was the governor general of Canada. So obviously, he used to walk around the house naked, pontificating about stuff. So clearly, his son grew up with a number of problems. One of which was that he wanted to be a writer as well, but he was eclipsed the whole time by his father. So he ended up editing the Reader's Digest in the United Kingdom for three years, and clearly he resented this greatly. So his big claim to fame is that he actually wrote a story. How my dog taught me to pray and got the Reader's Digest to publish it. And it was a joke. So I thought that was really, really cool. And given that I'm not invited to this conference, but Moose is, I thought I would follow suit. And my talk is on how my dog taught me to code. And I'm gonna do it in Reader's Digest style. I have 30 articles to cover, which means I got about 80 slides, 70, 80 slides. I only discovered when I got down here that I've only got 30 minutes to do it in. And I am really lousy when it comes to being scripted. So, what I wanna talk about are the things that I think are important when you're programming. And they go from the ridiculously low level to the ridiculously high level. Let me start with just one, okay? So there's 30 of these things. The first one I wanna talk about is forget the rules. Everybody out there is an expert on how you should do things. They keep telling you how to do things. So people come up with all of these schemes for how to design code. And they're quite often like five points and they'll make an acronym out of it solid or whatever it might be, yeah? Doesn't matter. What I want you to do is to forget them all. Because you can drive yourself crazy trying to follow all of these different rules. Here is the only thing you have to know. Good design is easier to change than bad design. That's all there is to it. There is no other metric for what makes a good design. So when you're coding and you come to a decision point and you say I could do it this way, I could do it this way. All you have to do is ask a year from now, which of these will be easier to change and do it that way, right? That's all there is to it. Layout, see I said there'd be some at low, low, low level. This kind of thing drives me insane. Don't do it. This code actually compiles perfectly cleanly. It's nice, but a ruby code. It contains a totally insidious bug that means that it actually corrupts the output one time in 50. I bet you can't see the bug. Why? Because the layout is crap. It looks like some on vomited letters on the keyboard, right? It's disgusting. So let's tidy it up a bit. Here we go. That's probably how most of you would write this. Can you see the bug yet? No. All right, let's tidy it up just a little bit more. Can you see the bug yet? Let's tidy it up one more time. Can you see the bug yet? Yeah, Florida. Thank you. Perfectly valid ruby. It concatenates the two strings, but it just means the Florida entry only has three rather than four columns, right? This bites people all the time. Lay out your code nicely and you can see it. You say nobody does that, Dave. So this is actually a bit of code from our online store that looks up towns in North Carolina that will work out sales tax. We'll actually work out what county they're in. And yeah, I do lay it out that way because it's easier to do. Here's some real life code, right? I don't know what it is with you youngsters, but you seem to think that terminals are infinitely wide. Everybody knows that God created 80 column terminals, right? Code like that, right? You will not go to heaven if you write code like that. So at the very least, do something like this, make it look like that, okay? But you could do better than that because does that express intent? No, that lays out nicely, it does not express intent. How about laying it out like that? Then you can read it. You can see what it's doing. Lay out is communication and what we do is communication. Here's another one. And yeah, it wraps and it's ugly and it's hard to see what's going on. So the same kind of thing. If you don't have an editor that will do that for you automatically change your editor. Cough, Emacs, cough, all right? But even that's kind of a little bit, the punctuation looks a bit strange. So how about thinking about doing it like this instead and using the little ruby percent I thing. But if you're gonna go to that trouble, then go the extra mile, right? Select those lines, alt X, sort lines and put them in order. So it makes it easy for people to see what's going on. Yeah, small things, big wins. This is an actual line of code from Rails. It is 490 characters long. The reason it's there is because everybody is afraid to change it. We write it like that. It's code. You're supposed to make it readable, okay? Layout matters. I'm way behind time already. Okay, inline comments. Inline comments are screaming at you to say get rid of me because what you've got is a function. So if you have code that looks something like that and you have this beautiful comment, you're really proud because you wrote these comments. Yeah, don't be proud, be ashamed because you probably should have written that. Yeah, you probably should have extracted out the complexity, given it a name and made it into a function because that's what the comments are telling you to do. And of course what you probably should be doing is using elixir because that lets you write it like that. But while we're talking about names, use your names as a design tool. If you go back to here, you could have written the thing like that but you probably wouldn't because you probably say I'm gonna help communicate so that people are reading what my code does. So you'd probably use decent names like that. But let's take that a step further. Let's think about how names help us do design. No class ever starts out like this. But most classes end up like this. They end up being this big bag of stuff. So you look at that and you think, okay, how could naming help me with this? Well, the first thing I could do is I could say, well, these things are in common, like name details, date of birth, address employer. So maybe I could be really good and extract them out into little separate modules. Yeah, and that way I have names that say what they do and they're independent and that is a really big win. But then what you should do is look at that and say, what am I actually doing here? Is there any difference between that and that? Well, yeah, it's a bit better to read but it's still ugly in terms of the design side. So I would say once you've gone there, take it a step further and turn it from a big class into a container class. Names help you see that kind of thing. Honor names. And it's related to honoring names. Rule, no more class base. Class person's less than an active record, colon, colon, base. That means there's a class base lying around there. In fact, there's many class bases lying around there. Here's an example from SNMP. SNMP called manager. Why is it called manager? Because whoever wrote it thought, well, manager sounds pretty important and this is pretty important so therefore, I'll call it manager. It's nothing to do with managing. It's actually a host connection. Whenever you see class names like factory, processor, implementation, holder, in fact, any class name that's named after a pattern. Delete it. No more names like that. Okay, personal pet peeve time. Name gems and libraries consistently. Please, here's the first 20 or so lines of our gem file. Gem file, oh yeah, it's our dot lock, I think. All right, look at this. Does anybody spot a pattern? The answer is no because there isn't one. Okay. Please, please, please name gems in some kind of sensible way. And although cute names are very cute, they really don't help when I've got 100,000 gems out there and I'm trying to find the one that I really want. So just do me a favor and keep them simple. Moving on, don't code the abstraction, refactor it. There is a wonderful tendency and I appreciate it and I do it myself all the time of you're looking at code and you think, hey, you know what, I could make this into some kind of like library, some kind of abstraction and then I could build on that and I could reuse it, right? And all of these are good words in the industry. So, what people tend to do is they look at a problem. Okay, I gotta strip the comments out of the, oh, I gotta strip the blank lines out of this file. How am I gonna do that? Oh, maybe I could write a state machine. Yeah, a state machine would be a good way to do that because that's an abstraction. Let's do a state machine. Hey, you know what, if I'm gonna do a state machine, I could probably do a DSL that would allow me to define the states. That's really, really cool. So let me do a DSL for the state machine. I could probably do a DSL that would allow me to define the states. That's really, really cool. So let me do a DSL for the states but they might get into this problem writing that DSL because it's not quite working. So I am gonna write a DSL, Metaprogramming Debugger Logging thing that will let me log the changes that my DSL is making to the data structures to find out why it's not working. Four days later, I have still not stripped the blank lines out of the file. Renan Stimpe gave us a name for this. It is yak shaving, do not do it. Next rule, do not use patterns. Okay, we are being handed down as if they were commandments. As if they were handed on tablets of stone, we've been handed down this idea of design patterns. And we use them all the time, observer, singleton, blah, blah, blah, blah, blah, right? Do not, do not code a pattern because it's just the devil tempting you. Right? The devil is saying to you here, take your code and make it work my way. Patterns are not recipes. All patterns are therefore is so that you can communicate an idea to somebody else. They are idioms, right? They are nothing more than naming conventions for ways of doing things. So code first, and if you happen to have created an observer, cool, then you can say to your friend, hey, look, I've created an observer. But please don't start off saying, oh, let's go see how I do observer pattern. That's not the way to do it. Next point, avoid inheritance. Inheritance is probably the most misused feature of all object-oriented programming languages. In object-oriented programming, you have the concept of a class. And a class is nothing more than a factory that gives you a set of methods. So you can use a class to create an object, and the object has its own state, and it has the methods that come from that class. And then people say, okay, well, I need to use those methods in somewhere else, right? I need to share those methods into somewhere else. How do I do that? Oh, I subclass. And so you end up with these class trees that have nothing to do with each other, that are there simply because people needed to get the methods from A to B, right? The only time you wanna use inheritance is when you have a true is a relationship, and A is A, B. Here's the problem. In the real world, there are almost no is a relationships. It's really hard to find is a relationships, which is a clue to say you should never use that little less than sign on your class line. If you need to share methods, that's what modules and includes are for. Next point, Postal's Law. Anyone can tell me what Postal's Law is? John Postal was big in the original, isn't it? He devised a lot of the original RFC type protocols. And you can actually, speak to me, kind of like there's many interpretations or many ways of expressing it, but be liberal in what you accept from others, be conservative in what you do with it. What this is saying is that if you are to participate in a big world, then you have to be capable of accepting things that that big world throws at you. But you can't trust it. You have to be conservative with what you're given. And when you look at the success of these incredibly simple protocols, like SMTP for mail, or HTTP for the web, which are basically just lines of plain text. When you look at the success of those, you can see that there's something to this law. I say that we're gonna need to honor this law going forward. And the reason I say that is because we are gonna move very rapidly into a world of federated random systems. And our systems are gonna have to be able to talk to each other. And that's gonna be tough, because you're not even gonna know what these systems are that you're talking to. So we're gonna need to be like this. We're gonna need to find ways of being open to what people give us and then be very careful with what they give us. I learned something from Chris McCord yesterday when he was talking about how he designs his services in Elixir. And he does something like this. He will accept a hash that contains the various parameters and he will create a new hash containing the parameters that he actually wants and pass that on to the next person. Now, what I would tend to have done is just take that parameter hash, say, hey, look, the keys are the same. I can just pass that parameter hash straight down to my authenticator. But that means that anything anybody passes in also gets passed down to the authenticator. So if they discover I'm doing this, they could put role equals manager in that incoming hash. Yeah? So hashes, JSON, whatever, is a great way of plugging these together. It's open. You can add to it. So it's a really good first part of Postal's Law and then this kind of technique is a really great part of the second part of Postal's Law. Next, listen to the code. When you're programming, I am sure you have all experienced this. You're sitting there and your coding and the code pushes back. And you go, damn it, you're just code. I'm gonna code harder, right? And you push back on the keyboard and it pushes back even more. You end up swearing at the code and the code ends up swearing back at you and eventually you may wrestle it into submission but no one's ever happy, right? When the code pushes back, it's trying to tell you that you're doing it wrong, right? I guarantee you every time it pushes back, what that really is is a little voice in the back of your head saying, Dave, this isn't the right way to do it. Listen to that voice. I don't know how to explain this in a minute. What we work with programmers is data. What we do to that data is transform it. So we need to think of the two things separately. When I design, not when I design, when we design, what we're really doing is we're looking at the data, the structure of the data and how that data relates to other bits of data. But when we code, what we're doing is we're making those transformations. The problem is that we tend to wrap that all together into the concept of classes and we do both at the same time. So is this my subtle way of introducing you to the idea that you should be doing functional programming? Of course it is, but it's actually, I have found that by switching to this, it's made my life infinitely easier and it's made my programs a lot easier to design and write. If you are gonna stick with OO programming, then my next rule is simple. Stop designing with classes, start designing with objects. It's OO programming, not CO programming, yeah? But what do we do? No, the first thing we type when we're writing code is class something or other. The first thing we do when we're drawing pictures is we draw class diagrams and we produce these little hierarchies just like Victorian scientists doing butterflies, right? It's not true, that's not the real world. The real world is not hierarchical and you cannot design the real world to be hierarchical. So please, stop designing using classes. If you use that data-oriented approach I'm talking about, then naturally you'll find yourself using objects and not classes. One of my favorites, delete the tests. I didn't get booze, hey. We all have been brainwashed into the idea that if we don't write tests, we are subhuman. That's not the reason we're subhuman. That's to do with bathing and other hygiene issues. Right, tests are there to help us. And fundamentally tests are there to help us with design because by writing tests, we get to be the first users of the code we've just written and therefore we get to see if our interfaces are good and we get basically to get some feedback before we move on, yeah? So I tend to, and also to make something testable, you have to make it decoupled and therefore you're gonna tend to lead to better design. So I view tests as being fundamentally a design technique. Now, you get to a point, your system's been live for three years and your tests are taking away a very long time to run, but every time you make some fundamental change, you've got to go and change 50 tests. They're just getting away. So my rule is delete them and see what happens, right? I, our online store had, I can't remember, it was like 4,000 or 5,000 tests, unit tests, and I recently had been rewriting it just a little bit to make it more mobile friendly, but in the course of doing that, I changed quite a lot of the low level stuff and yeah, all the tests start working and I had the most liberating morning of my life when I deleted all of the tests except the ones that are to do with money. Everything else just went. And suddenly I was about 10 times more productive. Having said that, consistency is key, do nothing without feedback. So don't start doing something until you know how to know that you're done. Yeah, and that's not always easy, particularly if you've got a big job. So what does that mean? Don't do big jobs. Break them down into smaller things where you can tell whether you're being done, whether it's done. And that, yeah, tests are useful for that. New tests, a test that you write and maybe throw away. Who knows? Divide and conquer. This is again, back down to the low level. If you're faced with code, okay, let's start at two levels. First of all, let's look at code, okay? Some code, the time it takes to do something increases non-linearly. It goes up faster than the complexity you would indicate. So as the complexity increases, the effort goes up faster. And that's bad because it means at a certain level of complexity, you're basically up in the lifetime of the universe kind of complexity of time. You can't do that. And over the years, many people have worked on ways of fixing that. And the most obvious one is this thing called divide and conquer. Because down at the bottom of this curve, it looks kind of linear. It's only when you get further up that it gets out of control. So break the problem into smaller chunks. Each one is fairly small. If you add up the times for each one of those, it's a lot less than the time if you did the whole thing at once. Divide and conquer. It's the basis of just about every sorting algorithm out there, right? A divide and conquer will take n squared and turn it into n log n, right? Which is way, way better. So divide and conquer. I bump into a situation maybe once a year where I discover something that works great if I'm just playing with it on my laptop, put it into production, dies of death because of volume, and you fix it by doing something like this. It's not the same as MapReduce, but you can solve it using MapReduce. But divide and conquer applies everywhere. Because as you know, the complexity of writing a large system is way more than the complexity of writing a small system. And yet, we insist on writing these big balls of mud. In fact, this is actually a better representation because what it really is is a whole bunch of sticks tied together with bits of string, right? Which is pretty much the way our systems look. I think this comes from Australian survivor. Yeah? It's a good reason not to go to Australia, if you ask me. I mean, the fact that people will actually do this, I mean. All right, anyway. So how do you do that? Well, you basically don't write monolithic systems. Which sounds really trite, and it's really hard to do. I know that because I happen to own three very large monolithic systems that I'm desperately trying to split into small systems. But try to write things in small chunks, self-contained chunks. One thing you might want to do, it's always easier if you have a rule. You maybe have a one-day rule. If it takes longer than a day, don't do it. Throw it away. Or a half-day rule. But choose some period of time. Chad Fowler says that they write most of the services from Wunderlist in a couple of hours. And that's great, because if you screw up, you throw it away and start again. Who notices? You may have just been a coffee. You know, just choose a rule you can follow and use that as the boundary. And one of the tricks for doing that is if you use message-based APIs, then you'll find you've got greater isolation. It's easier to write these small self-contained chunks. Related to that, every library couples you to a tree of arbitrary whims. This is a representation of the gem file dependencies in our online store. We have 124 gems in our gem file. We have 511, I think it is, in our gem file.lock. And frankly, I don't know what about a third of them do. Honestly, I have no idea what a third of them do. What I do know, though, is if I leave my code for more than a couple of months and then do a bundle install, it stops working. And that's because we have these crazy dependencies. I'm getting rid of them. I'm going through and I'm having great fun deleting out the gems. And sometimes it means I have to get, you know, a gem will be there because you needed three lines of code in that gem, yeah? I just replaced the three lines of code, I write it in line. Or even better, I go to that gem and copy and paste it out into my code. Why? Because copying and pasting it actually makes it more maintainable, right? They line to you. What is the most powerful to... If you use an IDE, God help you. What is the most powerful icon in your IDE? It's that one. Be joyful whenever you throw something away. Clearly, if you're doing something and it's not quite right, right? Don't fight it, throw it away. But sometimes, even if you're doing something that is right, throw it away. All right, quite often I'll be doing coding and I'll be kind of like battling with something. I'm not sure how to do this, whatever else. And I'm coding and coding and coding and I'll finally come up with something that just works and I'm kind of happy with. The next day, maybe about a third of the time, I'll throw it away and start again. It may have taken me two days to get to that point. It will take me the morning to get back to where I was and what I get back to it well with is infinitely better. Why? When you did math at school and people were showing you proofs for things, right? And there would be some like the quadratic equation. How do you get to that minus, plus or minus, whatever, yeah, that one, right? How do you get to that? And they'll show you some magic proof that involves steps that no human mind could ever possibly use it. Oh, I know, I'll go from here to here, right? Because that gets me to the solution. Well, no, no one did go from here to here. They groped around in the dark for six months. They found the solution and then they worked backwards having explored this space to come up with a really elegant solution. They threw it away and started again. Next one, never call when you can send. What this means basically is try to write every system as if it was a distributed system, right? Decouple, force yourself to write decoupled systems. You will thank yourself and people that follow you will thank you greatly. It all comes down to this idea of divide and conquer. If you're writing distributed systems where your messaging API is the only way you can talk back and forth, then you're pretty much guaranteed to be writing small little services. It's a way better writing code. If you've been writing webby design-y stuff, then you'll know that the common mantra now is design mobile first. Okay, now that's so much last month, right? This month is accessible first because I've been doing that with our new website and I've discovered that if you write accessible first then you get to learn what's important and what's not. And then you get to throw away the stuff that's not because you know what? If it's good enough for your accessibility, for your reasons that have disabilities, it's good enough for all of your users, right? You don't need all that fancy crap and it is so, so liberating. So I strongly recommend writing accessible first. Please know your history, please. We are an industry that spends its entire time looking forward. Do a little, spend a little time looking backward. Little test, when was the first language with classes, dates, roughly? Similar, back in the mid-60s. When was the first pure OO language? Small talk was in the 70s. You could argue maybe it wasn't small talk but I think it's small talk. When was the first language with proper declarative platen matching? No, that would be prologue also in the 70s. Statically typed full functional language. That would be ML still in the 70s. When did we have a language that featured proper tree data structures, automatic storage management, dynamic typing, full conditional logic, higher order functions, recursion, and a full self-hosting compiler? What year would you say for that? Actually, 58. Yeah, it goes back a lot further than you think. These people were doing this on systems where you were coding an assembler if you were lucky. Respect them and learn from what they knew. Don't reinvent the wheel. All of the people that I respect are language designers. There's more than that but this is a ruby crowd. They all study the past. You can talk to any of these people and they can go on at great length about languages in the past because they learn from them. Please do the same. Similarly, learn a handful of useful data structures. I have no idea which ones are useful to you but there are some examples up there. Just some stuff that you can go down and pick up because every now and then you're gonna have to solve some problem that needs a data structure like this. And you may say, oh, I don't need to know the data structures because I'm gonna use a library. No, because the library is not gonna let you understand the behavior of that data structure. You need to understand the trade-offs that are involved because every data structure has a trade-off. Learn data structures. Similarly, learn a handful of useful algorithms. This is kind of like eat your vegetables, right? So I don't know what they may be to you but stuff that's cool to understand, quicksort. Not necessarily because you wanna write a sort from scratch but because you wanna understand how dividing conquer works. Radix sorts because they are just so cool. Boy or more, Robin Cart, there's how you do pattern matching in strings, transitive closure because it's how you work out what's related to what. And there's some really trivial matrix-based algorithms or transitive closure that I have seen people try and do transitive closure just like for themselves and it's like nested loops and all sorts of crap and it takes like five years to run. No, right? Shortest path algorithms. There's a whole bunch of interesting stuff to do with shortest path. Topological sorting. Again, what are my dependencies? Topological sort, we'll tell you. State machines. Oh, I love state machines. Please, we should all be using state machines. Get familiar with them. You don't need a library or a gem to use state machines. You need a hash, right? That's all there is to it. There's cool books. There's a whole bunch of good books out there, right? Sedgwick is my favorite. I've had each edition of this come out, I think this is the fourth edition, but stick to it. How am I doing for time, Jim? Wake up, Jim. How long have I got? In it, easy. I'm gonna actually finish. Plus a change, which for the non-French speakers is the more things change, the more things stay the same. I, this is not accurate, but it feels to me like software has 14 year life cycles. During the first 14 years, we come up with some technology that is gonna change our lives. And slowly over those seven years, it moves from being like the earlier Dr. AlphaGeek types into the mainstream. And suddenly everybody is doing it. And after about seven years, the AlphaGeek start saying, well, wait a minute, this isn't Alpha anymore because all these commoners are doing it. So I need to go find something else. And to do that, I have to justify it. So what I'm gonna do is I'm gonna say, all that stuff I was telling you seven years ago, that's crap, all right? I've changed my mind. I'm gonna do it this way instead. And they basically react against what they used to do and end up doing it this different way. And they sort of like push and they push and they push and gradually people start coming along and following them. And at the end of the next seven years, everybody's followed them to that point. And they look around and they suddenly go, whoa, it's crowded in here, what am I gonna do? Oh, I know, I'm gonna go back to what I said 14 years ago and now that's the best way of doing it, right? And keep pushing. And you watch, there are cycles. There are cycles of popularity that go on for, I don't know, maybe it's about 14, I can't tell exactly, right? But there are cycles. And it's a bit like that old dialectic material thing, right? Where you have to have two opposites that come together and create something different, right? It goes on the whole time. But because we don't know our history, the saddest part of this is that each cycle repeats exactly the mistakes of the previous cycle. Except it's more complicated. So please, please just be aware of this. And I'm guilty of it as much as anything else. I mean, I pushed Ruby because I thought Ruby was fantastic, right? I evangelized Ruby. And now I'm out there evangelizing functional programming because I honestly do believe it's better. But at the same time, I'm causing all of this kind of, discontent, oh, maybe we should be doing this instead and this kind of stuff, right? Don't just listen to people like me that say, hey, functional programming's the future. Because seven years from now, I'll be saying, oh, you know what? Cobol's great. Instead, you need to be, yeah, looking at what these people are saying, but through the lens of a knowledge of history, through a lens of, yeah, but what they're doing is exactly the same as Nooth was doing back in 1976. And that didn't work because of this, this, and this, right? Look at all of these great ideas critically. And the only way you can do that is by knowing history. Who knows what miss one means? You know what? It's a typo. It's a typo on the slide. It's mince one. I'm sorry. I'm sorry. Mince one. Max is nice. So we are nice. Gotcha. Good. I was wondering about that. Sorry. I started going in that second, that's like. Yeah, yeah. It's a silent N. It's a silent N. Yeah. Why is this significant when we're talking about programming? It's because being nice is about thinking about other people. It's about being considerate. And when you're coding, you're communicating. You're communicating with a machine and you're also communicating with future generations of coders who are gonna be swearing at you. If you start to think about them, if you are nice, if you are considerate, then not only will they like you more because you've made their lives easier, but you'll like it more too. This is kind of like feedback thing that goes on. So as a community, I don't like the word community because that implies there's something, we just all like the same thing. I don't know what the word is for a group of people that like the same thing, but we tend to be nice, right? Apply that as you code as well. Think about future generations and it'll help yourself. Oh, I like this one because it always end up with an argument. People talk about flow, right? Flow is the state you get into where you start doing something and you look up and it's three hours later and you had no idea that all that time passed, yeah? Flow is the state you get into when you delegate to the kind of unconscious, subconscious part of your brain. So for example, if you drive from here down to San Antonio, ignoring the construction bits, you probably will be in a flow state when it comes to driving. You can quite often get 10 miles down the road and not actually remember doing the driving because you'll have been thinking about the music on the radio or whatever else you've been doing. You'll be in a flow state, okay? In learning theory, this is really important because it's the state, in order to get to that state, you have to practice and practice and practice like with driving, right? A brand new driver sure as hell is not in flow state as a driving I-35, right? Because they have to be thinking consciously about all that they're doing. But the more you do it, the more you learn not to have to think. But you are thinking, it's just become a reflex. In the same way if I throw a ball to you, you could catch the ball without consciously knowing why you're moving your arm that way, why you're closing your hand when you're closing it. It's become internalized. A baby can't catch a ball. They have to think about it. So what that's called is tacit knowledge. Tacit knowledge is knowledge that you have without knowing that you have it. And you can do that when you're programming. And for a long time, people thought flow state was really good because if you're in flow state, the idea is you are productive as hell, right? You're just churning code out because your entire being is focused on churning out code. But you know what? If you look at a racing driver, I mean a real racing driver, Formula One, not this NASCAR crap, right? But if you look at a racing driver, you can pretty much guarantee that they're concentrating on the driving. They're not thinking about the music on the stereo because they don't have a stereo. But they are not in a flow state. They're concentrating because they have to. They have to think about every single thing they do. When you're coding, if you're in a flow state, you know what? All you're gonna do is do what you've done before. You're just gonna reiterate what those patterns are in your head. So try not to, try to break out a flow state, at least have some part of your brain looking at you doing what you're doing and saying, excuse me, Dave, that's crap, stop. Yeah, flow stage dangerous. Change your course. Contribute to open source. Do not be a vampire. I don't know about you, but my entire life is possible because of open source. I mean, if I look at the stuff that I'm writing, the stuff that I'm using, in the old days, in the 80s, I had to pay for software. I would pay for compilers. I would pay for databases, right? And as a result, once I'd committed to paying $800 for a seat compiler, that's what I would write in. The whole time I had no choice. I couldn't afford another one. Same with databases. But now we have the choice. We live in this incredibly rich time. And not paying back is just criminal. So please pay back. Pay back by contributing projects back. A lot of what we do, even in our commercial work, we can take bits of it out and make it public and not hurt our companies. Let's do that. Add functionality, if you're using some library, some open source, and you have to add functionality to it, contribute it back, all right? But this is kind of going down in order of increasing the decreasing difficulty. Bug fixes, we all find bugs and stuff. If we fix them, contribute it back. Documentation, it's really important and is often forgotten. Contribute it back. And bug reports, if you don't actually write the bug fix, even contributing a bug report, adding a GitHub issue is still really important and it still adds to the overall value of the system. So please contribute back. This is actually aimed at me. Because I come to conferences and I say things like, I love Ruby, yeah? And, you know, in a way I do love Ruby. But the more I think about it, the more I think, actually no, what I love is what Ruby lets me do. All right? It's the facilitation that I like, not the language. And it doesn't take anything away from Ruby. Ruby is a spectacular language. But fundamentally, loving the language is relatively sterile. Think about what you do with it and that's what you love. And that allows you to be unfaithful to a language without being unfaithful to yourself. It allows you to experiment with different languages and try to say, does this let me do this better? Or in a different way, or do I learn something? Try not to befall into love with the tools because when it comes to things like languages, well, actually with everything, familiarity breeds complacency. And complacency is stagnation and stagnation in our industry is death. Almost last, I think that, and this is not a religious thing, God knows, but we are living at a time which is staggering. We are living in that kind of science fiction future. Yeah, we don't have flying cars. We've got cars that drive themselves. We don't have, we have drones that we can program in Ruby and have them fly around and do wild things and kill people. But we live in this time, we have open source software. We have access, each of us now sitting there can download stuff that would be unthinkable 10 years ago. And then we can use that to create wild new applications. Expert systems, image processing software, large scale databases. If we want to, we can run up a thousand instances on EC2 to process some big, big data set, run it for an hour or two and then shut it down and it costs us like 30 bucks. It is an unbelievable time to be living in. But sitting there day after day doing the job, it's kind of hard, it's easy to forget that. So personally, I've started like every day just thinking a little bit about what an amazing time. This is, to be a programmer. And I think we should all be really grateful for that. And my last rule is because of that, don't forget to have fun. Thank you.