 Thanks everybody. My name is Matt Clark, as you just learned, and I just learned that Notch is the name of the guy who wrote Minecraft. That's a different Notch, not me. I'm with a company called Notch 8, we're a consultancy up in Portland, Oregon. I also am partner of a code school down in San Diego called Learn, based on Ruby and JavaScript, like most of the code schools that you find across the country these days. So when we just put our first class together in January, they graduated in May, and when we were thinking about what our curriculum wanted it to be, we knew we wanted it to be Ruby. We were standing on the shoulders of the giants who've come before us, like Dev Bootcamp and Hackreactor and Ada and things like that. And then Ruby is what I know and what my partner down in San Diego knows. So of course we're going to do Ruby, but it got me to thinking about how I've always thought of Ruby as a craftsman's language. It's a really extensible language, flexible, you can open anything up and modify it. Are we going to be giving these students a Ferrari and ask them to go out and learn how to drive? And it really isn't the case. Ruby is a fantastic first language for programmers, and I'm going to go into the reasons why that is. So while I was thinking about this and putting this talk together, it reminded me of when my son was three, about 10 years ago, at a Pee Wee soccer game. It was an indoor, oh thanks, an indoor game. And they put bumpers around the basketball court and there's goals on each side. Has anybody ever seen a Pee Wee soccer game? They're really fun, you should check them out. And there's goals on each side and then all the kids who show up get to play. So there's 10, 12 kids, however many are out there. And they kind of throw the ball out there and blow the whistle and then the entire group of kids just kind of mobs around the ball and they all kind of move in this big mass to, they stay over on this side and they move in this big mass and once a while the ball squirts out and they all kind of race after it and every once in a while they actually score a goal. But they don't keep score anything. So this one time in the game, one of my son's teammates scored a goal and Mike was really excited about it. So we ran up and he wanted to give her a high five and she kind of looks at them and realizes what he wants to do. So they kind of set up for this high five and they get ready and they go for it and they completely miss, like just the total air ball of their hands go past each other. And so they kind of reset, remember they're three, they're this tall, they're determined that they're going to make this happen. So they reset and they go again and miss again. And so that's two times. So the third time they're going to make it happen. And so they stand next to each other and they kind of, they think about what they're doing and right at the same time they kind of, they grab each other's elbows and they guide each other's hands in for the high five. And by this time the parents are cheering as loud for the high five as they are for the goal that just got scored. And me included. And so it got me to thinking about, you know, high fives really are a craftsmanship skill that you can develop as well. There's a science to this. You have to get good at it. You have to practice. And you can take the craftsmanship analogy a little further. You have to pair when you're high fiving, right? Because high fiving with yourself is just clapping. So, and you can practice test driven high fiving too, like my son was doing. You know, he, with his, with his teammate, they, you know, they had a, they had a failure and they had to figure out what was wrong. So they use their critical thinking skills and, and, you know, kind of set up an easier test with the bracing on their elbows. So that got me to thinking that we need a high five boot camp. Stick with me. I'm going somewhere with this. And it could be really amazing. I'm thinking that like second and third graders is the right demographic that we can target for this. And we could do some amazing things, you know, in the four months, eight hours a day that we have to train these, these kids to do high fives. We could, you know, get trampolines and we could start to do aerobatic high fives and, and things like that. And, and we could even get, you know, borrow from the movies and get some wires and, and, you know, have some, those amazing kung fu sort of high fives. And my inspiration here was, of course, the matrix and thinking about that scene where they're flying at each other, shooting and how awesome would have been if they would have high fived when they realized they were out of bullets. But it changed the movie, but it definitely would have been an internet meme. So for my son and his teammate, the, getting back to the critical thinking, you know, the logic about, about what they were doing, they, they, they had to, they had to apply reasoning, right? They had a, they had a failing test if we think about it in, in, in a developer talk. And, and they, and they had to think, okay, why are our hands not connecting? And, and they, they, they made the assumption that it was their elbows. And so they tested that and they were correct. And I'm sure that if they had gone further, they would have, you know, got to the refactor stage of red, green or factor and they would have done a couple more and been able to do high fives without the brace. So, so Ruby, really the, the purpose of this talk is it really holds your elbow. It's kind of unique among the, the languages that people typically first start programming in. And I got to admit during lunch, because of Ryan's talk, I almost went back and rewrote my whole deck about the cool things that some of the other languages are doing to help teach people programming. But keep in mind, I'm really focusing on the, the three that, that I, I think people really tend to gravitate towards PHP, JavaScript, and Ruby. So, there's three types of logical thinking, three broad categories anyways. There's critical reasoning, evaluating, evaluating arguments, you know, trying to poke holes constructively, of course. Analytical reasoning, drawing conclusions based on facts and logical analysis, validating your facts and, and sussing out your assumptions and, and figuring out how to test those. And when we talk about critical thinking and critical reasoning in programming, we're, we're usually talking about the logical analysis piece. We're, we're trying to figure out what assumptions we made in our code and, and you know, are they true or not? So, that's the, the how and the why of programming. How is the semantics, right? It's the, the, the, the language that you're writing, the programmer happiness, why we love Ruby. And the why is the, the, you know, being thinking about why we're doing things, why things are where they are and, and such. The how is pretty easy, right? It's, you can be a programmer if you have a WordPress blog and you go to Facebook and you grab this code and you, you plug it into your site and all of a sudden you've got a, a like button on your, on your code, right? Boom, done. You're, you're thinking about the end result. When you're, when you're programming in a how-and-tell, you're thinking about how do I get this thing to work as quick as possible, cut and paste. There's tougher examples. This is small on purpose, but if you can read it, it's PHP and it's setting up a database connection and pulling out some variables and then spitting them out onto a, a web page, I'm assuming. I love the, the top of that. You put your username and password of your database right up there on the website, on the web page. It's awesome. But how doesn't a programmer make clearly? I mean, we need to, we need to, especially, you know, coming up in, in the sort of applications that we're writing now. You need to apply critical thinking to these skills or, or you're going to, once you get on an untrivial apps, you're going to really have, have a hard time. So the why is what we do now, why we do it here and, and why we do it like that. So here's my code. My, my, my talk is light on code. I apologize for that. But hopefully you'll get something out of it and appreciate what junior programmers are, are going through and, and how to better help them along their way. The first why in Ruby, really, when we're teaching Ruby comes on the first day when we write our first spec. So you can see my spec kind of in the middle there. I want to make sure that a default high five gets set with an exuberance of medium. Right. So I run my spec and of course it, well, I've got until I did my defined method up top, it wouldn't have passed. But, and when it didn't pass, I would have asked why, and I would have written my method and pass it. So yeah. So what did I do? I wrote my expectation. It failed because I didn't have that method defined. And so I had to think about what, what I need to do next, why that was failing. And I fixed the problem. This is, this is clearly a muscle memory for anybody who's been programming for a year or two. You guys just, we all get used to this. Just, it's how we write our code. But this is a, this is a brand new concept to people who are just coming into programming and that maybe they've had some experience in the past with, you know, being a how program. I just want to get to the end result as quick as I can. And they haven't thought a lot about breaking their project down into logical components and, and, and testing it and, and being really critical, you know, thinking critically about what they're doing. So our habits define us that at Notch 8 we work with quite a few junior programmers. We, I really value bringing them in and investing in people. I think it builds the kind of culture that, that we have. And it's a big part of it. And it's, it's part of our success. So, but, you know, doing that, you're, you're going to, you're going to get programmers who fall off the horse who forget about their, their good practices a lot. And so most of what I do on a day to day basis is walk around from a pair, you know, from pair to pair to pair, kind of asking what they're working on, trying to figure out if I can help them get unstuck, you know, keeping everything on the right track. And one of the tell-tale signs that the things that have gone, gone south is if someone's, you know, filling out a form and submitting a browser and checking their stack trace to figure out what they need to do next, that's kind of the wrong kind of critical thinking you do about your program, right? You're just, you're focused so much on getting to the end, you don't bother stopping to break things down and write tests. You just want the form to get you to a success state or whatever the case is. And so you, at that point, you know, if they're, they took their, they followed their stack trace off into some other direction that, that wasn't the real problem that they were trying to solve, you know, we'll stop and take, take a step back and we'll look at, at what are the components of the, the problem you're trying to deal with. You have, you know, your models set up correctly. Do you have your controller routed right or whatever the case is? And so we do, we try and get back to that question of why try and get back to critically think about a piece of our code. One of the, it just doesn't decide one of the challenges that I have, or I've set for myself this year as a goal is to figure out ways to reduce that, to kind of lessen that, that, that curve of building up that muscle memory. And it's an interesting challenge as, as someone who does quite a bit of mentoring. So I hear a lot, or I used to hear, I don't hear as much anymore. Maybe, maybe there's people out there who still think this, that new, that they're, they kind of are sad when they get new programmers who just come in straight from, from, you know, learning programming into Rails that they don't know enough SQL. Because after all, SQL drives are, are web backed, or sorry, are database backed web applications, right? You have to know SQL as soon as active record stops doing what you want it to do without a little bit, without SQL knowledge, you're going to be in a lot of trouble and I hear that and I agree with that. But I think that for junior programmers and for people just learning that, that that's getting lost in the, how that's getting lost in, in the mechanics of, of accessing your data. And one of the great things about using Rails and Ruby and a boot camp is that we can, we can get past the, the minutia of working with SQL pretty fast and get into the, the larger concepts. We do spend about a week on it because, like I said, it's important to know that there's SQL down there doing, doing the, the dirty work and getting, infetching your data. But, but it's more important I think that, that new students learn the concepts behind how objects relate to each other at the model there. And so I really appreciate Ruby's ability to kind of abstract that away and, and it allows, I still think it's important that, that all programmers get proficient in SQL, but it, it allows us to, to defer that cost where they can do that on their own or, you know, learning how it's really just, or sorry, learning SQL is just learning, is just memorizing how SQL works. So DHH talked a little bit, I think last year or year ago about how we're software writers, we're not computer scientists or programmers or engineers and things like that. And, and I think that's really critical, especially for new programmers when they're, they're thinking about what their code, why they're writing their code. There's, it's more important to write readable code, right, for, for your coworkers and for the people to come after you. And sure our, our computers are going to be reading our code as well, but, but that kind of comes second to being able to, to describe what you're, what you're doing in your code so that others are able to understand you. And speaking of DHH, you've all heard the look at all the things I'm not doing. Well, this is the, the next thing that he said and it doesn't get the, the sound bites as much as the, the first one does. But I, but I think it's really important for people just learning to use the Rails framework that they don't have to worry about all the required statements in the, and where code is belongs in. It's kind of like a minesweeper. I saw somebody earlier playing there, sitting in front of me. And remember that game where you get a board and it's all kind of grayed out and you don't know, you don't have any context of what's going on. You start clicking the, the boxes and then the, that shows you how many mines are next to you. And so you kind of gradually expand till you can see the whole board. Well, that's a lot like what learning out of program is, right? You, you, you just start at one little piece of a really large application, especially in a framework like Rails. And it helps in, so it, you know, it helps people keep focused on, on a, on a chunk that they can understand. So constraints are, are the other, the flip side of this coin, right? It's why we don't have to write all those required statements and why our router works the way it does. And it can kind of become a crutch for, for new developers. But I think it's a good crutch for that same reason that I, I just talked about. It's, it's the, the way that they can get understanding of smaller components of their application without having to understand the broader why. Of course, you know, we, you try and get as broad a depth of knowledge as you can as, as people work through the material. MBC is a big part of that and design patterns and I struggled with where these fit in my talk because they're kind of outside of the how and the why paradigm that I'm trying to build. But they're, they're again a crutch for understanding the why. They're, they're really depending on people who come before us who are smarter than us saying these patterns work to solve these problems. We have to be careful, of course, with, with new people because once they get a hammer and everything's a nail and design patterns can get abused. But even those situations are constructive for, for people because you can start to talk about, okay, why did you choose to use the composer pattern here? You know, would dependency injection have been a better choice or, or whatever the, the, whatever you're talking about is. And so those are opportunities for learning. Is anybody familiar with the theory of forms from Plato? It's nobody really? Okay. It's the idea that reality is really made up of two realms. There's the concrete realm that we live in, like this, this podium, for example, is a concrete example of a podium, but out there is a perfect idea of a podium. So when I was thinking about coming up here and giving this talk, not having seen the podium, and I had an idea in my mind what the podium would look like. And Plato argued that the, the abstract version, my perfect version is actually a more real version, because it's what I would talk about with, with you. It's, you know, it's, if I, when I'm, when I'm describing a podium to you, I would describe my perfect version, not the concrete one. And of course, there's levels of, of how close you can get to the perfect podium or in Plato's example that I see a lot is the perfect chair, like the, the chair on the right is a less perfect example of a chair than the one on the left, but they're still not as perfect as the one in his mind. So that brings us to Plato's MVC, or I'll try and say this, really try to give Wren Skogs MVC, he's the Xerox programmer who first wrote down the, the pattern. And again, a lot of people, I've heard say that Rails isn't an MVC. And I think they're wrong about that. I think that they're, they're kind of missing the point here that there's this perfect concept of an MVC. And then there's, there's concrete real world examples of it. And, and normally they'll argue that because our models, when they change, don't automatically update our views. We don't fit the pattern, but there's a lot of other great principles of MVC that, that Rails does do. And the model view thing is a restraint of HTTP, a little less so with sockets, but still. So we love Ruby because of the logic that it allows new programmers who are coming and they can get past the how, the minutiae of how to build things and they can start thinking about the why. The programmer happiness is, is, we all appreciate that. And I think new programmers do too. It's, it's really amazing to see someone who's only been exposed to, you know, very small parts of something like innumerable, be tasked with a challenge and, and say, well, I think I know how to do that, that, you know, this array, I need to go through all of them. I wonder if each would work and they try it and, and it works. And it's kind of one of these aha moments. They're really, really excited about that. So the, it's the, that's the, the, that's why Ruby, new Ruby programmers, I think kind of get up that curve faster because they found, they base their programming knowledge in concepts and larger, larger pictures. So Alan, when he was writing small talk and writing about small talk, the big idea is messaging. Object oriented programming really isn't about objects as much as it's about the messages that we send between them. And Ruby, of course, is, is very much a good example of that. So, and the example I like to use is Adder Accessor. Did anybody wonder why I did the defined method up there on that first example? So the answer is it's clear when you write out defined method like this that we're sending a message to our class and, and classes are objects after all, and they accept messages. So when we get to more interesting things like Adder Accessor, here's my spec for it that's failing. I want to set my exuberance level to Barney Stinson, who's the Neil Patrick Harris character of course. When we get there, Adder Accessor is doing the exact same thing as defined method is all we're doing is sending a message to our class. This wasn't clear to me when I learned Ruby for a long, long time. So the how part is learning to write software. The learning to write software correctly, I think is the piece that, that new Ruby developers get because of the ability to talk about the, thinking critically about our code and, and writing tests and things like that. Learning Ruby is also learning to be a craft person, which is just as important if not more important that, that students take that away. They're, they're really prepolyglots. Students are, they, they come like all the students that learn, we don't know what languages they'll actually fall in love with and want to, want to go off and do. We hope, we hope it'll be Ruby, but lots of other things will, will shape that decision. Their first job is their internships. They're just their own discovery. So Ruby is really useful as a language because we can talk about these concepts rather than the minutiae of putting parentheses around things or, or, you know, the kind of the, the how of programming. I asked, I was curious about, because, because our school is new and we're still graduating our first class, how many graduates from code schools actually go on to work in Ruby? And I asked Epicodes, their placement coordinator. Epicodes is a, is a fantastic code school up in Portland. And she told me that they, they talked to about 400 companies or so on working on setting up internships and, and placing candidates after they graduate. And of that 45 of those 400 are Ruby shops. Another 20 or so are they do some Ruby, whatever that means. That's about 15%. And she told me that roughly 50% or so find jobs and internships in the, in the Ruby shops, but that leaves the other 50% to go out and, and apply what they've learned in Ruby to, to other languages and, and, and challenges. So we really have to, to focus on, on building up good critical thinkers more than, than good Ruby programmers. So it's applicable to, to everybody. So why we do things is better than how we do things. There's more important. The, you know, the, the pairing TDD and, and writing readable code are all good examples of that. So the, that's a quote from Princess Bride, right, Wesley on the Jet Pirate Robert ship. My first job that I got programming was, was terrible. I didn't know it at the time, because I didn't have anything to check it against. And I didn't know a lot of programmers yet. So I didn't have anyone to ask, but I would go in in the morning with a mountain of tasks left over from the day before and, and unrealistic expectations on how long it would take me to get them done. And I kind of, I was, I was the only programmer at this company building brochure, where for hotels. And, and so I just kind of stood off on the corner and write code. And, and because I was very, very junior, the more code I wrote, the harder it was to complete the next task. And so the whole thing snowballed and, and I would have weekly or, or bi-weekly meetings with my boss and the owner of the company about whether or not I should be fired. And it's, it's true. And so, you know, eventually that kind of was the, the thing that made me realize, okay, this probably isn't the best place to work. But one of the, so one of the personal goals of mine, and the reasons why I'm so excited about learning the other boot camps is that, that, well, not all shops, I probably not very many anymore at all, like the one that I was in, but, but there's some really good shops out there. But some shops aren't as great a place as the work. And, and if we send developers out into those shops with an understanding of why we, we put these practices in place, the TDD and the, you know, and, and writing extensible readable code, then they'll have some idea, they'll have something to compare their experience, their, their current experience with them. And while they're, they're new programmers, they're not going to have a lot of sway, you know, eventually, if they stick with it, if it's a decent place, they'll, you know, they'll start to be able to apply some of the, some of the, the techniques to write good software. So, so boot camps should make happen. This is a bit of a soapbox part of my talk. Bobby McFerrin says, don't worry, be happy. The, I, I wonder, and I haven't heard this, but I wonder, I suspect that people are nervous about all of these junior developers who are entering the Ruby job market. And, and, you know, what's that going to do to the market? Is it going to, are they going to commoditize the market? Is business going to kind of zone in on these programmers who will work for, for much less than you and I will? And, you know, are they going to be great programmers? And there's going to be too many of us and, and, and you're not going to have a job, or you're going to have to fight harder for a job. And it's kind of intuitive, but the answer is no. It's clearly no, I think. The biggest reason is that it's a big pie world out there. The more, the more we eat out of the, the software pie, the bigger it gets. The, the more good software we write, we, we raise, we really raise customers or consumers' expectations on the quality of software that they want to interact with. So, as, if we're developing thoughtful, you know, logical developers in Ruby, as opposed to something else where they may enter a commoditized market like PHP, will be, will be continue to raise that bar because they'll eventually grow and develop into senior developers and be writing, you know, more thoughtful, more usable software. And that will, that will drive demand for that software, which will, which will drive more demand for you. So it's just an example of what Apple's done. And in the App Store, keeping quality high and, and ever rising Shopify is another great example of that. New Relic, there's a ton more out there. At Notch 8, we do a ton of work in the medical industry, which it's really easy to raise that bar of, of usable products. And so it's a lot of fun to like, you know, it's unbelievable how excited businesses get when they see the products that we're delivering in the medical space because they've never seen anything like it. I mean, it actually, it works and is usable. There's a lot more segments out like out there like that. Shopify is an interesting case in kind of a different context and that they've commoditized online retail, right? You don't need to be a programmer. You can go to Shopify and set up a store in a couple hours and, and you're selling. So do we, do we lament that, that we're not all out there building e-commerce sites because Shopify has kind of got that market? Well, no, the answer is no. There's, once the consumers have this great product like Shopify, they would just want more. They want better back office tools. And I know Shopify is busy working on that. And they've been working on integration tools like you can set up a Shopify store now in Facebook, which is actually a competitor to one of my clients. And so I, we're very keenly aware of, of Shopify kind of raising the bar because they do a great job at it. As long as they keep satisfying the needs of their consumers, they will never stop it a lot. Always grow. That's a pendulum, of course. Think about Internet Explorer in the 90s and early 2000s. We, it was kind of forced on most of the public and, and they just accepted it. They didn't have really any choice that they knew of. And, and so they dealt with the bugs and they dealt with the challenges that we had as, as developers writing websites that worked in IE. So we have to, I mean, we have to, it's actually kind of critical for us as developers to encourage more and more people into, into building Ruby and other communities that really value quality software. So more developers, bar moves higher, more demand, you get a raise. It's a good thing. I mean, if you're still worried about it, it's going to take years still to become as good at building software as you are. So I think you're safe. So that's it. That's about it for my talk. I, I talked about why Ruby is a great language to teach developers in because it gets them to the critical thinking part and the concept part of programming faster. And it's the community around them that kind of keeps them interested in building quality and, and the, and the techniques that that takes. So thanks a lot for your time. My name is Matt. I'm Wine Scout on Twitter.