 Thanks, Adam. And thanks, of course, to Bukku for going and setting this up. Everybody hear me OK? And you guys who are still here, thanks. This is kind of a fun talk at the end here. We'll try to keep it light. So my name is Greg McWilliam. I work at Vox Media. We do the Verge, Polygon, Espionation, Vox.com, a couple others in there too. General Assembly, I teach at part time on the side. And then I might know some of you through Backbone Community. I run the open source project Backbone Epoxy. So here today to talk about learning. Originally, the talk was about teaching. And I was kind of noticing that as the content came together, teaching as an input and really the output is learning that we take away with it. So just first a shout out to Backbone. If you guys haven't seen it, this is what Adam was just referring to here a second ago. Backbone is live and well at Vox. And if you ever run across the explainer cards, these are now servicing about 25% of traffic that's going and running through Vox Media. And it's just a neat case study of how something so simple as Backbone can go and bring interactive storytelling to life. But on with learning. We're going to be talking about today learning as a whole. Learning as a skill. And then to go in preface for learning Backbone, let's talk about learning JavaScript. Learning Backbone and then learning for the future. So getting in, learning is really just a series of simple truths that we kind of already know. But sometimes it helps just to go and reinforce what they are and kind of reflect on them. And so the first one is learning is hard. And one of the things we face here, and unfortunately there was no XKCD graphic on this thing, so I had to go and draw my own and design major. The cycle of change. And this thing here is, if there's an antagonist in the story of learning, it is this idea that we've got peaks and valleys in our growth. And the peaks are when we feel like we're on fire. We're doing really well. We're comfortable with what we're doing. And then there's the valleys where we got to go and learn something new. And this is an ongoing cycle that we face both inside of our learning, inside of our careers, and our lives as a whole. So this one here is actually taken straight out one of our classrooms. So we always start them with rails, and they go through to backbone curriculum. So on day one, everybody's excited. We're on a big high. We're going to learn how to code. And then week one, oh, crap. This is actually really difficult. And we hit the first slump. And then when we pull ourselves back out, as we start to feel like we're on top of it, hey, I'm learning. I'm learning rails. This is pretty good. And then there's the inevitable abyss that comes next, which is everybody's least favorite JavaScript. We'll talk about that. And so this is something that we need to go and get better at and not be afraid of if we're going to go and push ourselves forward. Just think about it yourselves. Take a second to reflect on this. What is a peak that you are currently on that you feel really safe and secure on and that you're using in your career? Conversely, what is a valley that you've been kind of walking around and trying to avoid? Personally, backbone has been something I've been writing for a long time. Valleys, holy crap. I think we've just seen two days worth of valleys for me personally. I don't know about you guys. So pushing forward, if you guys haven't ever seen this talk before, I'd highly recommend it. This is 10 minutes of time well spent. Eduardo Barincio gives a talk on this idea of growth mindset. Growth mindset being something that we can go and instill our own direction of where we're going to go with our learning. So when we realize that we can change our own abilities, when we have a growth mindset, we can bring our game to new levels. And so to kind of distill his talk a little bit in one slide here, he talks about the idea of there's this idea of a fixed mindset and a growth mindset. And a fixed mindset goes and says we've got an ingrained level of ability. I am this smart. If somebody does better, it means they were smarter than me. If winning makes me a winner, then losing must make me a loser. Conversely, if we go and we have just an attitude that says our mindset is malleable, intelligence is malleable, we can grow our own potential. So I can't do this, but I can't do it yet. I can grow myself to go in this new direction. And this is really the foundation of pushing ourselves forward, trying new things. And we actually kind of created a little game of this around our classroom. And it's called the Yes, Let's game. Yes, Let's. OK, so it's 4 PM on Friday. Let's go have a smoke. Yes, Let's. Then let's come back and look at JavaScript weekly and look up one of the libraries that was in there and learn something new today. It's just a simple strategy for embracing challenges and setting ongoing short-term goals to kind of push ourselves forward. And then the other one that kind of closes on just learning here is the idea of mentorship. And one of the common things that we get in mentorship is there's a hiring panel looking at a junior developer. And they'll be asking, OK, what does this individual cost us? And yet it kind of is a short sell on that individual because really there's a lot that a junior developer is going to bring to the team that's not necessarily expense. There's growth there too. Seniors are inevitably going to be kind of distilling their own knowledge down as they go and help an individual. They kind of form new conclusions about what they already know. And in a lot of ways, we teach ourselves when we do this. So even if you're the experienced guy on the team, you can still grow from yourself by having someone to help and to push. And then the thing with juniors that I love about them is that these guys are fearless. When you haven't necessarily gotten comfortable on some peak along your own cycle of change, then you're fearless to go and try new things and go in new directions. And a lot of us who might be a little bit more stagnant because we're more comfortable in our position, all we need is some young whippersnapper to go and kind of push us in the new direction and try something else to go and keep the entire team moving forward, rolling along. All right, so let's talk about learning JavaScript. And so the question that we see is for such a small language, there's a disproportionate level of anger and misery associated with it. Why is it so hard? Really, it's this tiny little thing. But what's interesting, incidentally, thank you, Agnes Kroll. I borrowed this from one of his presentations about five years ago. I think this is one of the best graphics I've ever seen that goes and just breaks down JavaScript and what's going on with it. So really, we go in and think about it. There's two languages there. We've got the familiar one that's easy and accessible and has made JavaScript incredibly popular, certainly amongst the front-end community. And it's almost a subset of the front-end community that's currently using this reduced level of JavaScript that is the familiar part that sticks up above the surface there. And yet, really, the language as a whole is a very expressive and powerful machine that is kind of taken out of context this little bit that we see at the top doesn't necessarily go and give us what we need to work with it. So in answering the original question, why is JavaScript so hard, my best answer is, ironically, when we only embrace the little bit, the familiar parts of JavaScript, it makes many of the really basic operations seem illogical and thus makes the language as a whole more confusing. And I guess we see this a lot with junior developers who have only gone learn the small subset and they're kind of comfortable with jQuery and then the first time we run into a confusing contextual situation of what does this refer to here? We don't know. And then the thing that we did actually know and were correct about might not make sense or we go and we train ourselves that that wasn't right because the thing that we didn't understand hung us up. So I guess my take on this is that really what we need to do is kind of redefine core JavaScript. Core JavaScript being what is the minimum in terms of our industry that we go and use and set is a baseline for teaching and excuse me. So the traditional here would be, lost my place. OK, thank you. So I would propose going to, we want to go and push to this aspirational core JavaScript. In terms of core JavaScript, basic understanding of JavaScript does not just limit itself to data types and data structures, conditionals, enumeration, simple functions. Really, what we want to go and treat as core JavaScript should still include first class functions. That's functions as objects, closures and scope, knowing what goes where, the meaning of this, contextual invocation, and then method sharing, prototypal inheritance. And this is the kind of thing that we look at something like Backbone. And Backbone is actually fundamentally fairly simple and obvious in terms of how the tool itself works under the hood in terms of the JavaScript that it's doing. And yet, if we don't necessarily understand prototypal inheritance, then what the extend method does is a whole lot more mysterious. So just understanding the language goes and makes us understand the tools that much better. Then the other one I put out there is just require another language. Node has created something of an institution for us in that all of a sudden JavaScript is a full stack language. It goes and it works everywhere on both sides. And this is really exciting, but also it kind of goes and loses a whole lot of ancestral knowledge if we go and choose to only pursue one language. There's a lot of documented benefits of just learning foreign languages. Foreign languages make us smarter, builds multitasking skills, increases perception, improves memory. Do these sound like characteristics of a good programmer? So even if we have the choice coming out to only pursue JavaScript, I would encourage everyone, especially new developers coming out, to go and look at other languages just for inspiration and just a source of knowledge to go and expand what you're doing with your main language, even if that is JavaScript. Also as a benefit of all this, this foreign languages forestall degenerative brain diseases. So if you learn Ruby, you actually stave off Alzheimer's. Pretty cool. So learning backbone. There's a question that always comes up when we learn backbone, or that I start to teach someone new backbone. The question is inevitably, so what do I do with it? Anybody ever gotten this question before? From a coworker, a colleague, they go and they look over the thing. A lot of times the easy out is to go and blame this on the documentation. I would argue the documentation is fine. However, the documentation of backbone is highly functional. We go there for answers as to how individual pieces work. And so the things that we're really missing inside of the backbone docs are the simple lessons of backbone. What is, you know, we've been looking at backbone through a magnifying glass for two days now, literally in the last one. Yeah, right? So now let's go fly out and kind of look at it through a spaceship from the thousand foot view is to, okay, what is the absolute bare minimum of backbone? And so even going above backbone's head, let's talk about backend and front end. Backbone is a front end language. So where do we start? To be honest, the backend seems like an excellent place to start. I don't know if anybody else has noticed, but front end is actually pretty complicated. We've got tons of JavaScript, we've got tons of CSS, that goes into an HTML document. The HTML turns itself into this thing called the DOM and then we have all of our JavaScript build out an application and then that attaches to the DOM, it does Ajax to get data and then it's connected by this, oh man, a deep link. So there's a lot that goes into it. Conversely, what we're trying to do on the backend is something that's a lot more streamlined. Not to say that there are simple problems on the backend, but there's a lot more consistency in terms of the problems that we face. You're a lot more likely to go and do a Google search on a problem you're having on the backend and come up with the thing that 500 people have also had the same question and have come back with the right answer as opposed to your graphics on the front end are really compromising you from ever getting the specific answer that you're looking for. So before we start diving into a front end language it really helps to go and learn backend. Also in 2015, front end applications are really kind of an extension of the backend. They don't really exist that much on their own anymore. So if we don't necessarily know how to go and configure backend data services or know how they work internally to go and build a front end application that goes and leverages them, we've already kind of short circuited our full knowledge and understanding of how this system's gonna work. Okay, if there is a visual quick start guide for Backbone I would say this is it. Backbone builds itself is an MV Star framework model view separation, model view separation. So this is something that we don't necessarily get from functional documentation but really it's very fundamental. We've got two components. We keep them as far apart as possible. They've got very simple defined roles. Model manages application data, notifies when it changes. A view captures user input, renders model state. And then this seems so fundamental but that comes with a lot of practice. And I'm sure at some point we've all kind of built some kind of like a mod view situation where all of a sudden the view is for some reason doing some kind of data service request for one specific one off action. Model view separation is a pattern that's been around for a long time. The other thing that I feel is really commonly overlooked is that model view is a free form. So we go and we have this idea of why only have one model bound to one view. It's traditionally taught that way. We have a model, we have a view, they go one to one together. But when we have multiple views that all wanna update based on the same data, well, how do we do that? It seems really obvious that they would all go and talk to the same data source. And yet there's perhaps this academic knowledge that lingers that says one to one is the way that model view works. It can be one to many. You go and you play with one view in one corner and all of a sudden all the other details all over the screen start to update. Another one that I find really remarkable is commonly overlooked and that's the relationship of the model and the collection. And it seems so fundamental that these are an expression of rest services. And yet again, when we go and we bury this in functional documentation in two different sections of the backbone docs, there's a lot of people, I mean data scientists in the DC data community had no idea of how we would actually get data into a model when it comes inside of a list. So just calling out a very simple expression mapping of these components. Let's start. Lastly, API to modeling. API is a service that we don't necessarily have full control over. Where our data comes from should not necessarily determine what our data looks like in our front end application. Our front end application has its own requirements, its own goals, and we're gonna go and define a structure that makes sense for it. If we're loading from a third party, we can't necessarily guarantee that what we're getting aligns with what we want on our side. And the solution here would not be to go and create some kind of amorphous blob of backbone modeling that goes and accommodates this dissimilar data structure that came from Spotify or someone else. And so one of my favorite methods inside of backbone that I always go and try to call out right up front would be the parse method. It's our best friend. It's great at reconciling these differences. Takes care of it for us. And then lastly, routers. There are no simple lessons. Thank you, James. Seriously, we've gone and we've tried to go and teach routers numerous times. We've gotten there eventually, but these things were a model and collection and view relationship. We've been successfully teaching those in one to two days. Routers, we've gone for two weeks and students are still just clueless. You just have to build the things over and over and over again. So I'm really excited to hear that there's progress being made in terms of other projects that are kind of working to go and streamline this process. Then finally, learning to the future. So first of all, quick retrospective here. This actually is not about obesity in America, but about maps. So this is my story. I'm sure we've all had something similar or will soon. But the first map I ever made, interactive map, was back in the mid-90s in my parents' basement doing HTML image maps where you went and you set up a little polygonal region and then assigned an href anchor to it. It was pretty cool. And then that made way to the much more advanced sprite engine inside of Macromedia Director, which is really cool. And that turned into Flash, which was quite a ways ahead of its time. And then nowadays, we're just going, we're queuing up D3, give it some Topo JSON, start writing some rules. The entire process has changed dramatically and yet really when it comes down to it, we're doing the exact same thing. Nothing's really changed in terms of what we're trying to accomplish. So there's a book about this. Some of you might have heard a bit, Design Patterns. This quote was actually pulled from the 15-year anniversary interview with the Gang of Four, kind of going and reflecting on where software had gone since and just what their opinions were. So they were pleased to go and just look at, there's a whole lot of the foundation, the inspiration that went into that book that they can still point to and say, yeah, that's in use today. We're still doing the same things. So backbone in 2025, this is my best explanation of what it's gonna look like. It's a simple explanation of a pattern. And whether backbone is still around or whether it's changed or whether it's been completely rewritten, it's probably gonna be doing about the same thing. And if we can go and focus our knowledge on the pattern, software designs are timeless in a way that code is not. So just as a final anecdote here, anybody know what that is up there? Can we even see in animation? Yeah, it's pretty, okay, you can't really see it. Conway's Game of Life is running back there. So just as a final anecdote that we did in the classrooms, start over. We had this exercise in class where we went and we had the students go and write Conway's Game of Life. It's a tile-based game, three tiles around, a dead cell will bring the dead cell to life, dead cells surrounding a living cell will kill the living cell. And so the exercise, and maybe some of you have run this in your own companies, would be to pair up, go and work on it for an hour, at the end of the hour, see how far you get, throw away all of your code, start over. Get a new partner, start the entire process over again. End of an hour, throw all your code away, start over again. The students continually from our class and subsequent classes that we've been talking to, cite this lesson as one of the most valuable experiences that they had inside of the classroom, simply because it was the one that went and taught them about letting go, breaking the cycle, and starting over, just moving on. So that's not to say that we should just go and throw away what we're doing and move on with no cause, but when the time comes for change, yes, that's, so thank you.