 But they wouldn't let me through TSA with it, considering that they thought that my plastic dinosaur is required extra screening. So I'm Oshah Hammerly, I am on GitHub as Thagamizer. I tweet at ThagamizerRB and my phone is very carefully stowed up in the boxes and my laptop is not connected to the internet and I really like it when people tweet at me during my talk because I check them all afterwards. So you should do that. My blog is at Thagamizer.com and the slides for a version of this talk are already up there. That's from last week. I will put the PG-13 version of those slides, which is the talk I am giving today, up very shortly. I'm dealing with wireless problems. Gee, I was in Salt Lake. I'm a little drunk and I really like dinosaurs as it turns out. This is what happens when you pay a guy in Malaysia to make you an icon, you get a giant dinosaur like that. So I work at Google on the Google Cloud platform. I am lucky that two of my lovely co-workers are here with me at this conference and you're going to hear actual intelligent things from them. For me, you're just going to hear war stories and I hope that's okay because that's becoming a Ruby on Ales theme for me. You can come find me or my co-worker Julia and we can answer any questions about what we have to run your site. That would be awesome. And if you don't want to talk to an actual person, but prefer to use a keyboard, we have a Slack and you should join that and there's a Ruby channel and there are awesome people like Mike Moore in that Ruby channel. And because I work at a big company, Lawyer Cat says that any code in this talk is copyright Google and licensed Apache V2. That is my sister's cat. And once more, this talk is dedicated to my family, specifically my grandmother. So a little bit about me. I started my career as a test engineer. Who here works in tests? It's okay. You can acknowledge it. We love you. Awesome. And then I became a software engineer in test, which is this position that only seems to exist in the Pacific Northwest. And then I was test engineer again. And then my title was software development, but I was still actually a test engineer. And then I became an ops slash release manager slash herder of lots and lots of cats, where cats are approximately equal to developers. And then I became a software development engineer. And then my title became developer. And now my title is developer advocate. So why all the crazy changes? And the answer to that question is this. I hit my fucking point. The PG version of this is the ferret point. You can also call it the magpie point because they also like shiny things and being curious. You get to decide which one is more appropriate to you. But I hit this point in every job that I have where something else becomes decidedly new and shiny. I want to explore all the things. I want to do something that I am not currently doing. And quite frankly, I'm bored or burnt out or just done with what I'm doing. And so I've learned to enable my ferret. And there's a couple things that I've done that have enabled me to ferret over the course of my 13 to 15-ish year career. And that includes living in a tech city. I'm from Seattle, but I assume most of you are from tech cities too, otherwise you wouldn't be here. I am part of the community. I very much appreciate this. This is my Ruby community, and you guys make me happy. And I am super glad that I get to share this with people I work with and other people that I love while I'm here. I've been taking pictures and sending them to friends all day, including pictures of Joan and playing magic on stage during lunch. But the big thing that enables me to ferret is that I'm constantly learning. And that's what this talk is about. So news flash for some of you, I hope this doesn't scare you and send you away from the community. What we learned in whatever training program we had, whether that was college or university, on the job training as an internship or an apprenticeship or went through a boot camp or a code school, is not sufficient to last us for the rest of our careers. Technology changes. That's actually why I like it, because I don't get bored. I get to do new things on a regular basis. And we, as the people who use technology and make technology, have to keep up. And this is a lovely, lovely buzz phrase, lifelong learning. If you have a kid in elementary school, and my guess is the phrase lifelong learners is probably somewhere in that school's mission statement. But more than anything, lifelong learning is what has enabled me to ferret over the years. So what should you be learning? Well, interesting stuff. Quite frankly, I don't actually spend any time learning stuff I don't find interesting. My English grammar is pretty bad. I have to have a copy editor for my blog. I really should learn English grammar, but I think it's boring. So I haven't learned it yet. You should see my speaker notes. You should also focus on the hard stuff. This is my confession time. Hi, my name is Aja, and I don't know C. And that's OK. But one of the study groups that I've done over the last couple years was a study group on building your own Lisp in C. And the reason I did that was that I wanted to be able to talk to all of the people who know C and have a vague idea what they were talking about. I wanted to say, yes, I understand pointers, and I still don't care, as opposed to I don't understand pointers. And really, during that book, writing some actual hard code in C was one of the best things I've done for my credibility in my career. But more important than either the hard stuff or the interesting stuff is the thinky stuff. And what do I mean by the thinky stuff? I mean focusing on ideas, not specific skills. This is especially true for those who are in their first three years of their software slash tech career. Raise your hands. I'm curious. Yeah, that's what I thought. I was expecting somewhere between a quarter and a third of this audience. That's about right. So focus on different programming paradigms, not specific languages. So focus on functional programming, declarative programming, object-oriented programming. Learn about different database designs, relational databases, object databases, document stores. They're all in active use right now in the community. And you should focus on them so that you have an idea of what those words mean so that when you end up with a problem, you understand that you need, you understand what it is that you should be using. And more importantly, when you have to dive into a language like LISP or Clojure, you're like, oh, this is a functional language. I know the basics of functional languages, so I have a scaffold to build my knowledge of this language on. You want to build that scaffold. You want to get broad as much as you can so that that way, no matter what crazy turns your career takes, you have a place to start. So that's all nice. You're probably thinking, yes, that's great. I'll show you a fantastic raw, raw, go brains talk, right going on right now. But how do I actually do this? And the how is the rest of this talk. And that's going to take approximately 20 minutes. So hold on. First off, MOOCs, who knows what this abbreviation stands for? Yeah. Exactly. That's what it stands for. Some examples of massive open online courses include Coursera, edX, Udemy, iTunes U, insert university name here, free slash open slash something courses. The format varies a lot. But common things include video lectures, reading and or homework assignments, forums where you can talk to other students or possibly some TAs and maybe the instructor, and online quizzes and or tests. And some of the pros of this are that it's very, very structured. Help is frequently available in terms of the forums and that you have a common experience. One of the coolest things I have done is I did the Stanford machine learning course on Coursera. My guess is that there's at least 2,000 people in this audience who have also done it because you guys are giant nerds just like me. And I have had more interesting conversations with coworkers about machine learning stuff because I got just a tiny bit of machine learning knowledge. I've made a neural net. Not exactly sure what I did, but I made one. And that was cool. So that's a really cool thing. And it's less likely on some of these big ones that the quality of these things is going to be low because frequently they've been vetted a lot. Some of the downsides, some of them aren't free, which is sad. So you need money. They frequently take a lot of time. And they're structured. So if you're someone who really didn't like school, this is probably not for you because they totally feel like school. But if you're going to go do it, here's some tips. Read the syllabus. It's surprisingly how many people don't do it. And make sure that the course is going to work for you. My first couple of course error courses didn't have tests. And then I got a class that had a test. It had a midterm and a final. And I gave up before the final because the idea of staring down a two-hour online test on statistics did not sound fun anymore. And I should have just given it up from the beginning. I shouldn't have put as much effort into it if I was going to quit halfway through. Some have very rigorous timelines, like they don't accept any late work at all. And if you have a chaotic life, like you have small children, that may not work for you. Speaking of time, be realistic about the time you have available. Many of these courses will tell you about how much time it takes per week. Believe them. They probably overestimate, but it's better to overestimate the amount of dedication you need than to underestimate it. And I like setting aside a regular time to watch the videos and do my homework. When I've been taking course error courses, that's typically 9 to noon on Saturday mornings. I go to a cafe, put my headphones on, and I work. Other folks do better, but I actually find that setting aside a regular time to focus on my learning and self-improvement really helps. Here's a hint on saving time. Most of these programs will let you speed up the lectures. I can say that personally, I like watching the lectures at two times their normal speed. Yes, the professors sound a little bit like chipmunks. It's okay. I also have to be knitting or fidgeting with something when I watch the lectures, because otherwise I fall into the trap of social media and I forget what I'm doing. Maybe you have more dedication than me. I fare it. I acknowledge this. And one other thing, and this is true about any kind of learning opportunity is don't be a guinea pig. You don't want to be in the first class for a lot of these things, especially if it's from an unknown school or an unknown organization that hasn't done one of these before. Quality varies a lot. So if you can find a course that's been run multiple times before successfully or is from a school that is well-known for good teaching, you're probably gonna have a better experience. This is also, of course, true for books, in-person courses, and other such things. And that right there is a neural net. Ooh, ah. So my favorite way to learn is study groups. We do a lot of these at Seattle RB. The best part of it is that you get to actually study with other human beings in-person. They're relationship-focused. Some of my study group buddies are in the audience right now and you are awesome. And they are some of my closest nerd friends at this point. Yes, I call them my nerd friends, that is okay. And I like the in-person accountability and I like the fact that there's assistance available to me if I get stuck. I can know that the next week I will show up, I will grab my coffee, and I can say, hey, I don't get it. And then someone will come up with some crazy analogy about tube socks and it may or may not work for me. That really happened. Cons about doing study groups though is that you have to have friends. So if you don't have friends, this may not be for you. You also need a curriculum. So some tips. You should meet every week. If you wanna know why you should meet every week, I'm not gonna tell you. You'll find Ryan Davis's talk from Mountain West RubyConf 2014 called Nerd Party 3.1 and it tells you why you should meet every week. You should have homework. You need time to practice. You need to actually engage with the content to know if you're understanding it. I firmly believe this. I have a minor in educational psychology and education so I'm gonna say that that makes me an utter and complete expert. No, it really doesn't. But you do need to engage with material to figure out if you actually know it. And we also found that having homework encouraged active participation as opposed to people who just kinda sat there and tried to learn by osmosis every week. Sorry, diffusion. It wasn't water going through. I found that about less than three hours a week is about the right amount for homework, more than an hour and that should be your reading and that should be your homework and your reading and the way we typically do it is we read a chapter, we talk about it and for the next week we do the exercises on that chapter and read the next chapter so that we spread the learning on a given chapter out over at least a week so that we know that it's actually getting into, hopefully, something that slightly resembles long-term memory. And one of my favorite things about our most recent study group was that if people didn't do their homework, they brought us penance pork. So that was various lovely meaty things that they had cooked that we all got to sample if they didn't do their homework. So if you didn't do your homework, you had to cook for us. It was fantastic. Keep the group small. Somewhere between six and eight seems about ideal, assuming that you're gonna lose a couple people from the beginning. This is both for accountability reasons. We're human, we feel less accountable when we have a larger group. It's the bystander effect. But it also can ensure that everyone can participate. It always really bugged me when we had bigger groups and there was someone who I was pretty sure wasn't getting it, but they were afraid to ask questions in front of the huge group. Whereas when it's six people sitting around a table, we all get to say, I don't get it and it's okay. And when you're done, you should totally celebrate. You should go get steak. One of my favorite ever outings was with Aaron Patterson, Ryan Davis, and some of the Japanese Rubyists. We all went and got a steak to celebrate finishing structure, interpretation, and computer programs. It was fantastic. It took us nine months, so we earned that steak. This is one of Ryan's steaks. And we also had a picnic once and Lito, where are you Lito? You're on the way back. Hi Lito, made us tiramisu and it was delicious. And we had just finished a book on scheme. Hence the reason there's a lambda on the tiramisu. Another way you can learn is games and puzzles. Project Euler, Exorcism, Google Code Jam, Rosalind. Rosalind's one of my current favorites. Rosalind is like Exorcism or Project Euler, but it's for bioinformatics problems, like this one. Given a DNA strain, count the number of each nucleotide and return the count for each. Here's part of my solution. One of the rules of Rosalind is you can't share your code online, so I'm only giving you part of it. My solution was actually much easier, simpler the first time throw, but Rosalind problems are lovely that they build on each other, so you're encouraged to do refactorings. So I've extracted a whole bunch of the code for dealing with DNA strings into a DNA library. I really like these because they're easy to do in small pieces. If I show up at a hack site, I have no project, I can work through a problem or two of these in 30 minutes to an hour and I feel like I've finished something. I'm a big fan of finishing things. And they range in difficulty from easy to hard, and they're similar to many interview questions. If you're someone who's trying to find a programming job at a stereotypical big company, I personally think one of the best things you can do is suffer through about a dozen project oiler problems because you will probably see some variant of those problems in your interviewing. The downside of these is they frequently require deep CS or math or in the case of Rosalind biology and knowledge in order to be successful and they're toy problems. They're not real programming. You're not gonna have to deal with the consequences of making bad or not so ideal decisions in your code for the sake of speed. Quick aside, Seattle Abbey, we've run a coding challenge for three months. We wanted to increase the ratio of spectators to doers at our meetings. I'm a big fan of having more doers and fewer spectators. So we took project oiler problems because we had a wide range of experience. We had two divisions. We had novice for those who'd been coding for less than a year and we had open for everyone, including those that had been coding less than a year. And we awarded prizes in each division. A $50 prize sponsored by myself originally and then a local company. And folks completed anywhere between one and 100 problems but it was an interesting experience. I just wrote a simple mechanized script that scrapped the project oiler website to figure out how many problems people had done. But it was an interesting experience to see how we could increase the amount of people participating as opposed to people spectating at our meetings. Books, some people like books because they're made of trees. There's also many options for topics for books. I don't like books because they're not interactive. And it's hard to assess for me at least how well I understand the material in a book. And it's also really hard to get help, although more and more books are coming with online forums. I recently purchased a book on bioinformatics with Python because I wanted to learn Python. And one of the things I really liked about it was there's an online forum that has answers and a place where I can get help if I'm confused. So some tips. Find books that have exercises, books that are just copy and paste this code, copy and paste this code, copy and paste this code are hard to ensure that you're actually learning from unless you're way more dedicated than me. Find books with short chapters. I like feeling like I'm done. And so knowing that I can work through a chapter in the course of a week is lovely. If you have the desire to do destruction interpretation of computer programs, it does not in fact have short chapters. It's like 900 pages and has five chapters. And it took us nine months to get through. So that is an example of not short chapters. Here are some of my current favorite books. The Elements of Computing Systems is also known as Nand to Tetris. If you're one of those people who still thinks your computer is a wizard box, you should probably check this out. It's pretty cool. It takes you up from first principles of logic gates all the way up to something that's sort of vaguely resembles Java if you squint. Including a, oh wow, an intermediate code layer. I also really like the Schemer books, especially the Little and Season Schemer. The Reason Schemer is fine, but if you wanna learn logic programming, I prefer Clause and Effect. That's all about Prologue. It's awesome. Prologue will be coming back later in this talk. And if you need a book that's not about code, but it's more about being a professional programmer, the programmatic programmer is a good book. It will always be a good book. So back to Prologue. Talks. Little non fact. A lot of your speakers today, or maybe not today, but a lot of speakers sign up to give a talk on a topic because they wanna learn it. And you can do that too. One of my best talks, the talk that got me one of the reasons I got my job at Google. My talk that made the top of our programming still has like 10x the views of any of my other talks on YouTube was a talk called The Taste of Prologue that I gave at Cascadia RubyConf. I proposed the talk because you know, I wanted an excuse to learn more Prologue. And they accepted it. So then I had a reason to learn more Prologue. And I'm saying all this not to brag, but to point out that people who choose to learn material to then give a talk on it can frequently give very good talks. It seems to me this thing that well, if you don't already an expert, you can't give a talk on it. But really the best time to give a talk and to teach something is right after you learn it. So some good things about this is that that deadline of having to stand up on stage in front of a lot of people forces you to finish. And your knowledge and your expertise in a given topic become public knowledge, which can lead to really cool opportunities such as more talks or jobs or other very cool things. And it's a really good way to meet people and expand your community. The bad things is that you have a deadline. So if life gets in the way, you still have to give the talk. And if you're one of those people who would not want to be me right now because I'm on stage in front of several hundred of you, probably not the best learning opportunity for you. Although speaking is awesome and you should all totally do it. So some tips. Pick a topic that you are willing to learn about. So you should either know it a little bit or be very interested in it. And don't propose a talk that you don't want to give. Eventually, eventually I will learn this lesson. I have not learned it yet. Keep your proposal or abstract simple. One of the things that I've noticed having been on a couple program committees is that they frequently have a lot of talks that are at very high level and they frequently want more talks in the 101, 102, intro to advanced beginner level to round out the program. So if you're like, I know something about this and I will give you an introduction to it, they're probably going to like that idea because it reaches more of their audience. Don't remember if it was, I think it was Sandy Metz who said that audiences want to hear 80% material they already know. And that makes me a little sad at times but it should help you out if you want to give an intro level talk. Give yourself plenty of time, two to three months from the acceptance of the proposal to when you have to give it, have a plan, know what books or resources you're going to use to learn the material and make sure that you know what you're going to do if your talk is accepted because if you don't want your talk to be accepted it probably will as I have learned multiple times potentially right now. One of my other favorite ways to learn is throw away apps. This is a snapshot of part of my projects folder on the Mac that's currently giving this talk. Majority of stuff in here has never seen the light of day and never will. There's a lot of stuff I'm deeply embarrassed by here. And that's okay. Some examples. My very first Rails app was supposed to be a wrap to store my recipes based on the rough quote from Bill Gates of what would people use a computer for? Well, they could use it to store recipes. I never even got the data model figured out on this one. Erregenerator, this is a simple web brick app that I used before. I understood how to use do mocking properly. Yes, mocking. And the idea is that you send a request to this thing and the request includes a three-digit number. And if that number corresponds to a known HTTP error code that's the error code that the server responds with. And I was using this for testing our integration with external websites when I was doing black box manual testing. There are better ways to do this, trust me. I also have a knitting app that is in progress. Turns out if you're familiar with knitting and I was knitting with at least one other person this morning, that knitting patterns are almost probably maybe a term in complete language that really sort of look like it if you squint hard. And so I'm trying to figure out, I don't know formal language theory in programming very well at all. And it's an error that I really feel like I should know. So I'm trying to figure out how to make a grammar for knitting patterns, parse knitting patterns, and then visualize them using the graphics gem that Ryan wrote so I can figure out what the lace pattern will look like after I'm done knitting it. One of the important things that's been hard for me to learn though is that not finishing is not equal failure. Even four hours or two hours or 20 minutes dedicated to one of these problems is the time that I am learning. And so you should not feel bad if your stuff doesn't stay the light of day because I am trying very hard not to feel bad too. So some of you are going, yes, that's all nice, but I don't have very much free time. How can I do this on my job? I have answers. So whose company has science fairs slash hack week slash hackathon slash, we called it project designated hitter at one of my companies. I'm seeing hands. So many companies will do this, basically it's a period of time for employees to either work on potential new features or things completely unrelated to their project. And it's a chance to just play around with new technology. So if your company doesn't have it, you should totally suggest it. And if you can't convince them to do it as a practical way of you guys learning new things and becoming better engineers or whatever kind of engineer you are, call it team building because this is a lot more fun a lot of the time eating pizza, hanging out, working on crazy technology problems with my coworkers is more fun than going and doing bumper cars or taking a cooking class or whatever else the mandatory fun of the day might be. So call it team building. Now if you do have it, totally sign up to do it. Use it as an excuse to learn something new. One of the companies that I did this at, they had dedicated a week of dev time and a week of test time to whatever the winning project was and it would go into the product. And they ended up having five good projects so they just released them all as beta with one day of dev time and one day of test time. But we got five really cool features out of it. Another thing you can do at work to learn stuff is to prototype. You guys might call this spiking if you are super-duper agile. The important thing now, if you go up to your boss and say I wanna learn this new thing, they're gonna say why don't you do that on your own time unless they're super cool. But if you say hey, I wanna spend two weeks to figure out or two days or 30 minutes to figure out if new library solves problem we are currently having, you've time-boxed it so they're more likely to say yes and you've related it to your job. So time-box your spikes. Somewhere between a couple hours and a couple days is probably more than enough, otherwise your problem is probably too big. And make sure you throw away your code. Who here is embarrassed about the first code they ever wrote? Mine was a calculator app written in Cubasic on paper. So, and I have been informed by one of my relatives that I wrote all of the C's backwards in it because it was a long time ago. So, don't be afraid to throw away code. Your second attempt is probably gonna be better than your first, probably. You can also do internal apps. My very first Rails app with actual users and by actual users I mean actual user because it was one person other than me was a test case management tool while I was working in Blackbox QA. We had brought in someone as a contractor we needed to track that we had done all the appropriate test cases for what we were testing. And that job got me to be able to move from Blackbox QA to release management and then to dev because it showed my boss three things. One, Aja can code. Wow. Two, Aja could deploy her code when given a server. I could deploy Rails. It was awesome. And three, that I understood the needs the need to manage project complexity. Everyone had a bunch of features. I had a bunch of quite literally three by five cards and I ripped them up when I added a feature and I had prioritized them and I was able to make trade-offs and I was able to make it work because of that. That making that app with its one user was a huge part of what allowed me to have that move. And so don't be afraid to make internal apps that help make your job easier. Testing, I'm not talking about unit testing although I hope you all unit test. I'm specifically talking about those more complicated test tools. Maybe you need content generation. Maybe you need something that creates test accounts. Those are all also variations on the internal app theme and those are great opportunities for learning something because that code typically doesn't last more than a couple months. You can throw it away and then you can do it again in a different language. A great example was one of the jobs I had we needed a load testing framework for an app we were writing and it was a web socket app and we had written the app in Node.js and I decided to write the load testing framework in Ruby because I wanted to learn Event Machine. Yeah. It worked and the important thing was that I wanted to learn Event Machine and we also proved that you could integrate with our Node.js app with a web sockets framework from another language that was potentially working with different sets of assumptions about how web sockets worked. It was really important to me that we proved since any of our clients were gonna be using any number of languages that this did work cross language and it gave me a chance to learn Event Machine so that was pretty cool. My final suggestion for you was something I call learning time. Quite literally set aside half an hour of your day, walk away from your desk and learn something. My current job I'm frequently doing this in the morning while I have my coffee and my breakfast. I sit down with a book and I read. At previous jobs I would do it over lunch. I would take my book away from my desk, go sit in the lunch room and I would read or I would work through problems on Coursera or I'd argue with code or I'd hiss at things and growl at things because that's what I do when my code misbehaves. And here's the weird thing is everyone I suggested was like, my boss would never go for it and I've never had it questioned. And someone's like, hey, what you doing? Learning, okay, own it. If you own it, if you say, hey, I'm taking this much time, I've got a timer set, you can even have the timer sitting out on the table, here's what I'm learning, here's how it's gonna make me a better employee for you and generally that is here's how it's going to make me a better developer, whether or not I'm gonna work for you in three months anyway. And I've quite literally never had 30 minutes a day questioned and I've done this at every job that I've had. Not consistently, sometimes I do it more than others, sometimes I'm really stressed out and we've got a lot of work to do and I put it aside for a while but I've never had a 30 minutes a day question. So, start today, set a goal, keep it simple, make it something simple. Say I'm gonna do five project oiler problems between now and the end of the conference or I'm gonna talk to my boss about doing a hack week. If your boss is here, you can poke them and then you'll be done. Or you're gonna say, I'm gonna buy a book by someone else in the Ruby community. There's a lot of great books out there right now on completely esoteric topics. And then find an accountability buddy. Ernie showed that he did his accountability on speaking to the entire internet. You can do that, I have done that. I find it a little more effective when you do it to one or two individuals because of the bystander effect. And ask that person that you're having help you stay on track to poke at you. Have them remind you that you promised to do five project oiler problems this week. Have them meet you at your local meetups hack night and you guys can hack together on something. Maybe you guys can do my force pull request together. And just make sure that someone else knows what you're trying to do so that they can politely and friendly or not so friendly remind you that you're trying to improve yourself. You're trying to increase the number of opportunities that you will have. And if you can't deal with actual people you can use an app. I use an app sometimes. Except setbacks, know that some days they're gonna be better than others and some weeks they're gonna be better than others. Reality always gets a vote. It's one of the only things I learned in any of my internships is the phrase reality always gets a vote. Cause reality always gets a vote. So I wanna say thank you. We have some swag from Google down here. There's stickers and t-shirts and bags and stuff. I have dinosaurs but I only give them out to people who are nice to me. And if you have any questions for me you can see a kitten and I highly recommend that we get at least one question because the first picture is awesome. So the question is do I like hack week or breaking it up more over the year? I am a creature of changing habits on a regular basis so I prefer breaking it up but I also know that some people really wanna dig into a project that's gonna take more than four or five hours. And I've seen both work really, really well. So it depends on the kinds of interests of your team. Yeah, yes. So have I experimented with learning more than one thing in parallel? Yes, and it did not go well. I try to focus on a study group or a task at a time. So what would be the highest return of something that I could choose to study right now? For me, generally speaking, I think you should learn different programming paradigms because I think functional languages are coming back and if you don't know how to code in a functional language you're gonna have a sad time. I say this as someone who's never, well unless you count JavaScript as a functional language and I do, has never written a line of functional code professionally. My personal next thing to learn is actually English grammar. I have a workbook, it is on my coffee table. SICP or Little Schemer? I think that you should all drink the Kool-Aid and do all of SICP. No, actually I think working through Little Schemer is a good way to get started and if you like it you should do SICP. Start with the book that's gonna tell you to go take a cookie break. Don't start with the book that's gonna make you angry. Jelly stains, exactly. I'm just gonna click cat pictures at this point because I don't want to answer any more questions. Yes. Do I learn interesting things that don't retain to my day-to-day not job? Yes. I have learned how to grow hot peppers in Seattle. I have learned how to knit. How do I retain that knowledge? By actively making time away from my screen. For my mental health I need some things that are not screen related which is why when everyone else is sitting here on their computers I've actually been knitting most of the day and paying attention to talks but I need to not have more pixels in my life some days. Shaming, we keep people engaged in study groups by shaving. This is actually why I recommend the Schemer books. There are 10 chapters in each of them. They're relatively short. They're written in Socratic Dialogue and I find that feeling so much not like school makes it so that people participate. The other thing we do is we just poke at people. I took one of my CS classes in college. In the syllabus it said if you send a sickness report to the graders they will bring you chicken soup and that was actually not a lie. And I missed the class once because I was having a bad day and I'm like, I don't need to go to lecture and the professor noticed. So one of the things I found is if someone doesn't show up at study group we all hit them up on Twitter. We hit them up on Slack. We're like, hey, you okay? You need us to bring you sick? You need us to bring you soup? And we have. So it's building the community. You wanna make a community where people feel accountable and people feel like they matter because then they'll be less likely to not show up. Or they'll bring you pork if they didn't do their homework, which is truly fantastic. Thank you all.