 Okay, so I'm Pamela Vickers. I hope you all are having a really great time at RailsConf, I know I am. Do you all remember when this article was just all in your timeline, if you're on Twitter? People loved it, people hated it, you basically only had a really strong opinion about it. And basically, Jeff Atwood was asserting that all of these big efforts for everyone to learn to code are fundamentally flawed because it assumes that more code in the world is an inherently desirable thing. It assumes that coding is the goal. It puts the method before the problem. It assumes that adding naive novice, not even sure they like this whole programming thing coders to the workforce, is a net positive for the world. And finally, it implies that there's a thin, easily permeable membrane between learning to program and getting paid to program professionally. So if you read this whole thing, some of these points hold some water, but it largely reads as if there's government checkpoints stopping you, making sure you've done your yearly hour of code. But the thing is, the last two points stood out to me because it had nothing to do with people not learning to code. It had to do with how we welcome new coders into the workforce or into the community. So people who really kind of understand who these people are, the people that are learning, kind of didn't like the post at all. If you know Zed Shaw, he really only likes things or hates things. So he wrote a blog post that says, please don't become anything, especially not a programmer. Dramatically disagrees with Jeff Atwood. And the people who agreed, I really only saw them in the comments because I don't go to places like Hacker News where I might see agreement, but most of them probably from what it sounded like, just only know about these new people in the abstract. They've heard of hour of code and they're like, that's weird, but they don't know anyone personally. So these new learners, they aren't just drones typing meaningless words into terrible websites, they're people with ideas and life experiences and just value. And our community is only really going to benefit by welcoming them. So I'm certainly not saying that everyone should learn to code, but that anyone should be able to. And how we as more experienced people in the industry greet these new learners will shape the kind of developers that they can become. They need us as much as they need, as we need them. So the journey to becoming a good developer is really a shared adventure between the learners and the teachers. And helping them get over the first major hurdle is really key to their continued learning. And this is kind of what it can look like. So meet Tenderfoot. She's going to be the character that we follow to see what the average experience of someone learning this really difficult thing can be like. And of course, there's different variants to the story, but I think most people have gone through at least all of these stages. So her ultimate goal is to scale this mountain. But she's starting down here. She's going to have to get through multiple levels before achieving her goal. And each level represents a stage in her learning. 1970 psychologist Noel Birch described these stages. They are unconscious incompetence, where you don't know what you don't know. Or the dark and foggy forest. Conscious incompetence, where you know what you don't know. Or the valley before the climb. Conscious competence, where you know what you know. Aka the steeply sloping ascent. And unconscious competence, where you don't know what you know. Or the hazy and lofty clouds. So this forest on the other side of the canyon, that's where Tenderfoot begins. That's level one, the dark and foggy forest. Tenderfoot can't even see the mountain from where she is. She knows in theory that there is a mountain probably, but it's so dark and foggy, she can't even tell if she's in a cave. She has to find her way out of the forest to even get to the canyon. Yeah, dark and foggy forest. Quick reminder. So this is often where beginners first search for something like, how do I learn to code? So meet Tenderfoot's companion, Bangle. Tenderfoot can ask Bangle any question. Bangle will answer with what information it can find, but doesn't really have any context or knowledge of Tenderfoot's end goal. So Bangle can be helpful, but when you don't even know what to ask, not quite as helpful. So as Tenderfoot goes further on her journey, she'll become more familiar with how to rely on Bangle. But early on, Bangle's almost burdensome. Much like Scarecrow from Wizard of Oz, when Tenderfoot asks Bangle, how do I learn to code? She's told many different conflicting things. That's funny. Of course, people do go both ways. Unfortunately, Tenderfoot at this point must decide on her first few steps, just completely on her own. Raven Covington and Elana Rails girl member, I think she's here, once told me, as I began learning, I found there's so much great content out on the internet, which is both awesome and overwhelming. It was difficult for me to chart my own path and figure out where to go next. So Tenderfoot, like Raven and Dorothy, must eventually just pick a direction, somewhat arbitrarily, and just pursue it. If someone's in the middle of a dark forest trying to cross a canyon and then climb a mountain, they must first get out of the forest. Whether they turn right or left and just start walking, they'll eventually reach the edge of the dense trees. And if they fall along the tree line, they'll eventually spot the mountain, at least hopefully. So Tenderfoot chooses direction in the dark and does just that. Step by uninformed step, she makes her way to the edge of the trees. So let's talk a little bit more about the mountain. The mountain on the other side of the deep canyon is like most mountains. It slopes up into the clouds and we, more experienced developers, are climbers or goadalers or whoever on the mountain at different points. The tip top of the mountain is where those on level four reside. They are the unconscious competence crowd. They don't remember climbing the mountain. In fact, they don't even know they're on a mountain. All they know is their life in the cloud and are pretty happy that way. Sometimes, one will wake up, stretch and take a stroll down to visit the other folks. But these are the special people. These are the ones who can remember the path that they took to get to the peak and can retrace it back down. Sometimes, they'll go and visit. So they are by some learning models on the fifth stage of learning, which is called reflective competence or, hold on, conscious competence of unconscious competence. Remember that one. It's likely you've worked with someone that's been in this level for a community. They are knowledgeable and experts at their craft. They can advise on which tool or technology to use and they give really good code reviews. But when it comes time to explain something maybe a little bit more fundamental, they kind of struggle. They've known their craft for so long, they don't remember learning it. Occasionally, you'll get the privilege of working with someone who's more advanced than the level five. They're the best teachers, the best mentors. They're thoughtful about how to describe things and are patient to let you catch up after describing it. Others on the mountain community kind of cycle between level two and level three, conscious and competence, and conscious competence. Many enjoy climbing and repelling back down to climb back up again. They're learning and relearning, sometimes in groups, sometimes on their own. But these mountaineers, they visit the edge of the canyon fairly often to see who might be on the other side. So if we were to pin your location somewhere on the mountain, where do you think you would be? If you feel like junior to mid-level, you probably feel somewhere between level two, maybe level three, cycling between conscious incompetence and conscious competence, always on a steep learning curve. If you're more senior, you'll probably drop your pin somewhere towards the top. And maybe some of y'all are self-aware to know that you live in the clouds and you don't remember. But I think most of us should strive to be a part of the level five community, able to mingle at the top with the more senior people, but making routine visits down below in order to help guide others up. So back to Tenderfoot, she's rambling through a dark forest. It's not scary per se, but it is vast. Stephanie Murillo described this feeling well when blogging about learning how to program in Ruby on Rails. She says, Rails isn't easy, it's approachable. So this realization helped her through some things when she was feeling like she was struggling a little bit too much. And the more experienced people, if we remember that this is actually the truth, it will help us when we are working with others to not discourage them when they are struggling. So Tenderfoot's been asking Bengal for help with basic directions, with achieving her ultimate goal. She's learning a little JavaScript, some Python, some Ruby on Rails, some HTML, some CSS. She's filling her knapsack with lots and lots of items. They're heavy, they're getting mixed up, it's just a big garbled mess. She'll try to reach in and grab one, she grabs the wrong one, she doesn't even know, because she doesn't even know why the things are in her bag in the first place. So her route via Bengal is imperfect and indirect, but she eventually finds her way to the edge of the forest. She steps out of the dark forest and sees a glimmer of light. She hikes up to the canyon ledge and sees a couple of mountaineers on the other side. She gets excited, this must be where things get easier. She tries to get their attention, but they don't seem to notice her. So she writes a note on a paper airplane and flies it across. She's really good at making paper airplanes. She says, hi new friends, how do I get across this canyon? Thanks. And then she waits. So we've all seen this, right? The uninformed question on the stock overflow, the overeager questioner in IRC or a Slack channel. Perhaps you've been like 10 to foot yourself asking something huge when trying to get initial direction, but it's vague and just too big of a question. But just think, this could be a person's first contact with the developer community. I think that's really alarming. I've browsed a bit of the subreddit learn programming and it's a pretty supportive community, but even the well-intentioned people on there who are trying to help can have discouraging messaging. So let's say 10 to foot have written this post. I want to really dig into programming, but I'm feeling a bit overwhelmed. They say, I read posts here and I'm absolutely lost in the amount of technical jargon and such. More than jargon, I'm worried about the mathematical aspects of programming. I've struggled for most of my educational career, including an up to my two years at a local college with anything beyond advanced algebra. I've changed a lot since then, as far as how I think, so I might just have to give it another try. Can anyone give me some insight into what level of math I should be proficient in or expected to be proficient in if I want to go anywhere with programming? So much like a lot of beginners, this person was learning JavaScript, HTML, CSS, and Python all at once. So the top vote of reply was long, obviously well thought out, but it began with a series of questions. They asked the first thing you want to do is take a look at yourself. Do you like math? Do you like logic problems? Are you good at breaking complex problems into parts? If you answered yes to one or more of these, keep reading. If that stuff sounds like a drag, please save yourself some time and look into something else. That is all that programming is, and if you delve deeper, you will find just that. So the well intended reply actually ended with some great advice, but if you're already feeling overwhelmed and flailing, it's not a very encouraging answer. On the other hand, Sarah May wrote a blog post about when she was first starting RailsBridge and she discovered that programming is not math. So imagine if Tenderfoot had heard from Sarah May instead of the well-intentioned redditor. She writes, people came because they wanted to learn how to make websites. Because of those motivations, the curriculum had virtually no math. And this is what finally did it for me. The students I saw all adults came from a wide range of backgrounds. People with a math background did fine, of course, but people with a heavy language background often did better. I saw this curious effect again while working with high schoolers with a similar curriculum, bilingual kids often took to programming more easily than monolingual kids. So I finally figured it out, programming is not math. So what a difference, right? So let's try to treat every paper airplane that we encounter like a delicate paper crane. We should craft kind and sensitive encouraging replies, because our reply might be the first and the last that our Tenderfoot receives. So our Tenderfoot is waiting on her reply. She's reading and typing away, learning all of the things without really learning anything when she gets a reply. Haven't you heard of a bridge? She suddenly feels pretty dumb. Maybe the people on the other side aren't that excited to help her. Another Tenderfoot redditor wrote a post that asked, why are experienced programmers so hostile toward beginners? They said, it's usually assumed that I haven't done my own research, which is never the case. For every helpful reply, it seems that I'll get four or five useless replies attempting to call me out from my own laziness. Out, that really would hurt. If we were playing a video game, I think we would lose health points when we would receive a reply like that. But without considering actual humans asking the questions, it's really easy to fall into the trap of laughing at jokes like this. I don't know if you remember this one, but it's how do I do the thing? I'm not aware of how to use Google. First one's lazy functional answer. And this gets retweeted a lot. I see it all the time. And then just last week, this XKCD comic was really popular. And it's so mean. It's code shaming and condescension as comedy. So we got to cut that out, but that's a whole nother topic. So fortunately, the reply that Tenderfoot received is really just smug, not that aggressive. But another paper airplane arrives and it says, are you asking how to build a bridge? Someone feels a little bit better, but it still isn't very helpful. So what could Tenderfoot do better when writing her own paper airplane messages? Sock overflow has a guide asking good questions. And the main points are golden rule. Imagine you're trying to answer the question, provide enough context like version numbers of tools you're using, database types, frame the problem. So tell your smaller and larger goal and avoid the XY problem where you ask about the solution instead of the problem. And provide sample code and data when relevant and don't include everything. And then finally, take time to write something articulately. What Sock overflow doesn't say is that you should kind of keep the same things in mind when providing the perfect answer. So again, imagine you're receiving the answer, provide enough context. Frame the answer well. So include your thought processes and how you've got to the solution that you are proposing. Provide sample code and data. Again, don't include everything. And take time to write something articulately. A really great talk about this was given recently by Sasha Landy about giving and getting technical help. And I just think everyone should watch it. But she provides a script to asking good questions. So my current understanding is this. I expect to see this here, but instead is doing this. What's going on? Or I want to do this. And I'm trying it by this. What do you think about this approach? So Tenderfoot takes a moment before writing her next note. This time she says, hello, I've just found this canyon and I would like to cross it. I don't know how wide or how deep it is, but I see that some of you have made it across. Can you tell me what you did in order to get there? I would like to build a bridge, but I'm not sure what materials to use. So she lists the item she has and sends a new plane right back across. This time her reply is a little bit more helpful. Hi Tenderfoot, crossing the canyon is super easy. All you need to do is grab your foo and then bar the baz. Make sure you don't baz the bar or else the foo will be sizzle. See you soon. Have you ever heard the phrase drinking from the fire hose? Much like Tenderfoot, it's easy to get lost as a new learner in all of the terms, among all of the other things you're trying to absorb. So this image is so big we have to look at it in pieces, but it's what people are actually learning when learning Ruby on Rails. So we have web stuff, we have OS stuff, database, deployment, command line, text editor, we know that that's really important to argue about early on. Ruby languages, how to manage Ruby, how to do Rails. We have version control testing, agile processes with a capital A, like that's pretty easy, right? So calling things easy or simple or saying you just do the thing is disingenuous and can cause confidence loss. When you're drinking from the fire hose, literally nothing is easy. So when we drop these phrases from our vocabulary when helping, it helps things go a lot better. But does this also mean we should change the words we use? Like isn't a string always a string? Sarah Simon, a graduate of Turing School and former art student and English major, wrote down some of her biggest takeaways at the end of her time there. And unsurprisingly, one of her main points was about gaining fluency. So she says trying to understand something without having the vocabulary to speak coherently about it is a lost cause. So, oh sorry. Pay your dues and learn the system before anything else. By building fluency, you'll allow connections to fall naturally into place. Then with fluency, you'll be able to do incredible things. There's responsibility on both sides of the canyon. When mentors provide context and definitions, when using programming specific terms and ideas, they remove presumption and provide illumination. And when mentees catalog and learn new terms and acronyms, they're able to receive more specific, precise, helpful answers. So Jennifer spent some time parsing the latest note. She has bingo for helping translate some of the message and eventually some of it begins to make more sense to her. But she's still stuck on a few things. All you need to do is grab your foo and then borrow the baz. She looks in her knapsack but she doesn't have a foo available to borrow the baz. Getting tools and environments set up, even as an experienced developer, feels at best tedious and at worst impossible. Installing tools to install other tools and dependencies. It starts to feel like installationception. Anyone who's volunteered at an install fest at, say, Rails Bridge or Rails Girls Workshop has probably encountered some difficult setups. And some of the ones I've seen are partial, previous installations, double installations, weird OS decisions, ancient OS, ancient machines, viruses, dimension malware. Why do we see these things all the time? Well, it's because not only does someone need to know what to install, they have to figure out how to install it along the way. Again, Stephanie Murillo or Ruby 1 Kenobi, she jokes that the first time some people see anything in the command line, it just looks straight out of the matrix. That's the first time they've seen it. And so when things go right, it can be confusing. When things go wrong, it's confusing and discouraging. So if we let our frustration get the best of us, they can really feel ostracized by that. And so when we have these kind of encounters, it can make them feel terrible. And I've done some of these things so I know that they happen. So we have a difficult question. How do we get RVM installed on my 1995 ThinkPad? Here's a horrible answer. Get a new MacBook Pro. Another difficult question. I'm having issues installing something on my Windows or Linux machine. Any ideas why? Here's another horrible answer. Because everything's harder on Windows and Linux. So what we're saying is this is hard. I'm not enjoying it. You're making my life difficult, and your life will be more difficult as a programmer because of your computer. So don't do this. Instead, use these difficult installations to show that experienced programmers, much like this kitten, encounters difficult things all the time. And you can teach them how you troubleshoot and how you read the actual error message. And you get bonus points if you have to ask someone else to show that this is just a part of the experience. So back to Tenderfoot. She still doesn't have a foo. She looks for one without any luck. She asks Bengal, where do I get a foo? But Bengal only offers, did you mean, where do I get some food? So given her experience with questions before, she waits a really long time trying to figure it out. Defeated, she finally sends another message. Sorry, what is a foo? Can't seem to find one. Sorry to ask so many questions. The reply she gets, oh goodness, did I say a foo? I'm going to say a Norf. Have a great day. So here we have Tenderfoot having wasted precious, precious daylight hours hunting for a foo when she actually needed a Norf. When we have tutorials with out-of-date information or assume that someone's using a Unix shell, we can cause them so much mental consternation. Being careful with the helpful information we put out into the world falls under the same category as writing code for the developer who's going to find it later. It's common courtesy. And when we give half answers to questions, we can send new learners in the wrong direction for an indefinite amount of time. If you missed Kylie Stradley's talk yesterday, I'm sorry, but you're just going to have to watch the video. And it's great because she talks about some of these common mistakes that if we were maybe a little bit more open about the mistakes we've made, we could save beginners from making. So checking in when possible can help prevent that. Just by asking, did that work for you, might save them hours of time. So Tenderfoot now, armed with this new updated correct information, uses Bingal to correctly identify and find a Norf. Yay. So she reviews and revises her instructions. Grab your Norf and borrow the Baz. With some help from Bingal and a few informative searches later, what is a bar? What is a Baz? How do I borrow? How do I borrow the Baz? She meticulously, carefully borrows the Baz. She looks up and sees a single step has appeared on her side of the canyon. She waits and nothing else happens. She's one step closer but only one step of many. She timidly writes another note and flies it to her friends. I've successfully borrowed the Baz. I have a step in my bridge now. Thank you so much. What do I do now to finish my bridge? Shortly a reply, right? Great news. Now just keep at it. You have to borrow a lot of Baz's to finish building your bridge across this canyon. See you soon. So she borrows the Baz again. Other stuff appears. Bars the Baz again. Other stuff appears. So what is she doing now? If we borrow ideas from the five levels of psychomotor skills, we can say that she's in the first couple of steps where there's imitation, where she's observing and patterning behavior after someone else, where performance may be of a low quality. And manipulation, where she's listening to instruction and performing it from that. Back in Reddit land, a Tenderfoot Redditor asks, is it okay if I'm successfully going through code academy lessons while not fully understanding some of them? I'm about halfway through the Python course and it's not quite clicking yet. I've not been having any problems with any of the lessons, but sometimes I'll type the code in and it will be correct, but I'll not understand why it worked. Should I just keep going and not worry about fully understanding it until I have more of a grip on the language? As Tenderfeet began to build their bridge across the canyon of cognizance, they're gaining consciousness of their own incompetence. They're quickly learning when they don't know something and what they do not know. This Redditor recognizes that a piece of understanding is missing, but can't quite identify what that piece is. Hold on. It's going to figure it out. Yeah, okay. Yeah, okay. This mix of imitation and manipulation around the halfway point between unconscious incompetence and conscious incompetence is where some of the more obvious aha moments or maybe duh moments start to occur. Again, Raven Covington, a member of Rails Girls said that, yep, that's that side, that's that side. She said, when I was using code academy, I didn't realize how easily you can type something wrong and break your program. It seems obvious to me now, and I fixed the problem by asking someone at a weekend install fest as missing a comma or something. So despite code academy having hints, she said it didn't occur to her at the time that the computer needed to know exactly what she needed it to do. So Eric Michael's over, I think summed it up the best. Zetzal describes this necessary repetition that we're seeing to get across the bridge in the intro of his book, Learn Code the Hard Way. He says, keep at it, force yourself. If you run into a study drill you can't do or a lesson you just don't understand, skip it, come back to it later. Just keep going because with programming there's this very funny thing that happens. At first you will not understand anything. It'll be weird, just like learning any human language. You'll struggle with words, not know what symbols are what, and it'll be very confusing. Then one day, bang, your brain will snap and you will suddenly get it. So some of Tenderfoot's repetition can get a little lonely, but there's just some things she's going to have to figure out on her own. She'll have to have her own ah-ha in her own duh moments. She's counting on the bang, now I get it, as Zetzal is promising. With each of these ah-ha and duh moments, she's inching her way across the canyon. She's learning what she has to learn. She's learning the ABCs so she can then learn how to read, but once she's learning how to read, she'll be halfway up the mountain. She'll be rotating in and out of imitation and manipulation and creeping into the territory of developing precision, where one can reproduce a skill with accuracy and exactness, usually performed independently. So with her head down, focusing on all the bazes she has to bar, she's steadily getting across the bridge. She has vocabulary, tools, resources, the ability to ask better questions, all these things in her knapsack. She has people on the other side who, to answer her paper airplane, messages, and she sees a goal. The mountain is finally in view. She'll have to continue barring the baz, but by the time she gets to the other side, she has more informed questions. What happens if I baz the bar? How bad is a bazizal? I know I needed to know, but what if I used a foo? She might not even understand the answers, but that's for the next stage of her learning. That's what will propel her further. So she's about to take her first step onto the safer, brighter side of the canyon. The challenges there are a little different. She'll have peers, which means more community to learn with, but also competition, because aside from basically learning everything, most developing developers have something else on their mind, and that's, how do I get hired with my new skill? More senior developers need to be careful, again, with the advice we give. It needs to be actionable and practical, not theoretical. A former coworker of mine remembers being told that she should do all of the project oiler problems and to start a company so that she could put CTO on her resume to show off her world-class experience to would-be employers. I've seen other would-be junior developers come to ATL rug, our local Ruby users meet up, and ask questions. How do I get hired? They wrote lots of code. They went to all of the hack events, but they still remained without a job for way too long. It's incomplete to only suggest, write lots of code, and go to hack events. This lacks the insight about what it means when a company hires a junior developer. Doing project oiler problems and attending hack events is just busy work in the absence of building relationships with companies and developer communities. Her Bucka Paulson, a new developer at Kickstarter, summed it up really well. She said companies who have decided to hire juniors have decided to take a risk. You have to connect personally to be the one they take that risk on. So how can junior developers make this connection? The advice I recommend is in addition to writing lots of code, get involved with the developer community, really involved. Help the meet-up organizer set up and clean up. Volunteer to give a talk, even a lightning talk. Volunteer at events. You'll hear about opportunities for internships or junior positions. You'll hear about them first, and then you'll have colleagues to give you both references, advice, and encouragement. Steering soon to be developers to a community and not just a network will help them find their footing and help them find companies that will nurture them in the next step of learning. When people can picture you as a person and as a potential teammate and not just a random resume, they can work harder to find you a place on their team. Again, Rebecca Paulson gave a really good talk about what companies can do once they have juniors on their team or to prepare for juniors on their team. So lots of very, very actionable advice there. So given the meaningful connection she's already made with the people on the other side of the canyon. I think our tender fit is going to do pretty well. Yeah, it's pretty exciting. If the Canyon of Cognizants were a board game, we're about to add the Pioneer Expansion Pack. Tenderfoot has to accomplish the same things, but without any help from the other side of the canyon. This time, Tenderfoot is the first to find her way to a forest, stumble to the ledge of the canyon and figure out how to get across. She doesn't see anyone on the other side. No one she identifies as a friendly face, as a helper, as someone who has made it already. She has no confidence she can get across. If no one else has, why should she be able to? What does this look like in the real world? It probably looks something like this, the gender breakdown at some top tech communities, and this is for technical positions there. Or this, this is the racial breakdown and tech positions at the same companies. So as bad as that looks, just imagine how that feels. When a Tenderfoot falls into one or maybe even more of these categories, she probably won't find someone on the other side as a beacon of success. No one that she'll recognize is, hey, that could be me one day. No one she knows will respond to a message if she sends one, so she might not even bother. Stephanie Magdalia Pai Herrera wrote about the importance of seeing someone familiar and recognizable early in the learning process. She says, prospective and current students need to be able to see people like them in interview rooms and in classroom podiums. We need to know that at every level of these organizations, from board rooms to HR, they're women of color who understand our needs and concerns and can advocate them for a meaningful way. The value of this kind of presence is immeasurable. Knowing that that kind of presence is still all too rare, many established, previous pioneers are working to improve this. The founder of Coding While Black, Dominic Imlidel, says he started the group as an answer to those who say there's a lack of black workers in the technology community, asserting we are here and they want to be found and to be seen. So after seeing no one on the other side of the canyon for far too long, imagine the joy and relief that Tenderfoot would feel someone finally appeared. If that presence was finally visible. Ashley Nelson Hornstein wrote a blog post about one of her newly discovered heroes, Annie Jean Easley an African American computer programmer who worked for the national advisory community for aeronautics later NASA from the 1950s to the 1980s. Ashley learned about Annie Jean Easley via Twitter and once she found out about her she couldn't stop talking about her to other women of color. She writes, having visible examples of people who look like you in an aspirational professional field is powerful. By merely existing, these examples prove there's an achievable pathway to that field. Ashley talked to many of her friends about Easley's life and even got to meet Dr. Yvonne Kegel NASA astronaut and when Ashley showed Dr. Kegel a photo of Easley she said that Dr. Kegel had a tangible emotional reaction. Annie Jean Easley was a pioneer. She figured out her own way through the forest and across the canyon but since Easley was not visible Dr. Yvonne Kegel had to be a pioneer as well when she was building her own bridge towards becoming an astronaut. So what can be done as a community to improve visibility to aid our tender feet? Whether you find yourself in an under or overrepresented group how can we improve the bridge building process? Groups and events like Cody while Black Rails Girls Rails Bridge AlterConf many many others they help members of underrepresented groups find familiar faces. These smaller focus groups act as beacons and can be visible from across the canyon. Just this Monday we had a Rails Bridge workshop with 25 volunteers and 50 students. We had a great time all together especially because there were no tornadoes but more importantly many of our volunteers and organizers not too long ago were Rails Bridge or Rails Girls students themselves. Now many of them are full-time developers or starting internships. Outreach events work and that's just in our own little Atlanta community and yes we did get a discount on our cake for misspelling it Rails Girls but I can fix it there we go. So hopefully now more and more pioneering tender feet can send a paper airplane to someone they identify with and recognize. So let's ask ourselves who are we lifting up to make it visible in our community in your local developer community what events are we funding and helping promote and are we from our mountain of competence sending the right messages and responses to these new would-be members of our community whether they're a pioneer or not each message we craft whether in person or online should recognize the difficulty of the journey they've begun and with each well-crafted message and interactions we're helping tender feet bridge that treacherous canyon we're helping them overcome that first major obstacle of many on their learning path with each bridge built across the canyon our mountain community grows with each bridge built we're gaining traveling companions and who have different experiences and different skill sets the upcoming obstacles we'll face might be completely new to to you or to me but maybe something familiar to our new companions we can solve new and exciting problems together we just have to get them across first thank you very much so I want to thank my co-worker and friend Tam for doing these little doodles for me and helping me realize tender foots to potential so I'm like right at 40 minutes so I don't have time for questions please ask me questions tell me stories in the hallway you can find me on the internet basically everywhere I'm regretting my username for the rest of my life because I don't know how to tell you how to say it ponola, onola, ponela, onela I don't know but I'm basically everywhere except for a warhammer forum from years ago but it's probably not active anymore that one's not me don't know who that is so so I want to thank Blue Bottle and Rails Girls for being like the best part of my developing life and yeah that's all I have for you today