 of the swamps of southern Louisiana. It's like real Cajun country down there, really rugged. These people are one with the swamp. And I went on this kind of touristy boat tour with a Cajun tour guide. And we saw just a ton of gators, right? You can look at these guys. You see, most of them are, like, pretty big. They look pretty tough. They were pretty cool to see. But the best part of the tour was the grand finale. The tour guide turns around. He reaches into this cooler. And he takes out this little baby two-foot gator. He was adorable. And the tour guide says to us, so we take these guys out of the water when they're just about this big. And we use them for the tours. We rotate them. They don't have to do the tours every day. But we can't put them back into the swamp until they're, like, at least four feet long. Because if we put them back before then, they're very much at risk of getting eaten by the bigger gators. Not that the bigger gators are, like, they're not cannibalistic. But that's just in their nature. If you bother them, they'll come down on you and crush your skull. So once the guides catch a little gator, they stick with him, and they let him grow. And they introduce him to life as a tour centerpiece until he can swim by himself without fear. So why am I telling you this? Well, because this narrative perfectly frames the phase of a junior developer's life that I'm going to cover in this talk. If you think of the baby gators as junior developers, and the big gators as confusion and anxiety that can sometimes become so overpowering that they crush ambition, and the swamp tour guide as a mentor, I think you'll have a pretty good sense of the scope of what we're talking about. It's the time between being really, really, really small and being just big enough to get by on your own. And just like with the gators, this is a really critical time in a new developer's life. Because if they don't get the experiences and the training they need, you could lose them. So we're going to talk about how to be just tough enough on your little gator to help them grow, and we're going to talk about how to be a tough little gator on your own. So welcome. I hope you will enjoy it. Who am I? Quick bio. My name is Alice Natola. I'm a Rails developer here at Constant Contact. I studied a little bit of computer science in college, didn't major in it. After I graduated, wanted to be an actress. I went to theater school for a year, did a bunch of other stuff, planned birthday parties for the children of the 1% for a while. Finally decided it was time to come back to programming. I enrolled in General Assembly, which is one of the major developer boot camps in New York. Did that last summer. Started as an intern here in October and came on full-time in January. So that is my background. Now, a little bit of honest talk here. I'd be willing to bet there are a few people in this room who don't really think that training junior developers is a really important topic. You just really don't care about UIs or puppets, so you thought you'd come to this, right? Is there anybody? Be honest. Be honest. Please be honest. Please be honest. OK, we got one guy. We got one guy in the back. I might have a truly enlightened audience here, but either way, if you're not being honest and you really don't think this is an important topic, I'm about to convince you. So according to the US Bureau of Labor Statistics, the projected growth for software developers between 2012 and 2022 is 22%. That's a lot faster than the average, which is 11%. And that's awesome. That's great for us, right? So how are all of these new jobs going to be filled? Well, obviously, they're going to be filled with all of the people coming out of colleges and boot camps right now, right? OK, except there is one little problem. I did a little bit of investigative journalism. Went to Glassdoor.com. I did a job search for junior software, 8,874. Senior software, 89,451. That's an order of magnitude larger. Indeed, 16,000 for junior software, 116,000 for senior software. Career Builder. Junior software, 1848. Senior software, 12,042. And finally, Stack Overflow Careers. Junior software, 1600. Senior software, 1700. Well, it's different. Why is that? Well, this part drops into speculation, but I'd be willing to bet that the companies that are posting on Stack Overflow are more tech savvy. They're more likely to be software as a service companies. In general, they are more heavily invested in delivering quality software. And they're the ones that are hiring juniors and seniors at about the same rate. So why do you think that is? Because junior developers are good for your team for a lot of different reasons. They challenge more experienced engineers to clarify and refine their knowledge. And because practicing communication makes your team stronger. I was on a panel at Launch Academy recently with people at a lot of different levels of experience in the industry. And this one quality kept on coming up, that what they're looking for when they hire is not just a really great engineer, but someone who can communicate. Because as an engineer, you're going to be in a lot of positions where you need to communicate with people who might not be as familiar with technology as you. And mentoring is a great way to practice that. Finally, people do their best work when they're treading water. In the best case scenario, you can challenge everybody on your team all the time. But that's a lot harder to do if everybody on your team is really experienced. Junior developers make that goal a lot easier to achieve. So I get why a lot of people don't want to do this. Training is really hard. It seems like a risk because it takes a lot of time. But it doesn't really need to be that hard. We're going to go through three phases of the process. The phases are based on the noobs' comfort level. I'm going to refer to it as noob, because that's a lot faster to say than junior developer. And each phase covers advice for both the mentor and the noob. Now, you'll notice that these phases have no time estimates, because everybody is different. And you might even be getting somebody on your team who's at phase two or even phase three. So I'm not going to say you need to be in this phase for this amount of time. And one thing I want to point out is mentors. All of the noob advice can be helpful for you too, either because it's something you can encourage your noob to do or because it's something you actually don't do yourself. Phase one, learning to swim. So this phase looks like you know some basics, but you've never been in a large code base before, which is a really different skill from pushing out homework assignments in school. All in all, you don't have any experience working on a team making software that people actually use. For mentors. For the best case scenario, you can assign the noob a dedicated mentor. This should be somebody who's already a pretty good communicator and somebody who actively budgets time for the noob and will stick to that. Now at New Relic, they estimated that their onboarding time for new people was about six months, but then when they started doing this, that time dropped to three months. And that's a lot of time and money saved. So this is a really good process. But I want to make it clear that for the rest of this talk, I'm not assuming you have done this. You don't need to be a dedicated mentor to use any of these tips. You can step in and be a good mentor at any point in the process. So remember how important communication was? We're gonna talk about a template for that. Overall, when you are communicating with your noob, you wanna provide a framework for learning without spoon feeding all the answers. I'm gonna compare it to something you probably already know, the template method pattern. So say you have a class developer and that class does stuff. Debug, learn pattern, learn quirk of design. Some of those methods are defined in the developer class, but some of them are defined in the junior developer class which inherits from developer. Looks like this. And if you take a look at the methods that are defined in developer versus junior developer, you will find that they reflect an important guideline for what you should share with your junior dev and what you should let them figure out on their own. You fill in anything unusual or unique to your application and they fill in pretty much everything else. But I wanna make it clear that this is not a passive process by any means. The developer class, like you see, is defining the order and the framework for gaining the knowledge. They're just not filling in all the blanks. So let's drill down a little bit deeper. Never assume knowledge on the part of the noob to get a sense of the person's initial level maybe on their first day. You wanna quiz them a bit, but the language you use here is really important. You don't wanna ask something like do you understand nested resources? Instead ask how do nested resources work? Prompt an active response so that you start to get it back and forth and you can get a real sense of what their initial experience level is. If your noob doesn't know some fundamental things, have him go read about them. And if he has it covered, go ahead and start him on some simple assignments. Now, one thing that I think a lot of mentors forget in these early days is that their guidance shouldn't just be restricted to the technical realm, right? It's really important to introduce the team process and even tell your noob stuff like who on the team is working on what. That will help them when they have specific questions know who to go to later on. Because every minute that your noob spends wondering what they should do next or who they should talk to or if it's appropriate to ask this question is a minute wasted. And finally, be honest about your own limitations. If you're busy or you run out of patience, just let them know politely. And if you're confused, just go ahead and say so. That helps your noob get a frame of reference for what is actually confusing and what they just don't know enough about yet. Like, your noob might not even know that it's weird for logging statements to cause errors in production. So tell them that. Important, pair programming is critical at this stage. It's not optional. It's mandatory. And I think that's probably all I need to say about that. So phase one for noobs. Obviously, you need to be acquiring knowledge at this point. But the question is, how do you get the most bang for your buck? So the next thing that I'm going to tell you, if you're not familiar with it yet, it's really going to change your life. It's the single most important step you can take in going from being a passively smart person to a brilliant person. And this is what it is. Metacognition. Metacognition is your brain's skeleton key. I know the marketing is really bad. It sounds like kind of a scary word, right? But all it is is very active control over the processes involved in your learning. I like to refer to it as tightening the feedback loop with yourself because the idea is you want to develop a program that gets deeper and deeper and more specific as you practice it until it's on the level of like seconds, like a seconds long feedback loop. Like, did I just understand that? Am I going to go back and read it again? What do I do next? At this stage of the journey, you don't need to worry too much about the specifics of what programming knowledge you should gain. You can let somebody else worry about that for you. But the most important thing you can do for yourself now or really at any time in your life is develop conscious metacognitive skills. Metacognitive techniques can be divided broadly into three categories. There's planning and approach, monitoring the process as it goes along, and then evaluating the outcome. Now you'll notice as I go through this talk that a pretty large fraction of the tips for noobs fall under this umbrella. And there are a lot of different techniques that you can use. I recommend you research it on your own. But I'm just going to share a few that I have found helpful in my own experience. Set goals and expectations. And I like this Eisenhower quote. Plans are useless, but planning is indispensable. Because it doesn't matter if your goals change or your expectations come crashing down in the middle of the process. The point is that you might not even notice that things are going wrong unless you had an initial expectation to compare to. Now people do tend to do this for really big things, like something expensive, like starting a developer boot camp, or something risky, like an acquisition. But people overlook the fact that this is really useful for small things, too. It could be something as small as reading a book or checking out the documentation for a gem that you're about to use. The point is that you make the goal clear to yourself at the beginning so that as you're going through it, you can very quickly and easily check in with yourself about whether you're getting what you need out of the process. And to that end, it's best if you actually write the goal down, because you crystallize it explicitly in your mind. And then it makes it easier to go back and evaluate at the end. Empower yourself with curiosity. So new developers, especially if they're working in a large code base for the first time, they can often fall into the trap of feeling powerless against the code in front of them. Sometimes it's because they just don't know where to start. Or sometimes it's because they're making a lot of progress and suddenly they run up against a totally arcane error message. And it's important in the face of this kind of confusion to start out very early, reframing it in your mind as an opportunity for exploration and play. For me, hacker culture has been a really important inspiration in this regard. And I have noticed that there's a trend, particularly in the bootcamp community, to use the term hacking to refer to any kind of programming, especially programming done quickly. And I think that habit needs to be dialed back. Because if you occlude the definition of the term hacking, you're missing out on what it really means, which is something very specific and very, very useful. So obviously, everybody's going to have a little bit of their own take on the hacker mentality. But I like this one from Wallace Wang's book, Steal This Computer Book. He breaks it down into three phases. Stage one is curiosity. And at this stage, the hacker just wants to know everything about a system. He's not comfortable with just absorbing what's put in front of him. He wants to go and discover new possibilities on his own. Stage two, control. This is where the hacker gradually learns to control and manipulate the system through experimentation and play. And then stage three is conscious intent. Now that the hacker understands the system, he can set a goal for himself. And he will pursue it with relentless determination until he achieves it. That phrase, relentless determination, that's straight from the book. And I think it's really interesting that relentless determination doesn't come into it until stage three. Because the first two stages aren't about brute-forcing the work. They're about approaching it with a sense of joy and fun. Another thing I really like about this definition is that it has absolutely nothing to do with computers, right? So lockpicking is hacking. Social engineering is hacking. But spending the weekend guzzling free pizza and Red Bull while you bang out an app that helps people find cupcakes isn't hacking, which brings me to the next pitfall. Going mad with false power. A lot of new developers get wrapped up in the thrill of just writing a bunch of code. They're like, oh, I use Rails to build a blog in 15 minutes. I'm an awesome developer. No. That's one of the things we love about Rails. It lets us get a lot done without necessarily having a ton of deep technical knowledge, and it saves us from ourselves a lot of the time. But it can distract from the importance of thinking deeply and critically about code. So that's why if you're a new developer, even if you're not specifically interested in information security, I think it's still important to have your own version of the hacker mentality in mind. You don't ever want to let yourself feel powerless against the code in front of you, but at the same time, don't get swept away with the excitement of awesome tools. Having a mentality that leads you with curiosity and play will help you balance between these two extremes. Now we're going to get real specific. Memory palaces. So this is a neat trick that I've started to practice lately. It is an effective technique for encoding information into long-term memory. How effective is it? Well, it's been around for thousands of years. Cicero described it in his book, Day Oratory. So that says something about how useful it is. And how does it work? Well, I think the best way to explain is by way of examples. So let's say you wanted to memorize some handy array methods in Ruby. You start by imagining your childhood home. There's probably a common path you would have taken through your childhood home, like maybe from the front door through the living room, up the stairs, and into your bedroom. So imagine you open the front door to your childhood home, and you find that it's been co-opted as a set for a game show called Rotate That Array. And the host implores you to spin a wheel for the chance to win a brand new array. This is the Rotate method. But you're finding this whole game show thing really annoying, so you just yell drop array dot length, and the whole wheel disappears. That's the drop method. So you leave the host in tears over the ruins of his beautiful set, and you go up the stairs to your bedroom to find Romeo and Juliet in an embrace. But sadly, they're being pulled apart by two giant ampersands, and they're holding on to each other so tightly that as they're being pulled apart, their arms fall off, and all that's left in the end is a pile of arms. This somehow is the intersection method. But everything's quiet now, so you go to lie down in your bed, but you find that your mattress is a little bit lumpy, so you turn to it and you whisper Flatten, which is the Flatten method. So it works by imagining a familiar place and a walk through it. And you add imagery representing what it is you want to memorize. You have to make the images as weird and outrageous as possible so that the memory actually sticks with you. And the traditional way is to use a familiar place, but I think it's also pretty fun to try using an imaginary place that has physical characteristics that represent the concepts that you're trying to memorize. So either way, choose your own adventure. There we go. So that's all for the metacognitive techniques for this phase. There is one more thing I want to mention about phase one. There is one thing you can do, even if you have no experience at all that will immensely boost your usefulness to your team. And it's this. Use the product. You might work in something like payroll processing where that isn't really feasible, but to whatever extent you can find some way to use the product for something that actually means something to you. It's likely that a lot of people on your team don't do this, so doing it will give you special insight that other people on your team might not have, even if they're experienced programmers. So summary of phase one. As a mentor, provide a framework for skill acquisition without spoon feeding. Be honest about your own limitations and pair program. As a noob, metacognition, and some other stuff that is not as important as metacognition, because if you get one thing out of this talk, it should be that. Phase two, touring the swamp. So this phase, it's different from phase one in that in phase one, you might have felt like you were just groping blindly through a totally unfamiliar landscape. But in phase two, the path is clear and the stumbling blocks are pretty well defined. You can work independently on small things, but you still need guidance pretty often, and you usually have a rough idea of what to do next, less often how to do it for mentors. So this is a transitional period. It's difficult to rigidly define what needs to be done. You can't plan it out ahead of time, so the theme of it is improvisation. And just like in theatrical improvisation, there are guidelines you can follow to make sure that the scene progresses. What you should not do is simply assign whatever happens to come up. I mean, there's gonna be a well-defined set of work that your team has to do at any given time, but the art is in how you delegate it. It's just like how a good improv performer can take a really boring prompt and turn it into something funny and original. You can take whatever set of work your team is given and turn it into a program that actually helps your noobs learn. Here's your objective. Keep your noob's head just barely above the water. Kinda like how decorators add functionality to an object at runtime. You improvise to add new functionality to your noob. Pay attention to what your noob has worked on in favor assignments that are harder or dissimilar. And if you don't remember what your noob worked on, just go ahead and ask. It's better than guessing what'll be right for them. One way you can help your noob stay challenged is to train her to look at her code with a pessimistic eye. You wanna ask questions like what could go wrong? What assumptions have we made that might sometimes be false? What would a null input do? Does this open any attack vectors? There might be times when the only work you can assign to your noob is stuff that seems a little easy on the surface. And this, aside from being a critical skill for any developer to learn, is a great way to add depth and complexity to stuff that might otherwise have seemed too simple. Noobs, if you are not lucky enough to have a mentor who can help you with this, it is obviously something you can train yourself to do, but this is one that I think is better acquired with a little bit of guidance. So while you're staying aware of providing your noob with a valuable challenge, there's one thing you should never forget, encourage. This could be something as simple as just saying good work, but another really good way to encourage is to tell your noob when his code has been deployed, because this tells your noob that his work matters and it also helps to familiarize him with the workflow if you have a team that, you know, where your process is a significant gap of time between writing code and deploying it, like most teams are that way, but not everyone. But telling your noob when his code has been deployed tells him, no, your code is not just being swallowed by a dark void. Sometimes it can feel that way when you don't have much experience. So the next tip, this is difficult to apply gracefully, so please take it with a grain of salt, but don't let your noob be a wuss. There's a senior engineer on my team who if I ever say something like, oh, I can't review that PR, I don't understand it, he'll just be like, since when are you such a wuss? And I really need that, but it's difficult to apply unless you know that you're gonna come off as having good intentions, so be careful. Phase two for noobs. So you've been plugging along, you've been charging up your metacognitive skills, and now that you're a little more comfortable, we're gonna talk about your approach to code more specifically. Be a code entomologist. You're probably gonna be debugging a lot at this stage, so whenever you fix a bug, think about what it was that you got hung up on when you were trying to figure it out, and through that develop a taxonomy. You wanna generalize the bug you saw as part of a larger category, and then think to yourself, how could I have figured this out faster? Now I'm just gonna throw out a couple examples of bugs that are in my taxonomy. The stupid little thing, the errors in syntax or spelling. And what this smells like is complete understanding, but your code is just broken. Now this may sound obvious, but once I learned to step back and smell that this was what was going on, I haven't gotten deep into a rabbit hole with something like this ever since. The next is the framework gotcha. Component of the framework you're using works in a way you didn't expect, or maybe it worked that way in the last version. The principle here, it doesn't matter what your classifications are, it just matters that you come up with them yourself. You wanna notice when you're deep in a rabbit hole, take a step back and compare what you're seeing to previously encountered bugs. And part of that is just going back and thinking to yourself, where is my understanding actually lacking? Because I can say from experience that the top one, when I step back, smells completely different from the bottom one, right? Because I do know, like I can tell when my understanding is complete and when there's stuff that's missing. And if you follow that scent, it'll make it much quicker to debug. Have opinions, even if they're wrong. This is like an amped up version of clarifying the goal before you start a process, because the important part of the idea is you don't have to be right. Every opinion has an emotional component to it, but it shouldn't just include how you feel, it should also include what you think. Like if you're trying to develop an opinion about the testing framework that your team uses, it's not just like, is this framework awesome or lame? Is it easy to read and write? Is it expressive? When you're trying to do something new that you haven't done before, how easy is it to just guess the language that you need? Because the easier it is to guess the language, then probably the better written the framework is. This can be a tiring habit to develop, it's not easy. But if you train yourself to do it, you'll gain a much better understanding of the philosophy of the tools you use, and you'll be able to use them better. You will learn faster and you'll remember things longer because you have an emotional connection to the material. And finally, it also opens you up to great opportunities for conversations with people who know more than you. Because if you disagree with someone, they'll be interested in talking to you. On the note of being wrong, review others' code even if you don't feel qualified. Thoughtful exchanges are never a waste of time. And you shouldn't worry about senior devs not appreciating it because they do appreciate having their work critiqued as long as you come at it with good intentions. Finally, for this phase, I think it's important to find an independent project around this time. It's the ideal time to do this because you're not as inundated with responsibility as you will be in a few months. And a personal project is okay, but you're gonna have a much richer experience if you build something for your company or your team because you'll have potential collaborators. You'll be able to actually test it and get feedback. And because people come in to you and saying, hey, if you finished the thing you said you were gonna do, it's almost as good as having a deadline. Using the product, as I mentioned in phase one, can help you get ideas for this. But if you can't really come up with anything that's kind of dependent on the product, an internal tool is always a great option. For ideas, just think about what would help your team be more effective, faster, more knowledgeable, or maybe make it easier for them to communicate throughout the day. Phase two summary, as a mentor, your objective is to maintain the correct level of challenge and your tactics for that are to improvise and to add depth. And while you're doing it, don't forget to encourage. As the noob, catalog what you learn from bugs, invite opportunities to be wrong and start working on an independent project. Phase three, swimming free. You still have a lot to learn in this phase but you can work independently most of the time. Your progress is gonna be mostly self-driven here and this, I think, is the best indicator that you're in phase three. Pairing sessions feel more collaborative than instructive. So as a mentor, the question is, how do you help a noob get from phase two to phase three? So it will happen with enough time but I think the best and fastest way to do it is through a rite of passage. In other words, an initiation. Initiation is one of the grand narratives of human existence. It doesn't matter who you are, you are familiar with some version of it. It's present in every mystical tradition and even in a lot of mundane traditions. Like Christians call it Dark Knight of the Soul. For Native Americans, it's a vision quest and for Frat guys, it's Pledge Week but the theme, the story is always the same. It's a difficult ordeal that when you pass it provides access to a new and higher state of existence. Initiation rituals do run the gamut in form but there's one that I think really perfectly captures the spirit of being a mentor. And this one comes from Joseph Campbell. So in the tribes of New Guinea, the young boys are raised to live in fear of these masks that the older men wear during their rituals. They see these as the gods, quite literally. And once the boy hits puberty, starts to get a little out of control too much to handle, the men, the older men one night they put on their masks and they go and they kidnap the boy, they take him to the woods. He's petrified, he thinks he's been taken away by the gods. And then he's forced to fight one of them, one of these men in these masks that he's feared all his life. So the fight, you know, he doesn't go easy on him but in the end the mentor does let him win. And then here's the really important point. He hands him the mask and he says, here you are, a representative now of the society that shaped you. So how do you be a good mentor? I think you have to fight your noob, let him win and then hand him the mask, right? And by fight your noob I don't mean be a jerk so let's get a little more specific. What makes an initiation? Well the first part is that it wouldn't be trivial for someone at a higher level. You have to set up a meaty challenge but at the same time it should be achievable for a noob. That's part of letting him win because every initiation needs to end in a victory or it's not really an initiation at all. Next, some initiations are solitary like the vision quest but one of the reasons I like the New Guinea ritual as an example is that it's not solitary. It's face to face and I think that's what you're looking for here. The mentor should have a very active role in the process. And finally it provides demonstrable and preferably quantifiable value to the team or the company. This to me is part of handing over the mask because it's saying you now have real responsibility and you've delivered demonstrable value back into the community. Now you are representative of the team that helped shape you. So by way of example I'm gonna talk a little bit about my right of passage. You might be familiar with the famous saying there are only two hard things in computer science, cash and validation and naming things. My right of passage involved naming cash keys so that they could be invalidated. The quote's not true by the way, there are a lot of hard things in computer science but let's stick with it for now. I'm gonna go pretty fast here because the point is just to show the complexity but if you are interested in more of the technical details feel free to find me after the talk. So our architect noticed that Redis was becoming a performance bottleneck in some cases and he wanted to switch our Rails caching over to Memcache D. Memcache D is faster and among its many optimizations it does not allow wild card matching. This was the way we used to invalidate our cache but now that asterisk was bad. So we had to get rid of it. What I needed to do was build predictable keys based on a set of attributes and each of these attributes could have a set of potential values, right? Sort type, request type, account ID, there were a few others. So when the cache is invalidated for a given account we had to build all possible keys and delete each one even if they didn't necessarily exist. That might seem a little crazy but of course it's much faster than a wild card match which forces a sequential search over every key value pair in the store. But then what if we added a new sort type later, right? The code shouldn't have to change so we can't hard code those potential values. So what do we do with them? Well, we store them in Redis. I thought we were trying to reduce the load on Redis while we are. So we had to add a thread safe key value cache in the controller. If the value existed in the class level cache then it was already in Redis so we didn't need to store it again and test all of this. So this was really difficult, took about three weeks, ended up being a 900 line pull request and finished it, cheered myself on for a little bit, forgot about it after a few days but then a week or two later our architect sent out this email where he showed before the deploy of those changes that was our response time after it went down significantly. So this was really like what sealed the deal for me and making me feel like I had really contributed and I was like a real engineer now. One more note on this process. I don't think that this was, I don't think this was set up for me intentionally or anything but if you do set up something like this intentionally for your noob, I don't think you should tell them it's an initiation. Part of why this process helped me so much was that everybody on my team really showed that they believed in me by treating me pretty much like a regular engineer. After the initiation, keep up the same communication style as before but a lot more hands off. A lot of the responsibility is off you now which we're gonna talk about in phase three for the noob but one thing you should do is introduce the noob to new ideas and if there are particular things she's interested in find resources and elaborate on them and help her kindle that interest. Phase three for noobs. Keep working on your independent project or start one if you haven't already. Start to code in your spare time if you haven't yet. If you've gotten to this level you might be surprised to find how easy it is to actually just go home after a day of work and start coding. It's a lot more difficult than phase one but by the time you get to here it won't be that hard. This is the routine that works for me. Directly after getting home whatever time of the day that is 15 to 20 minutes of meditation and then 45 minutes of creative time. Cap it at that unless I feel like I'm really on a roll. Creative time can be writing or coding or drawing but it can't be reading because the purpose of this is to shift your mode from a mode of consumption to a mode of creation. Read texts that are over your head seriously over your head stop reading pooter. And I just feel like I have to put in a disclaimer because I love Sandy and pooter is an awesome book but at this point you should have read pooter two months ago have those principles hardwired into your head and you need to read stuff that threatens to make your head pop off, right? I've actually found it not particularly easy to find challenging texts in the Ruby and Rails realm. A lot of stuff has like beginner to advanced beginners chunks punctuated by a few things you don't know but I do have a few examples that I think are really good resources for this kind of head twisting stuff. The first one is Crafting Rails Applications by Jose Velim, he's on the Rails core team and this book is about sort of recipes for things you can do with Rails that you probably wouldn't do on a daily basis and as he goes through the book you get a pretty good introduction to Rails internals too. Next is Ruby under a microscope. I haven't actually read this book but I've started it about 10 times which I think is a testament to how difficult it is. It goes deeper into the C implementation of Ruby and how it actually works. And finally, Tenderlove's blog is great. Tenderlove is famous in the community for being so damn funny but people overlook what a good programmer he is and there's a lot of stuff on his blog that is really sophisticated and he's also very, very good at explaining it so keep up with this one. Go to conferences, especially hacker conferences but that's my bias take. Really I think you should try some events that are outside the scope of what you do at work. And on that note, learn a new language especially one in an unfamiliar paradigm. I think that C or a purely functional language are good choices at this point because you can just go learn Python later. It's not gonna be that hard. Teach yourself design patterns. Design patterns are the most important thing they don't teach you in boot camp, right? They're also one of the things that separates a CS undergrad from a boot camp grad so if you don't know them yet, learn them. They're a very high return on investment for your time because they are easy to understand. You can probably walk into work and start using them tomorrow and they just make you a better person on the whole. I recommend this book, Headfirst Design Patterns. It might be a little confusing if you don't know Java but their approach is so good that it's totally worth it and by the way their approach is based heavily on metacognition so there you go. Finally, take everything that you've learned and go be a mentor to somebody else. Phase three summary. Mentor, set up an initiation once that's over broaden the scope. Noob, invite further initiations, learn design patterns and then be a mentor. So what did we learn? Here's a pro tip if you didn't listen to any other words in this talk you only need to get what's on this slide. In the first stage, metacognition. I don't care if you forget all the specific techniques I mentioned, if you go home and you start to develop a conscious metacognitive program for yourself that then you've gotten everything I wanted you to get out of this talk. Mentor at stage one, open all lines of communication with your noob, take an active role in determining his level of knowledge and be honest about your own limitations. In the next phase, the noob can apply their metacognitive skills to the challenges that the mentor poses to them and finally when the mentor feels the noob is ready set up an initiation once that's over it's on the noob to invite new challenges on her own. So in closing, as your mentor of the moment I want to assign a little bit of homework to be handed in any time before the end of your life but preferably like tomorrow. The process of learning and the process of teaching are deeply intertwined. So please take a moment, a few moments to meditate on this very important quote and see where it takes you. A true initiation never ends. Robert Anton Wilson, thank you. This is my references list. It's not an MLA format, sorry. This is really great, thank you. Do you have any, like definitely don't do this kind of things if you're a mentor or if you're a noob, like common mistakes people make? I mentioned some of it. Obviously part of it as a new developer is don't feel powerless, don't feel afraid to ask questions is a big one. And as a mentor just don't ignore, don't let it go. I think that's the important thing. Actually I would say maybe the one thing is don't let your noob be a wuss. I know that's hard to apply but really don't let your noob be a wuss. Yeah, I would say nothing that I didn't cover in the talk. Yeah, you mentioned conferences. I was wondering what were some conferences that you as a noob found valuable and what about them did you find valuable? So this summer I went to Hope which is a hacker conference in New York and I went to DEF CON which is the largest hacker conference in the world. It's like 10,000 to 13,000 people in Las Vegas. I know hardly anything about information security yet so I was just going to these to sort of like break open my head and see what would happen. And what I found really valuable about them is the extent to which the people there own the technology that they work with and how they're totally unsatisfied to leave anything as a black box. There's also just an extraordinary streak of self-empowerment in that community that I find hugely inspiring and I think is something that you can apply to any aspect of your life. Others, I mean yeah, so the hacker conferences were big for me. Those are the ones that I've been to that are not in the realm of Ruby. I went to RailsConf 2 and it was okay. Hey, great job. I've got a sort of unorthodox question because I think right now a lot of people talk about noobs and imposter syndrome, right? Feeling like they don't belong but the beginners that I encounter that I experienced the most are very successful beginners and they're sort of like king of the noobs and so they tend to be filled with all this false confidence while they talk about their imposter syndrome and I don't know how to talk to them about how they aren't quite the hotshot that they think they are without just totally bursting their bubble and destroying their entire ego. So can you please do that for me? I would say don't tell them, show them. Have them go read. Have them go read the source code of a very complex gem, something like that. Tell them like hey, or you could even say like, hey you know, you're pretty good. Why don't you learn C? Like can you go learn C for me? You have something like that. Just up the scale for them. A lot of the reason that new people, and this is interesting because when I was first like interviewing for positions when I came out of General Assembly there was this one guy who was interviewing people who was hilarious, he was so brutally honest and he'd ask me a question when I was answering he'd go staring me in the face like literally like that and he was like the problem with all of you is that you have way too much false confidence. So yeah, that's a common problem. But I think the best way is to show them the scope of what they're really dealing with. I mean you can do that in any number of possible ways but I think just recommending new reading resources and having them read source code that's very advanced. You don't have to tell them straight up. You don't have to, they'll figure it out. All right, that's our time for now. So thank you again, Ellis.