Ashley G. Williams
Kent C. Dodds
.eslintignoreand then tackle files one by one. This cuts down on the number of collisions with other PRs. Look for additional plugins, like the React ESLint plugin, and you can create your own
KENT: And we're live with Angular Air. Hello world! Today we're... "Angular Air" oh, my gosh!
So, I'm going to go ahead and introduce everybody really quick. We have Brian Lonsdorf.
BRIAN: What's up?
KENT: And Lin Clark.
LIN: Hey there!
KENT: Matt Zabriskie.
KENT: And I'm Kent C. Dodds. And for our guests, we have Ashley G. Williams...
KENT: And Kyle Simpson.
KYLE: Hello, everyone!
KENT: And Kyle is actually a panelist too, but he's a special guest this time 'cause he knows some awesome stuff about training beginners. He's always thinking about that and I think that's great. So, let's go ahead and get started. Ashley, maybe you could give us a quick intro to yourself, and then Kyle.
ASHLEY: Sure, so I'm Ashley. I work at npm. My official role is Developer Community and Content Manager, but I pretty much just like to say that if you don't how npm works, that's my problem. Right out of college, I was a middle-school science teacher in Harlem, for three years and started most of my tech career by working and then leading a boot camp in New York City called the New York City Web Development Fellowship, which basically allows students who make less than 40k or are unemployed to be trained for six months to become web developers. So that's my background, at least in the education world. (laughs)
KENT: Cool. Yeah, that's awesome. I didn't realize you were a school teacher. That's great! Kyle, tell us about yourself a little bit.
KYLE: I sure wish somebody would write some books about those specific topics (laughter) and help people figure out...
ASHLEY: Corey Frang has an amazing presentation that they did at JQuery, the JQuery Foundation Conference last year. I'll put it in the repo. It's good... or the document. (laughs)
I saw a talk years ago (and I now understand that it's actually a book and I'll put a link to this), it's called "Build Your Own AngularJS." Well now that Angular 2 is out, I guess it's okay for us to talk about Angular 1 and rebuilding it from scratch. But "Build Your Own Angular," was fascinating because what I assumed when I first was gonna watch that talk at a conference, was that the message was gonna be "You don't need frameworks. You can do it yourself." But actually, the message was much more productive and I believe this is true of the book as well. The message was: "If you're gonna use Angular, wouldn't it be a really good idea to understand how Angular works under the covers? So let me just show you that it's not actually magic, it's not actually a black box. Let's build it from scratch."
Any listener that's listening to me right now, I would encourage you to check those sorts of things out. Open up the source code for the things that you use and be a little more curious about them. So, I'm not saying don't use the framework, but I do want you to understand how it works and never treat something as purely a black box that you couldn't possibly understand.
ASHLEY: Yeah, I could not agree more. And I know that you've seen this, but I've been giving a talk this year called, "If you wish to learn es6 from scratch, you must first invent the universe," which is a play on a Carl Sagan quote (which is basically saying exactly what you just said), which is kind of, if you want to understand something you need to start from scratch and build it up.
So there's an awesome CS pedagogy, a professor named Peter Van Roy. He wrote a book called the "CTM," And basically, it's kind of this idea of creative abstraction. He has this kernel teaching approach where you literally start from nothing and you build every abstraction that a programming language would need from scratch, and only building that abstraction when you feel the pain of its absence. I think too many times, we believe that the sugar that we have in languages, the magic, is what makes something easier to use but beginners actually like find it, I've seen beginners get tripped up by it multiple times. And they feel much more in control when they know what's going on with something.
Like, I give the example of a "for" loop and "each" loop in Ruby, and "each" abstracts away the three things that define iteration: state, condition and increment; whereas in a "for" loop, they're immediately exposed by the syntax. And it turns out that, for learning iterations, students do much better learning "for" loops than they do with using the abstraction in "each." So yeah, I couldn't agree with your more, Kyle. If you're using a framework, it's imperative that at some point, you look under the covers and figure out how it works, because you really can't wield it appropriately until you understand the implementation.
KYLE: Yeah, everything's great in the happy path, but as soon as you get off the rail, so to speak, (laughs) as soon as things start to fall apart, you're like... that one last thing on that exact topic, there's another project which is very similar to what you just mentioned, Ashley, it's called, "From NAND to Tetris," (NAND as in the NAND gates inside of your CPU )"From NAND to Tetris - Building Computers from First Principles," highly recommend that people check out that book and that set of learning resources as well.
LIN: I think that it is super-important to get under the covers. I think that you can do that not just by building it yourself, but also by explaining it to other people. So for me, Code Cartoons has been exactly that. You know, going through Flux, going through Redux, going through Relay. Basically, I've been tracing through, you know, all of the code and then figuring out how would I explain this to somebody else and that's how I actually started understanding it myself. So I think that for people who are more, you know, who don't feel yet confident enough to build their own Angular 1 as a way to understand Angular 1, really getting nitty gritty deep into the interactions in the code base itself, not just the API, but the interactions between the components that you aren't seeing, that can really help you.
KYLE: I think that's a general principle for all of learning, that what really solidifies learning the best is when you re-explain, when you re-teach to others. Hundred percent agree with that. From the ground up, you need to be looking for ways -- whether that's writing blog posts or giving lightening talks, or giving brown-bag lunches at work or making an open-source project, or any of a dozen other ways -- if you turn around and say, "Hey, I think I just learned this thing, but can I show you what I just learned?" you will learn it better and they will learn it better. Teaching is really the only way to learn.
ASHLEY: Teaching is nature's way of letting you know how sloppy your understanding is. (laughs) That's how I like to say it.
KYLE: (Laughs) That's good.
KYLE: Does that still exist? That sounds like an awesome project.
ASHLEY: It's actually on my GitHub. I put it there. I'm embarrassed. It's called, "Rise and Shine." All my stuff's public. I'm gonna sound like, again, it's a little loopy. I was definitely writing it at like 4:00 AM, but it's there. (laughs)
KENT: You know, all of this stuff that we're talking about makes me think of Dan Abramov's lessons on Egghead.io about Redux. If you haven't seen those, I recommend you check them out. But one of the things that he does in there that I think is just so valuable, and like it has, this principle has nothing to do with Redux; the principle is, he teaches you about... like some concept in why you need an abstraction. And then he shows you how to use that abstraction and then he shows you how that abstraction works. And he re-writes it, just right there, in front of you. It's really, really impressive. And maybe you couldn't do that in an Egghead lesson about Angular, maybe for different parts but, I think that was just a really impressive way to teach. And I feel like I could write Redux right now and like that's pretty cool. If only I'd thought of it a year ago, then it would be me... no, I'm just kidding (laughs). But yeah, he teaches in a really effective way and I think that's an effective way to learn as well.
BRIAN: I find like as a counterexample though, that when I try to show like, "here's an implementation of a monad," for instance, people are like, "Whoa, whoa, I just want to know how to use it and now you're showing me like all these things and I'm a little confused." It's like, sometimes it's better to hit something from like 10 different examples to gain an intuition, than to pick it apart and show the pieces and the implementation. But, I don't know, it's like, where do you draw that line?
KYLE: That's just cause you busted out that word "monad"(laughs). Anybody that hears the word "monad" is automatically going to get a little bit scared (laughs).
And so, what I find is you have to... all learning is goal-driven, right? You have a goal. And so, often, people who are learning, they want to do something. And so as long as you can keep what you're doing very clearly on track to the thing that they want to do, you can get as deep and hairy as you want in the weeds as long as that connection still is maintained. And so there's always like a circling back to, and this is how this gets you what you need.
So I think, like monads are awesome and there's lots of ways to motivate people wanting to use monads. I think probably one of the big reasons people are freaked out by them is they have no idea why they're useful. So if you keep that in mind, people could get excited about all sorts of things, like no matter how deep and dense or close to the metal it might be, I think.
KYLE: There's a thing in teaching, and I don't know how many have heard of this term, but "cognitive overload theory", this notion that when you're teaching something, when you're learning something, there really is, everybody has sort of a level at which beyond that, not only are you not catching anything but it's really almost subtractive; you're losing out on the understanding that you thought you had. So as a teacher, you always have to be careful and mindful of that idea that, "What I'm teaching can't fill up the cup so much that it's overflowing and they're losing, they've tuned me out, they're not hearing anything that I have to say."
So on this notion of like building from the ground up, I'm not sure that that is necessarily the most healthy thing. I think we should want to inspire people to be curious enough that they could. But I think more practically, you might go in the opposite direction; instead of building from the computer's first principles, up to an Angular application, maybe start with an Angular application and go one layer down further in the abstraction stack and understand that one. And if you get to the point where you are pretty comfortable, a mastery at that level, get a competency level of the one below that, and the one below that. So maybe going in the opposite direction where I'm not really showing you the entire way that the sausage is made, but just that last step before the abstraction, I think that sort of curiosity is what will foster deeper learning.
ASHLEY: Yeah, just to jump back quickly to what Kyle was saying, I do think that you can go in both directions (and obviously depending on the type of person you are, one way might work better for you or not.) But one thing I have seen, particularly with web applications, and the reason that I kind of like to start from first principles as opposed to an application, is that an application is oftentimes, especially for beginners, not something that they understand. So if you start with the application, you're already starting in a place that is super-confusing and disorienting.
Whereas, if you start from first principles, then first principles doesn't need to mean, like, how the computer works or something, but something more like, "I have this type of information and I need to show it in a template, first principles." Because once you start from those things, it's significantly easier to understand that as a human being, I can reason about how an app works and now I just need to figure out how to implement it. Whereas, if you start from the application itself, I find that beginners are often trapped in the way it was implemented -- can't think outside of it, and also can't think inside of it. And so it's often not a terribly great place to start. Of course, once you have people who understand how a framework works, then moving down and explaining it, abstractions, that way, I think can be really great. But for beginners, they just get stuck and all they see is syntax and have a lot of trouble reasoning about it.
KYLE: Also, there's a lot of really terribly written applications out there, so if you use that as your basis for learning, you have to take that with a grain of salt.
ASHLEY: Honestly, debugging bad code is a great way to teach, I've actually found. It's really nice to... because beginners are often afraid of making mistakes, so being able to show examples of mistakes and then how to fix them, I think is often a more successful exercise than the blank page, having to write something from scratch. The debugging actually ends up revealing a lot more about how something works than writing it, often.
KYLE: Speaking of debugging, I hope everybody listening is well-familiar with the developer tools in your browser. You'd be surprised at how many times I run across developers that have been at it for a long time, and have barely any understanding beyond a console, that there is such a thing as developer tools. So if you haven't learned those, this holiday season would be a great time to up your skills in developer tools, whether that be Chrome or Firefox or whatever browser. There's tons of fantastic stuff about that.
LIN: I'm actually hoping to do some Code Cartoons, now that I've joined Firefox's Developer Tools Team, about developer tools, after I finish my React book, so, hopefully, that will help.
ASHLEY: It's really funny, being a back-end person, hearing y'all talk about dev tools. I mean, I do some front-end development, but debugging tools in the Node ecosystem are not actually really, they really like kind of like don't exist. They're not very good. So, it's funny to talk about dev tools in that sense. It's like, "Oh, learn how to use console log." (laughs) But yeah, I don't know. That can be interesting.
BRIAN: Instead of survival mode. You have to survive as long as you can.
KYLE: Yeah, it's like a more helpful version of Stack Overflow, 'cause Stack Overflow has all that information but it's really hard to find it, without, you know...
ASHLEY: Without all the snarks and the jerks, yeah. (laughs)
KENT: Yeah, exactly.
And one of the reasons for that is that I think there is some misconceptions among developers about what it actually means to have readable code. I think a lot of people think that's purely suggestive, purely opinionated, to call something readable. But it turns out, it has actually been more formally studied, this notion of code readability. What would it actually mean for a piece of code to be perhaps "scorable" in an automated way. There are metrics for code readability. There's a paper written about this. I'll see if I can dig up the link for the show notes, but there's a paper written about code readability. And one of studies, one of the outcomes from the studies that they did was that one of the biggest things that lead to people calling something readable is actually familiarity.
ASHLEY: Yes! (laughs)
KYLE: Now I know the destructuring feature, itself is actually, fantastically complex. There's a lot of nuances to it, and I still am learning parts, you know different nuances of it, but I think destructuring actually does something really useful with our code, which is that it turns our code from being more imperative into being more declarative. And it has been proven -- not just a theory of mine -- it's been proven that declarative structures are easier to learn. Instead of telling you how to do a thing, I just want to tell you what I want and I want you to give me that thing back. And that's what destructuring is actually doing for the language is allowing us to declare what we want to have happen out of these destructured assignments, and let the language take care of some of the nitty gritty, imperative work to make that happen. I think that's really important. Not that we can't or shouldn't tell them, "Here's how we did it before," but I think over time, it will become the preferred way of explaining how to deal with that idiom. So, I think ES6 actually did a fantastic job with stuff like that, and then they got a little bit drunk on special operators for things like arrow functions and other things like that, and didn't actually really move the ball forward in terms of learnability, in my opinion.
ASHLEY: This is very important! (laughs).
KENT: There's a separation between what we write and, and it's difficult for me, because I'm a craftsman. I'm like, I chose to do "++i" instead of "i++" and the language is like, "Well, this other way is way better." You know I'm glad that the engine is better at writing efficient code than I am, but it is difficult to separate and think that the code that I'm writing is precise to the set of instructions. Anyway, if we back up from those two assertions, it really does ask: what is the purpose of code? If there's an infinite number of ways to do it and whatever way I pick is just a suggestion to the computer anyway, then maybe the purpose of code is something different. And I contend, as many others do, that the purpose of coding, primarily, first and foremost, and as a far distant second the computer first and foremost, human beings. It's a form of communication with other the people.
And, yes, code comments can help and, yes, variable names and functions can help, but it's deeper stuff like, what idioms we choose. Is this appropriately done with a for loop versus a recursion, or is this a destructuring thing that needs to be declared that way? What we choose to do affects how people will understand our program, how they will learn our program. And it's not just other people on our team, but our future selves. When I go back to code that I wrote a week ago, I'm like, "what in the hell were you thinking?" No, no, literally, what were you thinking, 'cause I actually don't know, 'cause I can't tell from this (mumbling.)
ASHLEY: (laughs) I mean it's really important in substance though, right? It's like programs must be written for people to read and only incidentally for machines to execute.
KENT: Yes, it's not a unique idea to me. I'm just...
ASHLEY: Oh yeah, no, no, no. I mean I think it's super-important. And when I started really getting into programming language design as kind of like a hobby, I started out by being pretty hung up on this question of, "what does it mean for a language and then also a program to be expressive? What does expressive mean?" And I would like ask people this, at like meetups, all the time. I'd just go up to them and be like, "So what do you think it means for something to be expressive? What makes a language expressive?" And generally speaking, the thing I heard was "being able to do something in the least amount of characters." Like, the least amount of syntax. I know! I know it's terrible! I was like, I am trying to get at something really beautiful and important here and you're just talking about you have a language that has sugars so that you can write something really, really short.
So I think trying to move the community towards an idea, like, when we say "expressive," we're not meaning, how quickly you can get something done, but how you can really show intent and thought in what you are writing is what's important and is what makes languages, I think, either better or worse or special is how well they can help express what you're trying to do.
KYLE: Since you're at npm, I have to tease you on this: obviously, semicolons hurt the readability and understandability of code. We need to remove all semicolons, right?
ASHLEY: Um... that was not a decision that I made. I have no comment. (laughs)
KYLE: Sorry. I couldn't resist.
ASHLEY: (laughs) It's fine, it's fine. I mean style is important. Like the one thing I will say, as far as style goes, and expressibility or in the expressivity of a language is, you want it all to be the same, because the key thing that we want to do (and this is why frameworks and stuff are very great), is we want to take away all the boring problems, so that we can focus on the interesting ones. And so being able to Bootstrap things, being able to eliminate style, I mean this is why declarative languages are great, we don't need to tell the computer how to solve things; we just wanna focus on our interesting problems and the things that pretty much we spend all of our time as developers doing, which is like repeating this like kind of boilerplate stuff that everyone has already solved, done, again.
KYLE: Yeah, that's a very interesting notion of what is the difference between the boring, mundane work and the interesting work? And I would almost, you know, it's that "one man's trash is another man's treasure." One man's or woman's boring code might be somebody else's really interesting code. But I do think it is important for an individual developer to say, "this is the part of the program that I'm gonna be most effective at applying my brain power to and figure out what tools can help me not worry about that."
KENT: Cool. Okay, so this has been such an amazing episode. I wish that we had more time. Unfortunately, we don't so I'm going to wrap things up here. Thank you so much for coming on. Let's go ahead and take a look at the hashtag @jsAirQuestion question really quick. We do have a couple of questions on here. So Marcus Nielsen says, this is @Getify, "Object composition, prototypes, pure functional, reactive programming. What paradigms should we use in normal projects?" I don't know what "normal" is, but there you go.
KYLE: Ah, yeah, that's super, super hard to answer in a generic way. So, for example, you could think about procedural programming, functional programming and class-oriented programming as three major programs. Certainly not the only ones, but it's those three major paradigms. And I have to be honest with you that the vast majority of projects that I've ever written, that the most effective parts are the parts that mixed the best parts of those together. So I don't feel like I've ever written and entirely object-oriented or an entirely class-oriented or even an entirely functional programming-oriented project.
I have (again, shout out to Frontend Masters), I have a class called "Functional Light Programming," and basically that's taking some of the real basics simple principles from functional programming, separating themselves from some of the perhaps overwhelming terminology and just talking about the fact that we can deal with values as if they don't change and we can make functions that don't have side-effects on other state. And those are things that actually improve my code, even if I'm running a class-oriented program or if I'm writing, you know, a procedural-based code, program. Those are things that help regardless. So I would say find the principles, those first principles in each one of those paradigms and figure out how those work together. You're not gonna hear me, likely, say, "do all functional or all class" or anything like that.
ASHLEY: I just want to jump in here really quickly and say that the desire to do something in a purely one-way or the other thing and to have a simple, like, a one answer for all things is I would say, try rid yourself of that desire because that desire is not how the world works. And the reason you would want that is because you would want something, like, just this black and white answer. And I think it's important for us to know that these problems are complicated and things need to be hybridized and we need to see things as tools.
KYLE: Cool, yeah, I think those are good insights from both of you, thank you. So Alyssa Nicoll asks, "Difficulties like scope are not unique to JS though, right?" I think this is pointed to you Ashley.
ASHLEY: Yeah, completely agree.
KENT: So the next question that we have here is from... oh, no sorry, these are just a bunch of troll questions from Jeff Whelpley, so we're gonna move on. (laughs) So I think that's good for our questions. We are a little bit overtime. I do still want to get to the tips and picks though, because we have some really good ones. So let's go ahead and Ashley, we'll let you go last. We'll start with Lin Clark. What do you have?
LIN: I'm glad that you start with me because everything that people were touching on before the questions was exactly my tips and picks section. So, my tip was about ESLint because some places, I was at a place before Firefox. I was told when I was on the Firefox DevTools Team where there was actually a big fight about whether or not to have code style, whether or not to have ESLint at all, not even the rules. And I think that it's important to realize that for beginners, that stuff is really important because when you're a beginner, every difference that you see, you think that difference is meaningful. You don't see it as three different ways of doing the same thing; you see it as doing three different things. And so it does add to that cognitive load that Kyle was talking about. So, my tip for this week is, definitely, if you are working on a project with any other people, definitely use ESLint or JSLint or JSHint -- one of those. So use it.
Second, if you are converting a big code base like we're doing right now at Firefox DevTools, and Firefox generally, is converting to using ESLint right now and it can be tricky to introduce code style to a project when it's already so big. I've done this before in another open source project and the way we managed it there was by doing it file by file, so that you don't have... you know, if you do one rule across the whole code base as a patch, then it will conflict with a whole bunch of other patches that are currently being worked on by other people. If you do it file by file, you might inconvenience a couple of people who have patches that touch that file, but it'll be a lot easier for them even, when they are doing a rebase to figure out, you know, they just have one file that they need to go through and remember what they were doing in that file.
And my third ESLint tip is look for plugins, you know, if you're using React. There's a React ESLint plugin that helps out with specific rules for that framework. And you can even build your own. We have one for Mozilla. So those are my tips about ESLint.
KENT: Solid tips, awesome! Matt, why don't we have you go first, or go next.
MATT: Okay. Me and Lin were actually on the same wave length as far as tips. I will recommend ESLint as well. I actually just added this to an open-source project that I'm working on yesterday, because I was getting all these PRs, like everybody was using different styles and stuff. And kind of going back to what we talked about earlier, to have better readability of code when it's consistent, that's way more readable for either other people coming in on the project. But even for myself, when I look at stuff, it's like, "what is this doing here?" So I'm kinda echoing what Lin said, but I a hundred percent plus one that.
As far as picks, I have something not tech-related. I'm a big Foo Fighters fan. They just released an EP on iTunes for free yesterday, called Saint Cecilia. Dave Grohl's a legend. Go check it out!
KENT: Awesome (laughs) cool! Let's see, Brian, why don't you go next?
BRIAN: Sure. Let's see. My tips (laughs) were that, I found that most people I know that have been programming for a very long time, started with procedural until they got a good handle on it, and then they felt the pain and then started with object-oriented after that. After they became a good intermediate programmer with that, they started to really, you know, learn the design patterns, Gang of Four kind of stuff and classes and everything. And then once they saw that, then they started learning functional programming, you know, from more of a slim and different style, you know, of handling these problems.
So then, I think this natural progression of starting procedural and then learning object-oriented is the smart way to go, because you're gonna learn what the industry is using for the most part and then everybody's starting to kind of move to functional because it's interesting and new, I guess sometimes. But I find people are reading my "Mostly Adequate Guide," and I'm like, "Don't do this (laughs) unless you already know object-oriented programming," 'cause, you know, you're not gonna, you know, walk into the next job using this stuff.
And then, I just wanna say there was some cool picks, I don't know if they're links or picks, but I have some links too. Jared Tobin's "Recursive Types." He talks about fixed-point, you know, "Fix", "Free", and "Cofree". And then Hardy Jones' Computational Effects. I've linked to that. It's a really great GitHub repo to get an understanding of the composability of this stuff.
KENT: Cool! Thanks. Good tips and picks. So, I'll go ahead and go next and then we'll go with Kyle and Ashley. So I have one tip: contribute to open source. You just learn a ton when you contribute to other people's code. And so I've been asked many times, you know, "What project should I contribute to? You're telling me to contribute. What should I contribute to?" So I have a blog post that answers that question and I'll add a link to that, "What open source project should I contribute to," in the show notes.
And then my picks, I had pick Slides.com. I totally love slides. It's just like I don't want to have to worry about setting up my slides or anything, just like give me a place to put stuff. And it looks really slick, so Slides.com. And then, TodoMVC. I use TodoMVC. I know there's been a little bit of hate on TodoMVC, just because it's a really small application. It really doesn't show you all the awesome benefits of these different frameworks and how they compare, necessarily, but it's a fantastic place to start, I think. And I use it for some of my workshops. And so I think TodoMVC is very cool. Kyle, what do you have for us?
KYLE: My first tip would be if you are looking for a way to motivate yourself to learn, try to look in your immediate vicinity, like, for example, where you are at work and look for those opportunities. I you wanna learn something, like a new plugin or framework, then go to your boss and say, "Hey, can I do a brown bag lunch next month about this thing and I'll spend the next month learning it, then I want to turn around and teach other people." So if you're looking for ways to motivate yourself, set yourself up external deadlines, goals, if you will, whether that's giving a talk, or whatever, or a date that you have to have blog post published even. Set yourself up those external deadlines and that will help motivate you towards deeper learning.
The other tip that I would give is, I personally have had, as we're drawing towards the end of the year and I've had a crazy year of travel and busyness as usual, I've been experiencing a little bit of burn out recently. And a couple of weeks ago, I was like, you know, I'm just not gonna Tweet anymore for a while and I'm just gonna start workin' on building a game because I'm kind of tired of this grind of stuff. And I just wanna give that as a tip; it's okay to literally unplug and do something stupid and silly and kind of recover some of your mental direction and that sort of thing. So, that would be my other tip.
A couple of quick picks to mention: David Nolan, who is kind of my hero; I listen to and read almost everything that he does. He's @swannodette on Twitter. He is really, really smart and fantastic. He works for Cognitect and he just did a podcast episode for them in their most recent Episode 93. And I only got about half-way through this podcast before I realized I gotta go back and re-listen to this thing about five times. He was talking about how his framework and Clojure and ClojureScript called "Om" really changes the way people think about state and management of state, both front-end and back-end. I was blown away by it. I thought that was really fantastic.
KENT: Awesome. Congratulations! Now we need ES 2016 and beyond, so get on it! (laughter) Cool! So Ashley what do you have for us?
ASHLEY: Alright, so to start off, one of the things that I wanna say kind of as a tip that's been great for me is, last year, my resolution was to have more sustainable behaviors. I often do things like in huge bursts but I wanted to be able to do things like more sustainably. And one of the things that I started doing was this thing called Breakfast Repo. It's now my most popular GitHub repo, which is hilarious. But basically, it's a series of videos that people file as issues. And I watch one every morning with my coffee. And it's been amazing. And I've been able just to learn so much, just by doing like 20 minutes every day of watching a video. And it's not necessarily all about programming. There's a lot of programming stuff in there, but that's been really good.
For my two tips, what I've written here is to investigate the programming languages that you use as tools. Don't just take them for granted. Investigate them as tools. Figure out what makes them what they are. I know a common interview question is, "what's your favorite thing about the language you use? What's your least favorite thing?" Figure out what those are. Figure out what the trade-offs with the language that you use are. I think it tends to be very illuminating.
And then secondly, I said learn about different programming paradigms and then spend some time translating your side projects into them. One of my favorite exercises that I find is probably the way I learn the fastest, is to take something that I've already done and either translate it into another language, translate it into a different paradigm. Going from something that I understand and them moving it to a new thing tends to be really successful.
Then there's this blog post called "Hello Declarative World." It's a blog post based on a talk that somebody gave. And basically it's written in Ruby, but it's talking about different programming paradigms, what the declarative paradigm is all about and then it actually implements what's called a relational declarative language in Ruby. And I will throw up the link. I went through and translated it into ES6. It was really cool. In particular, it use generators, so if you thought generators were cool and need a project to like actually use them, this like was a very fun example of that.
And then last two are two talks which I would recommend that you watch together. And I'm only going to just say their names and tell you nothing about them, because I feel like I would ruin the kind of surprise in both. One is "Simple Made Easy" by Rich Hickey and the other is "Growing a Language," by Guy Steele. They're both fantastic. The Guy Steele one is old, but it's amazing! Again, both focuses on language design.
KENT: Awesome, if you're listening and not watching then just know that a ton of people just nodded their heads real big like this. (laughter) "Simple Made Easy" is a very good talk and I highly recommend you watch it regularly, like re-watch all the time.
ASHLEY: Oh yeah, all the time. It's so good.
So that's our show. Thanks everybody for showing up! We really appreciate you, Ashley, especially, for coming on. And Kyle, always appreciate you, thank you. We'll see you all next week!