 So, up next, we have Aja Hammerly, who is a three-time returning speaker. Thank you for coming. Wow. I love, like, everything she does, every time I get to hear her speak. And so, she was absolutely no-brainer, one of the very first ones we invited. But thank you for coming. And I'm really excited for this one, especially, I wanted to pair James's and Aja's together because I think they're going to work really well together. I'm really excited for this one. So, thank you, Aja. This talk is sharpening the axe. I really wanted to bring a real axe, but I had enough problems with the TSA without bringing one, so it's probably better that I didn't. And just to poke some fun at Ernie, hi, I'm Aja. I am on GitHub as Thagamizer. I tweet at ThagamizerRB and I blog at Thagamizer.com, and the slides for this talk are already up at Thagamizer.com. And I really like dinosaurs. I work for Google Cloud Platform as a developer advocate, which means I get to go around the world to conferences and talk about cool Google Cloud stuff, but that's not this talk. This talk is about feelings, but if you do have questions about running Ruby on Google's hardware, whether that's VMs or App Engine product, come find me during breaks. I'm also going to be at URug tomorrow night, and we have a Slack if you don't want to talk to people in person and rather talk through a keyboard. And because I work at a big company, I have to say this, all coded in this talk is copyright Google and licensed Apache V2, so says lawyer cat. So a little bit about me. I started my career as a test engineer, and then I got to become a software development engineer and test, which is a weird title that seems to only exist in the Pacific Northwest, and then I became a test engineer again, and then I became a software developer, software development. That was my title. So that's what it said on my card. Software development. And then I started working on ops and release management, and then I started working as a software development engineer, and then I got the title developer, and now I'm a developer advocate. So why are these crazy title changes? What's with all these crazy left turns? And the answer is the ferret point. I'm a ferret. You can also call this the magpie point or the something else point. You can decide. So what's the ferret point? I basically hit a point in my career at any given job where I'm just done. I want something new. I want something exciting. Everything else seems more exciting and more interesting, and I'm just very curious about everything that is not what I am currently doing. And I have made some choices in my life that have enabled me to ferret when I need to. One of the big ones is living in a tech city. I'm from Seattle. There's a lot of tech jobs there. There's a lot of tech jobs here in Salt Lake as well. I'm part of the Ruby community. I participate in Seattle RB. I come to conferences and things like that, and that is let me know about job opportunities that exist elsewhere. And I'm constantly learning, and that's what this talk is about. So if you're newer, you may not have realized this yet, but if you've been in the industry a while, you probably have already realized that the amount of stuff we knew when we left our training program, whether that was college or boot camp or an apprenticeship of some form, is insufficient to last us our entire careers. Because tech is constantly changing. Constantly changing. I had a great talk yesterday about the hype cycle in tech, and that was all about change. And lifelong learning, which James brought up, is a lovely buzz phrase, but it's also kind of reality of our jobs as developers, as people working in ops, as people working in QA, PMs, everyone in tech has to be constantly learning, because stuff is constantly changing. And more than anything else, the fact that I have this kind of weird curiosity about very random topics, not all of them technical, is what has enabled me to fare it over the course of my career. So the rest of this talk is going to be about what to learn and how to learn. You should focus on the interesting stuff. I can't focus and learn stuff if I don't find it interesting. For me, that means algorithms, machine learning, new languages. You should also focus on the hard stuff. This is confession time for me. I don't know C. My name is Aja. I'm a developer, and that's OK. But one of the things that I did about a year and a half ago, 18 months ago, was I focused on a book that was written in C, so that I could brush up on my C and decide for once and all that I did understand the underlying concepts. And I did that because I wanted to increase my credibility with a very diverse audience of developers and my credibility at work. I work at Google. There's a lot of very, very smart people who understand very low-level system stuff there. And knowing that I didn't know C made me feel like I was a little bit out of place. But mostly, I think you should focus on think-y stuff, especially early on in your career. And what I mean by think-y stuff is don't focus on specific skills or specific libraries. Instead, you should focus on things like learning a bunch of different programming paradigms just a tiny bit. So learn some functional programming, learn some object-oriented programming, learn some declarative programming, or maybe learn a couple different database designs. Document stores, relational database models, object databases, are super cool. Or dabble in the deep machine learning or deep CSE stuff like machine learning and algorithms, networking. And the reason I think you should do that is because especially early in your career, you're building a scaffold. You want to have just enough knowledge that when you need to understand how Mongo works because you finally have a project that requires something like that, you have the base to build that knowledge on. Or maybe you're working in JavaScript and you don't understand some JavaScript in the library that you're using, and then you realize, oh, this JavaScript is written in a functional style. My personal belief is that JavaScript is a perfectly fine functional language, as it turns out. And that scaffold is what's going to help you keep learning as you go on. So that's all nice and all, but how do you actually do that? And this is the meat of the talk. All sorts of ways to learn. So one of the most popular that I hear about now is this acronym. Who knows what this stands for? Shout it out. Open courses. Yep, exactly. This is things like Coursera, edX, Udemy, iTunes U, and then insert university name here slash free courses. There's tons and tons of these out there. And the formats vary a little bit depending on who's running the course, what organization, but there's generally video lectures, reading assignments, homework assignments, forums where you can interact with either the teachers, maybe some TAs or the other students, and online quizzes and tests. And there's some great things about these. I've done about five of these at this point. One of the things that I get a lot out of it is the fact that it's very structured. It feels like school. There's deadlines. There's stuff I have to get done every week. I have to do this homework assignment and I have to watch these lectures in this week. Otherwise, I won't finish the course. There's help available. Another thing that for me is that there's a common experience with the other people who are taking the course. So I don't feel like I'm a horrible person if I'm struggling. The cons, some of these things are really expensive as it turns out. I've only done free ones, but some of them are fairly expensive. They take a lot of time. I typically, when I do these, devote somewhere between four and eight hours a week to them. They're very, very structured. And if you're one of those people who was more than happy to leave school when school was done for you, these may not be the right thing for you. But if you're going to try it out, I have some tips. First one is read the syllabus. Ensure that the course will work for you. Look at the time requirements. Some courses have tests. The first couple I took didn't have tests. Then I got a course that had a final and I was really confused and kind of freaked out. Like, wait, what? You want me to take a three hour online test? And some have really big projects and some don't accept any late work. So if you have a schedule that is somewhat unpredictable, that might not be the course for you. And related to timing, be realistic about the time you have available. At least on course error, they give you an estimate of how much time per week the course is going to take. That estimate may or may not be accurate for you. Depends on a lot of factors. And I also find it helps to set aside a regular time to watch the video lectures and work on the projects. When I have been taking these courses, I typically set aside a couple hours on Saturday afternoons. One tip from the wise is if your course does have video lectures, speed them up. I usually can watch them at 1.5 or 2x speed. And most folks I know can and still retain the material. I am kind of distractible, so I watch them very fast and knit at the same time. Because otherwise I will get distracted by something that's happening and not actually retain the material. I also recommend not being a guinea pig. Take courses that have been run before or have been run by large universities. I've taken one course that was in its first year, and that was first iteration. And that was really rough. I ended up dropping it halfway through. But the courses I've taken that have been run multiple times have been very good as a general rule. And that's, of course, also true for books or enforcing courses or any type of learning activity. Being the first has some risks. But one of the big things I've gotten out of this is this is a neural net diagram. I took the Stanford machine learning course, which is one of the more famous Coursera courses. And I have had so many awesome conversations at conferences with colleagues, with friends, who have all taken this course. We kind of have this common experience that we can talk about and a common vocabulary of the basics of machine learning. So what if you're thinking, that's very nice, Aja. But it's not quite me. There's other ways to learn. Another one of my favorites is study groups. And some of the best parts of study groups is that it's relationship focused. It's all about people. SeattleRB has been running study groups for several years now. Ryan talked about study groups in his talk at Mountain West RubyConf 2014 called NerdParty 3.1. And I really like the fact that the people in the study group with me are some of my closest nerd friends now. I like that it's relationship focused, and I like that there is in-person accountability. If I'm going to slack off, someone that actually knows where I live will notice. But some of the downsides is you have to have friends who are nerdy, which not all of us are lucky enough to have. And you need a curriculum. If you're going to run a study group, there's some tips. Meet every week. Same reasons as Ryan talked about SeattleRB meeting every week. You want to have your study group meet every week. And you want to have homework. Despite what you may think, you do need to practice. At least I personally need to struggle with material a bit. And I find that homework encourages active participation. One of the downsides of some of the study groups we've had is that we've had a lot of people, and a lot of them just kind of showed up and sat in the corner, listened to four or five of us talk and didn't actually participate in the material. And they ended up not learning as much. So do the homework. I've found that three hours a week-ish, a little bit less, is a good mix. And the pattern that we've been following for most of our recent study groups have been, we read the chapter, we discuss it in person, and then we do the problems associated with that chapter and read the next chapter before our next meeting, which means that we spread out learning the material over a week or a half or so, which means that we can actually see if we're retaining it. Because if you read and then immediately do the problems, you may not have actually gotten it to fully get into your long-term memory. Many books have bad problems, so if you're choosing your homework, only choose the ones that look good or interesting. Don't be afraid to skip problems, because you don't understand them when they don't make sense or they're just not well written. And one of the things that happened in one of our recent study groups that I very much like is we have a gentleman named Javier who is a very good cook. Most of our current study group are cooks of various sorts. And whenever he would forget to do his homework, he would bring us pork to eat at study group meeting. He called it his penance pork. And so sometimes it was barbecue, and sometimes it was ribs, and it was lovely. There's some very, very delicious penance pork was eaten. And keep your study group small. We typically lose between a quarter and a third of the folks who sign up, so we try to start with about eight, which means we have somewhere between five and six that graduate with us. If you have a larger group, you don't feel as accountable. That's just basic psychology. You're like, oh, well, you know, there's 12 of us. No one will notice if I don't show up this week. And then the other big thing is celebrate when you finish. This is a picture of a tiramisu that we had after we finished the season schema, when Aaron, Ryan, and I finished structural interpretation of computer programs, which was our very first study group. We went and got steak. And that steak was well earned. It was awesome to celebrate with my friends that we had completed the book. We had a picnic this summer to celebrate completing another book. You're like, OK, well, that's too much people time for me, Asha. And I'm like, OK, well, how about games and puzzles? And by this, I'm talking about things like Project Euler, Exorcism, Google Code Jam, and Rosalind. Who's here has heard of Rosalind? Couple people. OK. Rosalind is like Project Euler, if you're familiar. So a bunch of small problems that you can solve on your own, except unlike Project Euler, it's focused on bioinformatics, so the intersection of math, computing, and biology. And here's an example problem. Given a DNA string, count the number of each nucleotide and return the count of each. Here is part of my solution. And I'm not showing you the whole solution because part of the Rosalind code of conduct is that you don't share your answers. By the way, I had a much simpler solution. This is a really simple hash and string parsing problem. But one of the things I really like about Rosalind is that the problems build on each other, which encourages you to actually do refactoring, which is something I haven't found I do when I'm doing things like Project Euler or Exorcism. So I've pulled a lot of the stuff for parsing DNA out into this DNA file that I'm requiring at the top. And that's where most of the actual logic is. So one of the things I really like about these small problem game puzzle sites is that I can do the problems in small pieces. I can show up at a hack night, grab a problem, and probably finish it before I leave. And they range in difficulty. Euler, Rosalind, Exorcism, they all have a range of difficulty from very, very easy to very, very hard. And especially Project Euler is similar to many interview questions. If you're someone who always seems to freeze up when you're asked to reverse a linked list on a whiteboard, well, first of all, I would argue that reversing a linked list on a whiteboard is not a particularly good measure of your coding abilities. But if you want to play that game and go to those jobs where they ask those type of questions, doing a bunch of Project Euler problems can help you feel much more confident with that style of questioning. But there's some downsides. All of these sites frequently require pretty deep CS or mathematics knowledge. So if you're someone who came in via a non-traditional path, you may not have spent a bunch of time talking about the prime factorization of very large numbers. So there's gonna be a lot of extra knowledge you need. Rosalind does supply information on the underlying biology, but I still find myself struggling to understand exactly what they're asking sometimes. And you can argue that these aren't real programming. They're toy problems. You don't have to maintain these systems. Quick side note, since I have the time for it. I was talking about the fact that at Seattle RB study groups, we really want people to actively participate. We also have that feeling about the actual group. I would really like it if we had more doers than observers. I don't think that's gonna happen, but I could want it all I want. And one of the things we tried was doing a Project Euler coding challenge where I wrote a Quran job that scraped the Project Euler website and calculated how many problems everyone had done over the course of a month. And because we have a fair number of folks who are from code schools or relatively new to CS or programming, we had two divisions. One was novice, which was only for people who had been programming less than a year. And one was open, which included everyone, including the novices. And each division had a prize, $50, to the person who did the most problems in the division. And if you noticed how I set that up, it meant that a novice could win the open division in addition to the novice division as well. And we did that so that the folks who were newer wouldn't be intimidated by those of us who've been programming for a really long time and think they stood no chance. And we had a no-case turnout. We did it for three months. Some people only did one problem, a number of people didn't participate at all, and some folks did 100 problems. And it was an interesting diversion to try to bring in a different kind of active participation in our group. Another thing you can do to learn, another thing you can do to keep learning is books. Books are made from dead trees. And you can work at your own pace. A lot of people really like this, especially people with schedules that are unpredictable or lives that are fairly hectic. It means that they can set it aside for a couple months and come back. And there's tons of options for topics. I mean, how many programming books are there? We had a great slide yesterday, which is tons of pictures of covers. I don't like books particularly for learning stuff because there's no interactivity. I have a really hard time assessing if I actually know the material, and I have a hard time keeping myself on track because there's no schedule, and there's no one outside of me enforcing me to finish. I am about three quarters of the way through a book teaching me Python using bioinformatics, and I have been three quarters of the way through that book for about nine months. And it can be hard to assess how well you know the material or hard to get help if you get stuck, although more and more books are coming with online forums or answers available on GitHub or other ways of interacting with a community of learners. You're gonna do books, some tips. Find books with exercises to puzzle through, problems, things that you can actually do to interact so that you can see if you're retaining it. Books where you're just copying and pasting code or retyping the code from the chapter, I find I basically don't learn anything because I already know how to type. And bonus points if you can find the answers to those problems on GitHub or elsewhere. Getting through structured interpretation of computer programs, we used answers from the internet multiple times to get unstuck. I like books with short chapters so that I can pick up a chapter and finish it in a week. Then I feel like I've completed something. Structure interpretation of computer programs is not this book. It's several inches thick and has only five chapters. And it took us nine months to get through, so we were not finishing a chapter in a week by any stretch of the imagination. Here are some of my favorite books right now. The Elements of Computing Systems, also known as the Antetetris, is fantastic. Especially if like me, you're still kind of fuzzy on the architectures and operating systems part of computer science. I liked The Little Schemer and the Season Schemer quite a lot. The Reason Schemer is lovely, but my preferred book for logic programming is Clause and Effect, which is a book in prologue. And I'm including the Pragmatic Programmer just because it's a great book. It doesn't have exercises. It's not gonna teach you a skill or a language, but it's a fantastic book, and I highly recommend that everyone's read it at least once. And so now I'm gonna give away a secret for many of the speakers at this conference. A lot of speakers give talks to force them to learn things, myself included. I gave a talk three-ish years ago at Cascadia RubyConf called The Taste of Prologue. I proposed the talk with a general idea of the topic, but didn't actually know what was gonna be included. I kind of wrote up a general proposal and knew I could fill in the blank. And I then used the time between the talk getting accepted and giving the talk to cram. Tons of reading on prologue and doing problems and working through material to figure out how I was gonna get the material across. And that talk has the highest number of YouTube views of any of my talks, and it made the number one spot on our programming about a year and a half ago. And so I'm telling you this not to brag, but to say that you can propose a talk and give a very successful talk when you don't have a good idea of the content ahead of time. You don't need to be an expert when you give the proposal. And the good thing about doing this is you have this lovely deadline of the fact that you're gonna have to get on stage and tell a story for half an hour or 45 minutes. So it's gonna force you to finish. You can't just drop your topic. And your knowledge and expertise on that topic is gonna become public knowledge because people see you speak, they see the videos. And I personally love going to conferences as ways to expand my network. Giving a talk, actually that prologue talk at Cascadia RubyConf was what allowed me to move from a job at a startup to a job at a consultancy. I had to interview, but I talked to them at the conference and I'm like, hey, I really want a job and they're like, great, we'll happily take you. We've seen you give talks twice on two really different topics. We know that you've got a deep enough knowledge to work with us. The bad part about doing this though is that you have a deadline. So if you get really bored or life happens, you still have to finish. And if you end up bored by the topic, you can't drop it. And if you're one of those people who's afraid of speaking in public, you have to speak in public. Some tips, choose a topic you know about or are very interested in and don't propose a talk you don't wanna give. Eventually, eventually I will learn this. Eventually. And keep it simple. I think a lot of people, I've reviewed proposals for a couple different conferences now and a lot of people try to go really deep, but in a half an hour, you're much better giving a 101 or 102 level talk. It's a lot easier to propose, it gives you more flexibility in how much you need to learn and gives you room to kind of take a really deep rabbit hole into one subset of your topic if you need to. Give yourself plenty of time, try to get at least two or three months between the acceptance of the talk and when you'd have to give it and have a rough plan for what books or resources or other things you'll use to learn the topic if the topic is accepted. One last way you can learn on your own time is with throw away apps. This is a screenshot of part of my projects directory and the vast majority of stuff in here has never seen the light of day and probably never will and that's fine. Every one of these directories reflects something that I was working on or curious about or learning at some point, some examples, recipes. Who knows the famous Bill Gates quote about why you would use a computer to store recipes. It's a pretty apocryphal story and I took that a little too literally and tried to make my very first Rails app a recipe database. I'm here to tell you right now that I still don't have the data model figured out for this. Before I really understood how to do white box testing, I spent several, five or six years doing a lot of black box testing which is sitting there and clicking things and seeing if it blows up and one of the things I was needing to test was our integration with a payment service and I needed to do this black box. So I wrote a quick app using Web Brick where you submit a three-digit number and if that three-digit number corresponds to an HTTP error code, it will return that HTTP error code to you. So I could hook up our system to this and test how it handled different error codes from an external service. I know much better ways to do this now, I promise. Here's another one. I'm currently working on this. It's an app that's going to assume that knitting patterns are a programming language of sorts which they pretty much are and then use Ryan Davis' Graphics Library to visualize what the pattern will look like once it's been knitted up. I'm still working on it, still in the parser phase but I'm doing this because I don't have a ton of experience with formal languages in computer science and I want practice and I like to knit. And the same that I keep having to tell myself that not finishing any of these things is not failure because any time I put into these, as long as they're outside of my day-to-day bread and butter stuff is learning. It's experiences that's getting me more skills that I didn't have before. Although I do wish I had finished some of them. Some of you are probably saying, yes, that's nice but I have a life, Aja. I don't have multiple hours a week to dedicate outside of work to learning stuff and I'm here to tell you that you can also spend time at work learning. Whose company does a science fair or a hack week or a hackathon or something at least once a year? I'm seeing some hands. I've worked with a couple teams that do this. I've encouraged a couple teams to do this. Basically the way it works is you set aside a day or a week or a couple hours and people get to come up with new features or new projects for your company to work on or just they get to play with technology and there might be a prize or the prize might be you don't have to work and you get to eat pizza. And it's a great, great experience to play around with technology. So if you don't have this, I recommend suggesting it. And if your boss is like, eh, I'm like, how do we do it as a team building activity? That would have been wasted time anyway if we do regular team building. One of the companies I worked at did this as part of our normal release cycle. We did three month releases and they set aside five developer days and five QA days in every release cycle for an employee idea that didn't come from management. The first time they did it, they had so many ideas that we ended up shipping five of them and they ended up slipping the release by two weeks so that we could get all five of those awesome employee ideas in. There were 30 proposals and they gave us two days to come up with our project proposals. So there's a lot of cool ways to do that. If your company does do it, participate. Participate, use new technologies, use it as an excuse to learn something, to experiment with something. And that might mean just trying out a new role. Maybe you're like, hey, I work in QA, but I'd like to try Dev, or hey, I work in Dev, but I'd like to try project management. Use these types of experiences as a chance to do that. Who works in an agile shop? Prototyping, also known as spiking. Yeah, this is probably something you do. This is a great chance to play around with new libraries or possibly new languages. And they're specifically focused on a problem you're currently having. So solving a pain point that you have right now. I know a lot of folks are like, I don't think my boss is gonna go for this. And I've found that if you do what you're supposed to do with spikes and time box them, whether that's two hours or four days, it's a lot easier to get by it. And you're like, hey, I wanna try out this new thing. I think it'll help us, but I'm only gonna spend this much time on it, so I promise I will not go down a rabbit hole and throw the whole schedule off. And I worked on a team that did a lot of spiking, and one of our big rules was we always threw away the code afterwards. And we always started over from scratch when we were gonna write the production version of the code. And the reason was the code where we learned if a given technology was gonna work was bad, universally bad. So we wanted to start over from scratch and not recreate all of our mistakes, only recreate our successes. Another way you can do time is learning is to work on internal apps. Every company's got some internal apps for some purpose or another. My very first Rails app with actual users was a test case management tool. And I wrote this while I was working in QA, doing black box testing, poking buttons and seeing what happened. And making this app showed my boss a bunch of things. First of all, showed him that I could code, which he was relatively certain at the time that I could not. Showed him that I could deploy my code because they're like, here's the server, make it go. I'm like, okay, I'm gonna figure out how to get the Rails app deployed. And it also showed him that I understood how to manage a project that had a lot of competing priorities. I didn't actually get a ton of work time to work on this. I think I hacked most of it together in the evenings and spent a couple days at the office during the deployment. But as feature requests came in, he saw how I managed them and I actually wrote them out on note cards. Did it all XP style, ripped the cards in half and we were finished. And that showed him that I understood how to run a project. And making that app was a direct part of why I got moved to ops and release management and then eventually to dev because he had this concrete piece of data that he saw that I could do the job. Another way you can do this was with testing. A certain, a lot of internal apps have to do with testing. And I'm specifically not talking about unit testing. I'm talking about the other stuff. Maybe you need something that creates test accounts. Or maybe you need something that creates content for a website, test content so you can see what the website looks like when you actually have the content there. And all of that stuff is great for learning because it doesn't need to be especially robust and it frequently gets thrown away every couple months. We had an intern at one of the companies and her job was to create a content generation site so we could see how our blog system would look. That's one of the great test tools. Another great example is I got moved from software test engineer to software development engineer at my first job because I spent two days learning Pearl and my learning is probably a little strong. I worked through the first five chapters of the camel book. And I learned Pearl because I was testing a feature that involved a bunch of screen scraping and log processing and I'm like, oh, log processing. I'll use Pearl, that's what it was designed for, right? And they saw that I was able to code this as opposed to testing it black box and that helped me get that move from test to development engineer in test. Another job I had, I finally sat down and learned Event Machine because I needed to do load testing and we're load testing a WebSockets app and so I learned Event Machine and Ruby to test WebSockets. I didn't have a reason to do it before that. I could have done the load testing in Node but I wanted to double check that our Node app worked with a different language as the client side. The last idea I have is called learning time. I couldn't think of a better name for it. Basically what I mean is setting aside 30 minutes to an hour of your work day to learn. Maybe that means that you sit there and eat your lunch while reading a nerd book or maybe you do it first thing in the morning. That's actually when I'm doing it right now at my current job. And I highly recommend that you walk away from your desk and go somewhere else in the building to do this. And I have suggested this to a number of people like I don't think my boss would go for it and I can tell you right now that if you own it, it's probably going to be fine. I've done this at every single job that I've had and it's never been a big deal. At my current job at Google, I send out a weekly status report and one of the bullet points is what am I going to learn this week? And I'm not the only one on the team that does that, although I was one of the first ones on the team to do it. And sometimes it's things like I'm going to learn how to not have stage fright when I give a talk. And other weeks it's like I'm going to spend a bunch of time working on learning Python better. If your boss is giving you some flak, the two things I can say is know how what you're learning relates to your current job and set a timer. If your boss can see that you've got a timer running and you've only got 15 minutes left, it's basically a smoke break at that point except for you're spending your smoke break making yourself smarter and expanding the number of things you can do to help the company. So, start today. I want each and every one of you to set a goal right now. Keep it something simple. Write it down. Tell your neighbor. Maybe it's do five project oiler problems this week or talk to my boss and see if we can set up a hack week for later this year. Or maybe it's buy James's book and start learning about mesas. And then once you do, come up with an accountability. I love this word. I made it up myself. Not really. Find someone to help you stay on track. I get really easily distracted. I don't keep my goals unless someone else knows that I have them going on. So maybe it's gonna be you're gonna meet someone at Hack Night every week and you're gonna talk about the chapter of a book you just read. Or maybe you're gonna have someone who emails you on Tuesdays and Thursdays and asks if you've done the project oiler problems you said you were gonna do this week. Or maybe you're gonna have someone and you guys are gonna have a friendly competition and at the end of the month, one of you has to buy an ice cream for the other one. Whoever gets more work done towards your learning goal. And if you're one of those people who doesn't want anyone else to see your learning and I know that there are those people out there. First of all, I'm gonna tell you make loud mistakes because people can't help you if they don't know you're struggling. And second of all, there are apps that can do this. I have a habit tracking app that uses an RPG framework and I am a level 50 mage and it reminds me every day to make sure that I've done the things that are important. One of those is mindfulness meditation. Another one of those is spend some time learning. You can also use things like just reminders on your phone with lots of ways to keep track of this and accept setbacks. So some weeks you're gonna do better than others. You're gonna get the flu. Your kid's gonna get sick. You're gonna have a huge release at work. Your server, your data center is gonna catch fire. Been there done that twice. It's okay. You don't have to be perfect but if you make the effort to learn it's gonna give you a lot more opportunities in the future. So thank you all. Thank you Mike for having me. I've come to this conference four times now and I loved it every single time. I do have, so the question is do I have any personal experience with having a mentor? I've had several mentors. Aaron Patterson, Ryan Davis are actually pretty high on that list. Also at Google, I was assigned a mentor on my very first day and he has been a fantastic resource for me. And when I was similar to saying things like hey, I wanna learn Python. He's like, here are five things I recommend. Here's what I know of your personality. Go try this out. I've also found, even though it's a little scary, I've been asked to be a mentor and I always really like it. So if you're thinking, hey, there's this person I really like out there. Say, hey, are you willing to be my mentor and have an idea of what you want that to look like? Maybe it's, you all have a Slack conversation for 30 minutes a week or maybe one of the last conferences I went to, someone's like, I want you to be my mentor. I'm going to send you Ruby questions I have over email. I'm like, okay, I will happily answer those for you. So if you have an idea of what you want, you're more likely to get what you want out of the relationship. And I promised y'all a kitten. So with the little schema, the question was how do you structure your study groups that you have an idea of how the timeframe and stuff is gonna work? With structure and interpretation of computer programs, which was the first one, we decided we were doing a study group. And we said we were gonna meet weekly for an hour to two hours. Since then, and that took us nine months and I don't think if you had asked any of us how long it was gonna take, we would have said nine months. Don't do that. Don't do every problem. We've gotten better. What we typically do is we take a book, we look at it and we say we're gonna try to do a chapter a week. We almost always meet in the hour before Seattle RBS hack night. So we know we're only gonna meet for an hour and we give ourselves permission to stretch a couple chapters out or to skip chapters that all of us find boring. So usually it ends up being that it takes us plus or minus 20% of the number of weeks equals the number of chapters. And that's worked out pretty well for us. It's not gonna work with all books, obviously. So the question was, with all these different ways of learning, how much time am I actually spending on it? And the thing is I don't do these all simultaneously. I haven't done a Coursera course in about a year. I'm currently dragging around some nerd book at all times and when I get to work in the morning while I'm having my coffee, I sit down at a table, not at my desk, but in a window seat because the way our office is set up, I can look out over a beautiful body of water and I read for half an hour. And I do that and then I do my mail and then I go to my desk and actually start working. When I was doing the Coursera courses, I wouldn't be doing that. I might spend a little bit of time in the morning watching one of my video lectures. And that would be my learning time at work that day. And so I just, I'm a ferret. If I do too many Coursera courses, they get boring. If I do too many books, they get boring. I just mix it up. And so on average, actual learning time on a good week is probably about three to four hours. And that includes the fact that I don't actually spend our hack night learning a great deal right now. I'm spend most of it chatting with people and being social. So if I was actually being good about using hack night for its purpose, I wouldn't be spending more time learning. Thank you all.