 have ponies, so let's do it. My name is Cary Miller. I'm a heavy metal software developer for Living Social. I like to say I'm heavy metal software developer because my title is Lead Software Development Engineer, which means I think very weighty thoughts and I can protect you from x-rays. Also we're hiring. I think I have to say that contractually. Before I was a lead engineer at Living Social, I was actually a teacher at Ada Developers Academy. Anybody besides these three or four people know about Ada Developers Academy? Okay, it's not a bad crowd. Okay. Ada Developers Academy, let me see if I can get this, is a 12 month educational program for women who are transitioning into STEM, specifically with a six month classroom training program educating them on Ruby and Rails and modern web development followed by a six month internship at a sponsoring company, which hopefully then turns into a job offer at the end of that time. Did I nail it? Anyone time now? Was that an elevator pitch? Yes. Yeah. And the wonderful thing I love about this program is unlike other boot camp programs, we actually don't even charge, we don't charge the students. We actually charge the companies. And in fact, the cost is even less than zero because all the students receive a monthly stipend for as long as they're actually in the program. So it kind of is a really, really interesting model. We just graduated 15, our first cohort, a few weeks ago and we're starting a new cohort of 24 about two months ago, kind of asynchronously there. And so to them, you know, I'd like to say, hey, welcome, welcome, you were much loved. Does anybody not like ponies? Man, I'm sorry. Your day just got ruined. But seriously, welcome to the industry and welcome to RubyConf. One of the things I do love about the program, especially is because we get to work with the students for such a long period of time, more than just like nine weeks in and out. We really get to see people go from maybe a class or two in college, they worked on a side project once or did a Rails bridge up to their fully fledged software developers. And part of that is understanding what a career in software development looks like and changing people's story from I'm a student or I'm learning to embracing and defining themselves as a software developer and using that language to talk about themselves. And getting to see a lot of women sort of work through the same sorts of struggles and infusions and frustrations, I started to see a lot of patterns. Like a good scientist, I decided the best way to explore any sort of sociological phenomenon is to take a survey and do a questionnaire. And so I posted a little questionnaire about, hey, what should I tell these women who are in this program? What do you wish you could go back in time in a metaphorical DeLorean and tell past you about software development? And I got over 150 responses, tons of great people and quotes and some people were angry and typing out all the horrible things about their current job and some people were super happy. But there were a lot of common things. And so I picked five that kind of appealed to me, kind of resonated with my own experiences and that's what I'm going to talk about today. So without further ado, let's get started. So one thing we don't talk about in software very often is that this stuff is supposed to be hard. It is a very, very difficult discipline. There are shortcuts and metaphors that we use to try to wrap our brains around it, but we're not talking, it doesn't like learning another spoken language. You learn another spoken language, you're trying to communicate with another human and you can assume that there's some commonality about the human experience that we love and we're afraid and we're sad and we're angry and we're happy and we rejoice in some things and some things terrify us, but computers don't care. They're like, right, computers are super dumb things that only do exactly what we tell them to do. And so as we're learning to do that, the learning curve really comes into play and sort of understanding where we are. So we have to think abstractly about what our process of learning is. And so has everybody kind of seen a learning curve graph like this? Yeah? Like this is a super abstract way of thinking about learning. Because when you're actually, we're standing off to the side and watching somebody else's path on the learning curve, right? But when you're actually on the learning curve, it feels so bloody horrible. It's really a matter of perspective on where we are. We can't really tell where on that curve we necessarily are. And so when you're standing off to the side and you're watching someone struggle with something, you're like, you want to tell them just like one more semicolon. Just add another semicolon and it'll all work, I promise. But you kind of have to hold back a little bit. It's hard to convince people that you're right at the edge of the cliff. Just one more pull and you're over the top. It's hard for people instinctually to understand that. And part of that is that some of the things that are really difficult about software that give you a hard time are things that other people seem to do just super easy. I struggled for a long time to really understand concurrency when other people just seem like, oh, yeah, concurrency threads, forks, blah, blah, blah. And that's just that. For me, that's something that I didn't get. And it's not a deficiency in who I am or my abilities as a software developer. But it was really just, we had a different set of experiences that we were both bringing to that problem. And their experiences were enabling them to think differently about the problem than I was. And it made it easier for them. And conversely, there are things that I'm really, really good at that other people just don't seem to get. And I have a hard time sometimes understanding why somebody doesn't understand a piece of technology that I get. It makes a lot of sense to me. I do a lot of work with asynchronous processes. That's really easy for me to grok. It's not everybody's cup of tea, though. But this is sometimes a blocker, especially for people who are learning things. And even those of us who are experienced, when we're used to having easy successes and all of a sudden we've come across something that's really hard, I'm learning closure right now. Any other closureistas? Closure writers? I don't know. A couple of people who don't really want to admit to it at a Ruby conference. I understand. Well, the problem is, is that a lot of times we had this expectation about who we're supposed to be as hackers. We're supposed to, like, jack in and hack the planet, right? I'm like, oh, I'm hacking the Gibson. And we're supposed to all get this reference from a 1980s movie starring Angelina Jolie. So much fun. So much fun. If you ever want a completely horrible example of what it's like to be a software developer to show your family, show them hackers and say, yeah, that's me. So, I mean, sometimes it's hard just to get, like, hello world to print out sometimes in some things, right? You have to set the whole tool chain and the compiler and then LLVM and, like, oh, there's a new X code out in the middle of it and it breaks everything and that's just my world, though. So, you know, how can we, how can we possibly live up to this image that we have or what it means to be a hacker, right? And we have to remember that, you know, if this stuff was easy, everyone would do it. Every single person in the world would jump at the chance to do what we do and, quite frankly, get paid what we get paid. And so just keep that in mind that this stuff is supposed to be hard and part of the compensation that we get for it and the freedoms that we get through employment, through, you know, flexible time off, or getting to go to conferences and getting two kinds of beer. You know, most people have to suffer through one kind of beer, you know. And come on, come on, don't get upset when you run out. So, most people who, if you see them and everything is going really, really easy for them, they're just really good at pretending. They're good at not getting frustrated, right? I'd like to say that most of the time, we spend most of our time working in the darkness at the very edge of our experience. Because this is my life every single day. Does anyone recognize this? Anyone not recognize this? I don't want to assume. I don't know who's in the room, right? So this is a stack trace from something that blew up on me. And whenever I see these come up, I feel like my computer is just, like, taunting me. She's just like, ah, you suck. And you know what that makes me feel like? It makes me feel very sad, very, very sad. You know, and I'll pour over it, and I try to find the problem, right? And you find the problem, and you're like, sweet, I fixed it. Reload. Same error. What the hell? So I look some more, and I'm like, oh, I forgot that other semicolon. Oh, JavaScript. And so you fix that, right? And it still doesn't work. And then you go, oh, you pour over it, and you find this really subtle mistake, right? It's a super subtle, like, race condition that you hadn't considered, and you fix that. It still gives you the error. And then you realize you didn't degrade or de-migrate. That's my daily. That's probably yours, too. So whenever I'm helping a student, and like MRI, like, barfs up one of these stack traces, you know? Like, to them, it's magic, right? That I can look at a stack trace, and I'm like, oh, yeah, it's such and such a thing, right? Or it's, you know, you missed a comma or something. But for them, it's like, look at the friggin' matrix, right? It's just like, boo. And sometimes I feel like that character in the matrix who's like, yeah, I don't even see it anymore. That's a hamburger, and that's a, you know, I don't remember the quote, but. So one of the things I always try to emphasize to people, right, is like, do yourself a favor and like, read the error. I'm actually working on a gem for people just in funsies to take the output of the error, that part that says, like, you know, could not do this thing, and just like, have it pipe that to the text to speech on my Mac. So it actually tells me exactly what the problem is instead of like, so I don't see this panic wall of text like flying at my face. Because an error like this is a computer's way of saying, like, help, I need an adult over here. Please help me. Somebody bail me out of this problem. And it's really important to remember that one of the things that we have to keep in mind is that we are the adult in this relationship, right? The computer is a dumb, totally logical child, and all it does is exactly what we tell it. It's the most obedient child ever. You know, if we tell it to subtract zero from zero, it will try to do it. If we try to divide it by something like zero, it will try to do it. But then it will complain because it doesn't understand. It doesn't, it's not proactive enough to understand that we're asking it to do something completely illogical. So don't feel helpless, because you're gonna feel like this every single day otherwise. Because you're gonna write bad code. I guarantee. And it's not because you're dumb. It's not because you're not capable. It's not because you're not experienced. Even the most experienced people write bugs all day long. And that's why, you know, we all have jobs, fixing and maintaining stuff. The thing is, what do you do when you've broken everything? What's the next step? And it's your reaction to that, that you really are, that's what you're in control of. You're not in control of the fact that you're going to make mistakes. You're not in control of many, many things in this, but you are in control of how you address problems and what your attitude towards it is. And you can panic when you see the wall of text fly at you or the emails and the pagers start going off. Or you can say, hey, there's something wrong and we're gonna fix it. Because you have to have faith. You have to have faith that everything we do here can be understood that software was written by humans who thought this up, right? Computers just didn't fall out of the sky, right? And we washed up on the shore and then we're like, oh, computers, oh. We invented these, we humans. People from the previous generation and the generation before that, yes, some of them were very, very smart but most of them weren't. Most of them were just as smart as you or I and they came up with these things and they worked with them and so can we. We're all capable of this. What's really important in addition to having the faith that you can do that is the courage to take the step towards doing that, right? That courage is faith in action in many ways, right? So you have to be able to admit that sometimes I'm gonna look dumb and I'm gonna ask dumb questions and I'm gonna look foolish but that's just pride. You know, and other people, we don't see other people looking foolish or asking dumb questions but they do, they do. We have to accept that, that we're gonna do it, that they're gonna do it and have that sort of humility and compassion for each other if you'll pardon the touchy-feely for a moment. We have to have that sort of compassion for each other that we're all just human and that we're in this together. That's one. So you do you, which is kind of a nice way of saying be yourself. But every conference I go to, including this one, at some point, a speaker gets up on stage and makes an assumption about who Rubyists are and what we like and what we do. And I'm pretty sure that none of these things are true for everybody in this room. Does anybody fit all of this? Say, who fits like three? Oh, well, okay, you like JavaScript? Man. Yeah, I'm three of the four. Anybody just two? Couple people? See me afterwards, you get a prize. It's a key cord for your EMAC setup. So it's really important that you sort of question these assumptions. It's not just enough to sort of be yourself and be wacky and wear rainbows, right? You have to also sort of like look at the culture that you live in and the people that you surround yourselves with and the assumptions that you make about the tools that we all use and who we are, what our identities are. We waste a lot of time trying to figure out where we are and the hierarchy of other nerds. There's a lot of like, oh yeah, well I did the dial up with the acoustic coupler and like, oh, I used to work on a punch card machine, like all that kind of business, it's whatever. That's just people who are trying to figure each other out because they're human and humans we tend to be prone to hierarchical social interactions that way and it's a waste of time ultimately because it doesn't matter, it doesn't matter. Things are moving forwards too fast. We've worried about what other people did in the past and it gives you a certain amount of perspective sometimes but don't fall into that trap, don't fall into that game and watch for yourself and like not pushing other people away by those games that you wanna play to figure out where you are, just be confident that you are where you are because there's absolutely zero connection between your ability to quote Monty Python and your ability to set up a server. There is no correlation whatsoever between the length of your beard or the tightness of your pants to your ability to use node. Actually, now that I think about it, love you node, love you node. But seriously, there really isn't any connection to your ability to fit into this community of people and your ability to do the work and so respect those differences and respect people for the work that they do and celebrate those sorts of differences because they're bringing vitality to our community, they're making us a much more interesting place in less of these assumptions about what the tools and the processes that we should be using and they bring in the next potential person who's going to disrupt our community and things that we do for the better. Like if we discriminate against DHH for, he says whoopsie all the time, well then that's kind of ridiculous, we wouldn't have had rails. Anyway, walk your own path. Because it's really important that you are on a path and you're always going to be constantly moving. Sandy Metz always says that you're never going to know less than you do right now. I'm actually a little bit more pessimistic, I've always said I'm never dumber than I will be, I am yesterday. But basically, you make the best choice you can at the moment that you do with the resources and tools you have at hand and so you have to sort of give other people that latitude that you don't understand why they wrote this crappy code this way, but they did it for a reason, right? They made a conscious choice. Nobody sets out and says, I'm gonna write the worst code possible. Actually, well you write Pearl though. JK, what's up? Sorry folks, sorry conflicts. So ultimately, be nice to others but be nice to yourself here, okay? Don't beat yourself up, if you don't know something, you're supposed to make mistakes, it always comes back to this. You're on a journey, so be nice to yourself and be nice to future you, right? Code that's easy to understand, easy to change, all those good things that we're trying for, make them happen for yourself. It's also really important to take care of your personal health. We have, like I said, this hacker ethos that we all drink surge and eat cheetahs and stay up till 2 a.m. And although that's a little bit ridiculous and we all kind of know that, right? We still live with that sort of stereotype from the larger culture that we work in. Sometimes not just the wide culture of our societies as we walk around town and say, yeah, I'm a computer developer. But like the people we directly work with who don't do our work, accountants, business people, sales folks, they have certain assumptions about who we are based on the larger cultural dynamic and that can be a struggle sometimes. So you wanna take care of yourself and your body and your mind and your heart. We do a lot of sitting around programming and there's a lot of people making the change to standing desks for health. Go for walks, do these sorts of things. It doesn't, you don't have to buy an exercise bike and set up your laptop and be programming when you're on the exercise bike or anything like that. But just pay attention to the lifestyle habits that you're making and how they affect your body and your mind, your ability to do what is effectively very difficult mental work. For me, I have a lot of hobbies as a lot of people here know. Everyone here knows me. I do glass work. I went to cooking school for a while. I was a professional poker player. I played poker like two or three nights a week. I like to work on Vespas, like vintage engines and things like that. Just things that are like physical and mechanical and are not computerized, they're not virtual. And this is actually a huge boon to me personally because I'm a very tactile learner and I've learned that about myself over the years. And so being able to take an engine apart and think critically about it and put it back together again has directly translated into how I look at code because I can look at it like an engine or like an electrical circuit. And my understanding of how code gets refactured feels to different parts of my brain the same way that glass feels as it melts and solidifies and cracks under different temperatures. And I wouldn't have that understanding, that very intuitive understanding if I wasn't doing things that was engaging different parts of my entire limbic system, my brain and my heart, getting my hands involved with things. And so I encourage people always to sort of like, go get a hobby, do something else, meet new people that aren't also nerds who work on software so that you can see how other groups and populations of people deal with their problems and their interpersonal struggles. And you'll bring a lot back to the job and that actually improves your higher ability in the long run. Excuse me. So we've talked a lot about imposter syndrome the last year and a half. I think I feel like it's been a constant refrain. And everybody seems to feel this to some degree. I don't know if it's a little bit of selection bias for who talks about it or selection bias like people who tend to be have a little bit more of imposter syndrome tend to gravitate towards software development. But everybody kind of feels this, right? And we don't really know what we're doing but I love this quote. If you're hired for the job, you could do it, right? Like if you struggle and you get through like a rigorous interview process and they offer to pay you money, you can do this job, right? And if you can't, we'll take the money, right? Like don't worry about it. Don't doubt yourself. It's easy to say like, oh, don't doubt yourself. You're really good. But really, if you have done this professionally, you can do the job. Like it's that simple for better or worse. So being yourself looks really different. Sometimes. Because it's tough to stand out in a crowd. I know a lot about standing out in a crowd. And I didn't like that for a long time. I used to wear a lot of black. And I would tell people, oh yeah, I wear blacks and grays because I used to be a stagehand. And I go to the Merc and like listen to sad music and blah, blah, blah. But that wasn't true. Oh, get a little weepy. No, I really didn't want to stand out. I'm six feet tall and I'm a little chubby. And I kind of stand out. I didn't like that. And I started wearing rainbow bandanas and then people were like, hey, you seem like a fun person because you wear rainbow bandanas. That's pretty cool. So I was like, you know, I'm gonna stand out. I'm gonna stand out. I'm gonna be fun. Because I really like talking to people. I really like people. So I embrace that because here's gonna hate, right? You can't, you gotta deal with it. So you're gonna encounter people that are like, oh, you don't know what the RFC 1103 for email is? You know, people, come on, come on. Don't worry about that stuff. You do what you have to do and keep pushing forward. Let the haters hate. There's no magic whatsoever to what we do. Not a drop of it. It seems like magic, but there's none whatsoever. Has anyone seen this kind of graph before? I first encountered this in seventh grade, IFL, Introduction to Foreign Language. Someone was trying to explain to me why I couldn't learn French and Spanish at the same time. I was very ambitious. I still am. We started out with unconscious and competence where we just simply don't know what we don't know. We know nothing. And then we move, we become more conscious of what we don't know because we start learning things and we realize there's this huge, huge world out there that we don't know. And then as we gain more competence, we're still aware of what we know, but we start to identify these big regions of things and we're aware now of what we don't know very clearly and we understand where those boundaries are. And then finally, we finally move into this unconscious competence. This idea that like, if you're a driver is a common example where you can drive for hours and not even realize you're driving because you're just doing it subconsciously almost. You're so competent that your brain, you don't have to use the higher functions to be aware of what you're doing. And software is a little bit like that sometimes, but it's not really in a lot of ways. How many people are math majors? I always liked to do this. How many math majors? People who did math, like a minor, anything like that? Well, compsci, CS degrees. Everybody else doesn't have a CS degree, okay? That's about the normal split. Like Ruby is a weird community, right? It's about 50-50. People who came through math or computer science and everyone else is like artists and crazy hippies and a few musicians. And that's so cool, that's so cool, right? But we don't do a really good job about having different ways of explaining how software is. We don't teach it very, very well. So I'd like to give you an example of what would happen if we taught math the same way we teach software. Let's imagine we have a pony. Everyone agree this is one pony? Now I give you another pony. We have two ponies. One plus one pony equals two ponies. One plus one equals two. Does everyone agree that is a true fact? Great, we'll do this exercise for homework. This is just a simple extension of what we've already done, folks. We don't teach math this way, but pick up a programming book, man. It's like, here's how you do Hello World. Here's how you do a loop. Here's an if, else, conditional. Go make rails. Have you ever seen this chart? The Rails competency chart? This is amazing. It's so big, I can't even fit on this slide so you can read it. Everything on the left side is the generic stuff you quote unquote have to know as a web developer or someone who's writing web applications and everything on the right is all the competencies you need to be a Rails developer in addition to the stuff on the left. This is an amazing, amazing, insane amount of stuff to know. So if you only know a quarter of this, where are you on that original chart? Do you have conscious competence? Conscious uncompetence? Where are you on the learning curve of being a Rails developer? Is anybody 10 out of 10 on all these things? How do you rate yourself? Because I'll guarantee you there are huge chunks of this graph. I don't know. I really am not very good with, like JavaScript. But you know what the coolest thing is? You know the super cool thing about all this is? You do not have to learn it all at once. You don't have to do it. You don't have to know every single one of those branches in order to do a passable to good job at things because the entire internet is at our disposal to answer questions and we have a community of people that we can reach out to. Your job is to learn one thing on your first day and then learn a second thing and then a third thing and see the connections between those three things and then go on and learn a fourth thing. Nobody just sits down and reads a book and is an expert at all of this stuff. It takes time. So give yourself the time to understand and learn this stuff because it's all just code. There's no magic. There is nowhere where there is a black box where wires go in and wires come out and no one has ever looked in the box because it's magic. Oracle servers aside. There really is no magic. We can look at the source code or we can look at the APIs and it can all be reasoned about and understood and it feels like hell. It feels like climbing that cliff some days. Hello, close your docs. But you can do it. I swear to God you can do it. I did it and I'm, who am I? I'm not special. I'm no more special than anyone else in this room. So the underlying theme of all this sort of stuff, right, is that you need to learn how to learn. And the interesting thing about how we teach in America is we have a set of finish lines, right? We focus on graduation. You graduate from sixth grade which really isn't a graduation. I mean, come on, right? So now you go into junior high and that's a couple years and you graduate, right? You get another diploma except that's not really graduating, right? So now you go into high school and you graduate and it's so amazing, right? And there's valedictorian speeches and homecoming games but that's not the finish line either. So then you go into school or college. That's not it. Master's degree programs. There is no finish line. Education is a process. It is not a destination. And especially with the amount of stuff that you could learn and the amount of stuff that you can learn, education is an ongoing thing throughout your entire life. One of Leonardo da Vinci towards the end of his life wrote down something to the effect of I am upset about dying because there's so much left to learn. You can't know it all and so you have to pace yourself and understand how you learn and what your approach should be, what your relationship with discovery is. So imagine this is Ruby. This is everything you can ever learn about Ruby contained in this box, right? Will everyone agree that that is in fact everything you could learn about Ruby? So you learn one thing, right? You learn one thing. That's your first day. Maybe you went to a Rails bridge or you read the first chapter of learn Ruby the hard way. You learn one thing. And then you learn a few more things, right? Because you're Googling for how to do a loop and you come over and you, oh, innumerable. I saw a great talk at RubyConf 2014 about how to do innumerable, but a hurdle guy. And you start to see how these things relate to each other, right? They start to describe a shape. And so that shape is knowledge and wisdom is gonna get put together. And you can start to define the centrality of your knowledge, right? So things get pushed further. These boundaries get pushed further and further back to the darker corners of the thing you're trying to learn. And the interesting with software, right? Software works together with other pieces of software. That's where really interesting stuff starts to happen, right? So for like a Rails application, right? Like you start to learn things and there's some overlap between these. So now think about these. These are data points within a larger conceptual structure of software engineering, all those things you could learn. And so you're always gonna be pushing back against what the edge of what you know is, against that darkness and making less and less darkness and more and more light as you learn things. Because we have no idea what the next thing we're gonna have to learn is or what its relationship is, but it's gonna be outside of this box by definition. And so you need to be comfortable with working outside of the box of what you already know in those dark spaces. Things changing all the time. Two years ago, RubyConf Denver, when I gave one of my first conference talks, everybody was talking about how do we get Ruby into the enterprise environment? People were still talking about that. I haven't seen a talk like that this year. No one's talking about that anymore because we did it. We figured that thing out. But now we're talking about Ember and how do we do concurrency and static versus dynamic typing and should we use closure as elixir of the next hot thing? We're talking about new things. And so being able to learn, learning how to learn, how to acquire knowledge and really understand things quickly and integrate it and see where it falls on that map in relation to the other things that you know. So you can define regions of knowledge as a critical skill to acquire. And you can do it. I mean, you've done it. You're alive. Everyone here alive? Yeah, you're actually a pretty responsive audience. I really appreciate that. You're alive, you can acquire knowledge, right? You can learn. You are not fixed in stone forever. And so I actually wanna show you all something that I got really excited about last night. And I went on IRC and I was just like, oh my God, this is the best thing ever. This exists. For those in the back who can't read it, this is Friendship Is Magic Plus Plus. It is an imperative dynamically typed interpretive language that takes the form of the pony of your choice writing a letter to Princess Celestia. I wrote Hello World in it last night. This is a program, this runs. Who wants to write code like this? Okay, I got two, three people, all right, that's good. Look, I get it. Okay, Friendship Is Magic Plus Plus is not gonna be the hot new language, right? We're not gonna write some accounting software system in this. But what are we gonna write it in? Yeah, I thought so. Nobody wants to tell me, right? I feel exceptionally lucky, right? I learned Ruby, I won the jackpot lottery, right? Like this is awesome language with awesome people and I get to have fun and hang out with y'all and wear whatever I want, this is super cool. But we just got lucky, some of us. And so you have to kinda keep looking for your career to always be looking to acquire new skills cause you never know what direction things are gonna go. I'm learning closure at work. I'm also playing around with rust when no one's looking. Because I don't know what the next thing's gonna be but it's not always gonna be Ruby. And I hate that, I hate that this is an ephemeral moment in time, the awesomeness of Ruby. But if we're all awesome, we can then go to the next language and bring that awesomeness with us, like that's super cool. I like that, so let's do that. But I don't know where we're going, so I don't know. This is kind of a, let's all go there together but you all lead. And I guarantee you, unfortunately, that no matter who you are and no matter what you're struggling with, the likelihood that you are the first person to ever struggle with that, to ever cry and swear and bleed and flip a table, that's probably not true. You are almost never the first person. Every single time I hear about a cool new idea, like on Hacker News or something, like they're very exposed just like, oh, Dijkstra wrote about that in 73. But that seriously happens all the time, like every cool new language that comes along, someone says, oh yeah, they tried that in 78, or oh, there's a list version of that somewhere. We're all kind of like standing on the shoulders of giants. And we also stand in their shadow, right? The work that other people have done have got us to where we are today and it's our job now to step forward and lift the next group of people up. But we also stand in the shadow of those giants that they cast, they cast very long shadows because they did some really revolutionary stuff. That doesn't mean that we can't do revolutionary stuff. We have to understand what their influences are and where it comes from. Because we're not alone in this. For every single person who's tried to get JavaScript to work in IE6, man, I couldn't find a screenshot. I couldn't bear to put a screenshot of that error in this talk and I'm sorry. I really wish I had now. But you are not the first person to struggle with that horrible, horrible thing. So take some strength from that. So I hate to break it to you, but no matter who you are, there's someone out there who's exactly like you. Almost exactly like you. They might not look like you, but they probably think like you and struggle with the same things and have the same hopes and dreams and aspirations. And I can say this because I worked for five years in the Amazon Personalization Team, looking at what you people buy and you're all horrible people. I think I can say that. It's I'm no longer under contract. So it's kind of horrible, right? We all want to be special snowflakes, but oh my God, it's so great. It's so great because I can go find those people who have struggled with these same things and find out how they solve it, right? And like talk to them about what I struggle with and what I rejoice in. And so it's really important that we build communities around ourselves to be successful as developers, right? We're not supposed to be sitting up in our addicts programming all night. Go to meetups and things. Everyone says, go find a mentor. And I'm saying it again too, but you should find more than a mentor. You should find coaches. You should find people that give you good feedback that are able to give you advice about your career. Is this a good job offer? Are they paying me enough? Should I take this job? What should I be learning that I don't already know? What should I be working on so that I'll be employable next year? How can I help you? You wanna bring something to that table, not just take things away. And so building these communities, I think it's awesome. I think Ruby is an amazing thing that we've all done. I could say that's in front of this crowd, right? We all agree, right? Ruby's pretty good. It's not bad. Yeah, it's not bad. It's not bad. But where would we be without conferences and meetups and blog posts and Twitter, right? None of us would have, Ruby would not be where it is today. So be involved. Go share the learning. I love teaching. And I think teaching, if you're at all good at it at all, even if you're kind of bad at it, it's an amazing way to solidify what you know. Really interesting things happen in our brain when we teach. And I'd love to talk to other people about it. I won't take up any time without doing entire talks about what happens when we're teaching. But it supercharges our ability to retain knowledge. So go teach a class, go volunteer, go to Rails Bridge or Rails Girls. Clojure Bridge is really cool. Start a study group or a book club at your office. Like if you've always wanted to read SICP, but you never could bear to do it, find somebody else at your office who wants to do it or go online, just say, on Twitter, like, hey, I want to read Sandy Metz's book, but I don't want to do it alone. Who's with me? And they just do a Google Hangout every week or two and talk about it. Book clubs don't have to be just for Oprah. And this is why we tell people, like, write a blog post or do lightning talks, right? Because it's like, once you're involved in the community, it just, it gives you so much more confidence and your ability to feel good about strides you're making. You're able to start to track where you are in that graph of competence and confidence. So who here is going to sign up for a lightning talk? A bunch of people. If you want to do, if you didn't raise your hand and you want to do a lightning talk, come see me and I will help you. I will do anything. I will help vet your idea. I will help you with keynote. I will let you borrow my cool thing. Look at this, look. Super cool. It's got fresh batteries. Totally cool. I will totally help you do a lightning talk. If you want to do a blog post, I will edit your blog post, right? And this is a standing offer for anybody, forever. I'm there to help you just come see me. I'm pretty easy to find. Pay attention to people around you and how you communicate with them. Communication skills are super key. I've told a lot of people, like go take a relationship skills class. Like we just like, why would I want to learn how to date? Like why is that important to my job? But it's not about that. It's about understanding other people and listening to their needs and desires and whatever. But I mean, as far as the pitch goes, but the actual content of it is understanding that other people have fears and hopes and dreams and goals and desires and things that they want to do. What do they want to accomplish, right? And taking a class on that is super great. Because we're making it up all the time and learning to understand other people and how they're making it up at the same time, like that's gold. So speaking of things being hard, you know there's hard problems in software, right? There's two hard problems. One of them happened to me. But seriously, this is actually a really, really critical thing that I wish someone had come to me, maybe myself in a DeLorean and said, get started. Don't wait. I fretted. I love telling this story. I fretted for about a year and a half and didn't get into Ruby because I couldn't get the MySQL gem to install correctly. Really? Really? Has anybody else done that? You ever like done something like that where you just, you put it off and you put it off because of something stupid and trivial like that? Yeah, a lot of people have. It's important to get started and just get in there and do things, right? It doesn't matter if it's silly and ridiculous. The act of doing makes you right, which is one of the tenets of the Done Manifesto, which is, came up with by Bree Pettis who's the CEO of MakerBot that made the cool 3D printers and his partner, Keo Stark, who wrote an awesome book called Don't Go Back to School. These are just three of the things that are on the Done Manifesto, but it's this idea of if you sit and fret all day long about being perfect, you're never gonna start. And you can never be perfect, so why worry about being perfect? Don't worry about the perfect framework. Don't worry about the perfect transport protocol, the perfect language, the perfect editor. Those are refinements. It's only through the act of doing that you become correct. Worrying and not getting started doesn't get you any closer to being done. Okay, so that was a lot. There's a lot of ponies. It's a lot of things. I'm gonna just kind of sum up here because you really shouldn't be afraid of things that scare you. The five things that I wish that I knew, that this is supposed to be hard. There's a reason we're well compensated for it. There's a reason why we're all a little bit crazy. It's hard. We're not unusual because we find it hard. Be yourself. You do you. Whatever it is, don't worry about other people's perceptions about your skills and abilities and so much as it means a thing. Your ability to fit in is zero correlation to your ability to do this job. There's absolutely no magic in what we do. It is all just code that we can think about, that we can reason about, that we can write blog posts about and someone could explain to us. We're very capable intelligent apes using tools made by other apes. Learn how to learn. Take some time to understand how you approach new things and what your reactions are and how you take them in and retain them best. Find your communities and if you can't find that community, build that community. There's this really, there's a guy up in Chilliwack BC who didn't want to drive the two hours every week to Vancouver BC to go to their local Ruby Meetup so he started his own. Does anybody know about Chilliwack BC? A couple of people from Seattle I think. Yeah, it's a nothing little town. It's like 5,000 people. But he found one other person who did Ruby and they get together every week at a local community center and they do Ruby. And those two people became three, became four and they've got, I think he said like six or eight people. He built his own community and I think that's an awesome story. And finally, number six, go and get started. Go today. When you leave here and you go home, if you are not excited to do this thing, get excited to do it because this is an awesome job and we deserve it because we're putting in the time and the effort in making this happen. Go do it. Thank you.