Crossing the Canyon of Cognizance
Vickers, Pamela O.
Most of the four learning stages - unconscious incompetence, conscious incompetence, conscious competence and unconscious competence - are bridged by acquiring experience. But the gap between unconscious incompetence to conscious competence is where the most discomfort and discouragement occurs. Helping new developers bridge the void ensures a vibrant, accessible community, and having visible members/mentors in each stage encourages newcomers' learning. This talk illustrates (literally!) how to help new colleagues build this bridge and prevent losing them in the what-do-I-even-Google abyss.
 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, says, please don't become anything, especially not a programmer. He 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 that, 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. Like, 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. Oh 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, Bingle. Tenderfoot can ask Bingle any question. Bingle will answer with what information it can find, but doesn't really have any context or knowledge of Tenderfoot's end goal. So Bingle 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 Bingle, but early on, Bingle's almost burdensome. Much like Scarecrow from Wizard of Oz, when Tenderfoot asks Bingle, how do I learn to code, she's told many different conflicting things. Who said that? Don't be silly, Total. Scarecrow's don't talk. It's pleasant down that way too. That's funny. Wasn't he pointing the other way? Of course people do go both ways. Hello. 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. So 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 four 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 someone who's more advanced in 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, focus 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 and competence 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 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 Bingal for help with basic directions with achieving her ultimate goal. She's learning a little JavaScript on Python, Ruby on Rails, HTML, 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 Bingal 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 over eager questioner in IRC or a Slack channel. Perhaps you've been like Tenderfoot 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 browse 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 Tenderfoot had 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 Rails Bridge 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. This gets retweeted a lot. I see it all the time. 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 other 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? Sacr overflow has a guide to 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 Sacr 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 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 of 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. 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. 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? Thera 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 co-currently about it is a lost cause. So, oh sorry. Pay your dues and learn the system before anything else. By building fluency, you 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 Tender Fint 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 bar the baz. She looks in her knapsack but she doesn't have a foo available to bar 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 installation seption. Anyone who's volunteered at an install fest at say a Rails bridge or Rails workshop has probably encountered some difficult set ups. 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 I 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. And the idea is 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 north. Have a great day. So here we have Tenderfoot having wasted precious, precious daylight hours hunting for a foo when she actually needed a north. When we have tutorials without of date information or assume that someone is using a unique 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 is going to find it later. It's common courtesy. 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. 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 beginner's room 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 north. So she reviews and revises her instructions, grab your north 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 bar? How do I bar the baz? She meticulously carefully bars the baz. She looks up and sees a single step has appeared on her side of the canyon. Hooray! 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 barred the baz. I have a step in my bridge now. Thank you so much. What do I do now to finish my bridge? Shortly reply, right? Great news. Now just keep at it. You have to bar a lot of bazes to finish building your bridge across this canyon. See you soon. So she bars 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 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 tenor foot Redditor asks, is it okay if I'm successfully going through code academy lessons while not fully understanding some of them? I'm 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 if I'm not understanding 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 tender feet begin 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. This mix of imitation and manipulation around the halfway point between unconscious and 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 side, that side. She said, when I was using Code Academy, I didn't realize how easily you can type something wrong in a break-up program. It seems obvious to me now and I fixed the problem by asking someone at a weekend in Stahlfest. I was missing a comma or something. 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 is over. I think he 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 will be weird, just like learning any human language. You'll struggle with words, not know what symbols are what, and it will 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 aha in her own duh moments. She's counting on the bang. Now I get it, as Zetzal is promising. With each of these aha 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 bazes, but by the time she gets to the other side, she has more informed questions. What happens if I baz with bar? How bad is a bazizzle? I know I need to denort, 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 oriler 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 oriler problems and attending hack events is just busy work in the absence of building relationships with companies and developer communities. Rebecca Poulsen, 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. Help them find their footing and 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 Poulsen 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 foots are going to do pretty well. Yeah, it's pretty exciting. But if the canyon of cognizance were a board game, we're about to add the pioneer expansion pack. Tender foot has to accomplish the same things, but without any help from the other side of the canyon. This time, tender foot 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 tender foot 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 as, 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 in 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 if someone finally appeared. If that presence was finally visible. Ashley Nelson Hornestein 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. They even got to meet Dr. Yvonne Kegel, a 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 and 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 who have different experiences and different skill sets. The upcoming obstacles we'll face might be completely new 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 Foot's 2 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. Ponela, onela, 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 I want to thank Blue Bottle and Rails Girls for being the best part of my developing life. And yeah, that's all I have for you today.
 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, says, please don't  become anything, especially not a programmer. He 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 that, 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. Like, 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.  Oh 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, Bingle. Tenderfoot  can ask Bingle any question. Bingle will answer with what information it can find, but doesn't  really have any context or knowledge of Tenderfoot's end goal. So Bingle 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 Bingle, but early on,  Bingle's almost burdensome. Much like Scarecrow from Wizard of Oz, when Tenderfoot asks Bingle,  how do I learn to code, she's told many different conflicting things.  Who said that? Don't be silly, Total. Scarecrow's don't talk. It's pleasant down that way too.  That's funny. Wasn't he pointing the other way? Of course people do go both ways.  Hello. 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.  So 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 four 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 someone who's  more advanced in 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,  focus 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  and competence 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 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 Bingal for help  with basic directions with achieving her ultimate goal. She's learning a little JavaScript  on Python, Ruby on Rails, HTML, 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 Bingal 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 over eager questioner in IRC or a Slack channel. Perhaps you've been  like Tenderfoot 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 browse 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 Tenderfoot had 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 Rails Bridge 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. This gets retweeted  a lot. I see it all the time. 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 other 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?  Sacr overflow has a guide to 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 Sacr 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 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 of 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. 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. 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? Thera 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 co-currently  about it is a lost cause. So, oh sorry. Pay your dues and learn the system before anything  else. By building fluency, you 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 Tender Fint 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  bar the baz. She looks in her knapsack but she doesn't have a foo available to bar 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 installation seption. Anyone who's volunteered at an install fest  at say a Rails bridge or Rails workshop has probably encountered some difficult set ups.  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 I 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. And the idea is 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 north. Have a great  day. So here we have Tenderfoot having wasted precious, precious daylight hours hunting  for a foo when she actually needed a north. When we have tutorials without of date information  or assume that someone is using a unique 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 is going to find it later. It's common  courtesy. 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. 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 beginner's room 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 north. So she reviews and revises her instructions, grab your north  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 bar? How do I bar the baz? She meticulously carefully  bars the baz. She looks up and sees a single step has appeared on her side of the canyon.  Hooray! 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  barred the baz. I have a step in my bridge now. Thank you so much. What do I do now to  finish my bridge? Shortly reply, right? Great news. Now just keep at it. You have to bar  a lot of bazes to finish building your bridge across this canyon. See you soon. So she bars  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 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 tenor foot Redditor asks, is it okay if I'm successfully going through  code academy lessons while not fully understanding some of them? I'm 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 if I'm not understanding  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 tender feet begin 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. This mix of imitation and manipulation around the  halfway point between unconscious and 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 side, that side. She said, when I was using  Code Academy, I didn't realize how easily you can type something wrong in a break-up  program. It seems obvious to me now and I fixed the problem by asking someone at a weekend  in Stahlfest. I was missing a comma or something. 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 is over. I think he 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 will be weird, just like learning  any human language. You'll struggle with words, not know what symbols are what, and  it will 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  aha in her own duh moments. She's counting on the bang. Now I get it, as Zetzal is promising.  With each of these aha 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 bazes, but by the time she gets to the other side, she has  more informed questions. What happens if I baz with bar? How bad is a bazizzle? I know  I need to denort, 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 oriler 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 oriler problems and  attending hack events is just busy work in the absence of building relationships with  companies and developer communities. Rebecca Poulsen, 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. Help them find their footing and 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 Poulsen 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 foots are going to do pretty well. Yeah,  it's pretty exciting. But if the canyon of cognizance were a board game, we're about  to add the pioneer expansion pack. Tender foot has to accomplish the same things, but  without any help from the other side of the canyon. This time, tender foot 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 tender foot 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 as, 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 in 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 if someone finally appeared. If that presence  was finally visible. Ashley Nelson Hornestein 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. They even got to meet Dr. Yvonne Kegel, a 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 and 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 who have different experiences  and different skill sets. The upcoming obstacles we'll face might be completely new 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 Foot's 2 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. Ponela, onela, 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 I  want to thank Blue Bottle and Rails Girls for being the best part of my developing life.  And yeah, that's all I have for you today.
Crossing_the_Canyon_of_Cognizance_0_155.png Crossing_the_Canyon_of_Cognizance_156_299.png Crossing_the_Canyon_of_Cognizance_300_3551.png Crossing_the_Canyon_of_Cognizance_3552_5891.png Crossing_the_Canyon_of_Cognizance_5892_8267.png Crossing_the_Canyon_of_Cognizance_8268_8615.png Crossing_the_Canyon_of_Cognizance_8616_8747.png Crossing_the_Canyon_of_Cognizance_8748_8915.png Crossing_the_Canyon_of_Cognizance_8916_10283.png Crossing_the_Canyon_of_Cognizance_10284_11339.png Crossing_the_Canyon_of_Cognizance_11340_13439.png Crossing_the_Canyon_of_Cognizance_13440_16835.png Crossing_the_Canyon_of_Cognizance_16836_17123.png Crossing_the_Canyon_of_Cognizance_17124_26231.png Crossing_the_Canyon_of_Cognizance_26232_26855.png Crossing_the_Canyon_of_Cognizance_26856_32399.png Crossing_the_Canyon_of_Cognizance_32400_32615.png Crossing_the_Canyon_of_Cognizance_32616_32723.png Crossing_the_Canyon_of_Cognizance_32724_32783.png Crossing_the_Canyon_of_Cognizance_32784_33155.png Crossing_the_Canyon_of_Cognizance_33156_33263.png Crossing_the_Canyon_of_Cognizance_33264_33359.png Crossing_the_Canyon_of_Cognizance_33360_34763.png Crossing_the_Canyon_of_Cognizance_34764_36047.png Crossing_the_Canyon_of_Cognizance_36048_36815.png Crossing_the_Canyon_of_Cognizance_36816_37247.png Crossing_the_Canyon_of_Cognizance_37248_39671.png Crossing_the_Canyon_of_Cognizance_39672_39983.png Crossing_the_Canyon_of_Cognizance_39984_40211.png Crossing_the_Canyon_of_Cognizance_40212_43247.png Crossing_the_Canyon_of_Cognizance_43248_43931.png Crossing_the_Canyon_of_Cognizance_43932_45671.png Crossing_the_Canyon_of_Cognizance_45672_50435.png Crossing_the_Canyon_of_Cognizance_50436_57311.png Crossing_the_Canyon_of_Cognizance_57312_57671.png Crossing_the_Canyon_of_Cognizance_57672_62087.png Crossing_the_Canyon_of_Cognizance_62088_62219.png Crossing_the_Canyon_of_Cognizance_62220_62459.png
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, says, please don't become anything, especially not a programmer. He 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 that, 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. Like, 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. Oh 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, Bingle. Tenderfoot can ask Bingle any question. Bingle will answer with what information it can find, but doesn't really have any context or knowledge of Tenderfoot's end goal. So Bingle 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 Bingle, but early on, Bingle's almost burdensome. Much like Scarecrow from Wizard of Oz, when Tenderfoot asks Bingle, how do I learn to code, she's told many different conflicting things. Who said that? Don't be silly, Total. Scarecrow's don't talk. It's pleasant down that way too. That's funny. Wasn't he pointing the other way? Of course people do go both ways. Hello. 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. So 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 four 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 someone who's more advanced in 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, focus 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 and competence 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 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 Bingal for help with basic directions with achieving her ultimate goal. She's learning a little JavaScript on Python, Ruby on Rails, HTML, 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 Bingal 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 over eager questioner in IRC or a Slack channel. Perhaps you've been like Tenderfoot 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 browse 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 Tenderfoot had 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 Rails Bridge 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. This gets retweeted a lot. I see it all the time. 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 other 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? Sacr overflow has a guide to 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 Sacr 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 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 of 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. 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. 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? Thera 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 co-currently about it is a lost cause. So, oh sorry. Pay your dues and learn the system before anything else. By building fluency, you 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 Tender Fint 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 bar the baz. She looks in her knapsack but she doesn't have a foo available to bar 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 installation seption. Anyone who's volunteered at an install fest at say a Rails bridge or Rails workshop has probably encountered some difficult set ups. 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 I 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. And the idea is 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 north. Have a great day. So here we have Tenderfoot having wasted precious, precious daylight hours hunting for a foo when she actually needed a north. When we have tutorials without of date information or assume that someone is using a unique 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 is going to find it later. It's common courtesy. 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. 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 beginner's room 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 north. So she reviews and revises her instructions, grab your north 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 bar? How do I bar the baz? She meticulously carefully bars the baz. She looks up and sees a single step has appeared on her side of the canyon. Hooray! 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 barred the baz. I have a step in my bridge now. Thank you so much. What do I do now to finish my bridge? Shortly reply, right? Great news. Now just keep at it. You have to bar a lot of bazes to finish building your bridge across this canyon. See you soon. So she bars 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 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 tenor foot Redditor asks, is it okay if I'm successfully going through code academy lessons while not fully understanding some of them? I'm 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 if I'm not understanding 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 tender feet begin 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. This mix of imitation and manipulation around the halfway point between unconscious and 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 side, that side. She said, when I was using Code Academy, I didn't realize how easily you can type something wrong in a break-up program. It seems obvious to me now and I fixed the problem by asking someone at a weekend in Stahlfest. I was missing a comma or something. 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 is over. I think he 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 will be weird, just like learning any human language. You'll struggle with words, not know what symbols are what, and it will 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 aha in her own duh moments. She's counting on the bang. Now I get it, as Zetzal is promising. With each of these aha 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 bazes, but by the time she gets to the other side, she has more informed questions. What happens if I baz with bar? How bad is a bazizzle? I know I need to denort, 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 oriler 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 oriler problems and attending hack events is just busy work in the absence of building relationships with companies and developer communities. Rebecca Poulsen, 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. Help them find their footing and 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 Poulsen 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 foots are going to do pretty well. Yeah, it's pretty exciting. But if the canyon of cognizance were a board game, we're about to add the pioneer expansion pack. Tender foot has to accomplish the same things, but without any help from the other side of the canyon. This time, tender foot 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 tender foot 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 as, 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 in 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 if someone finally appeared. If that presence was finally visible. Ashley Nelson Hornestein 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. They even got to meet Dr. Yvonne Kegel, a 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 and 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 who have different experiences and different skill sets. The upcoming obstacles we'll face might be completely new 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 Foot's 2 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. Ponela, onela, 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 I want to thank Blue Bottle and Rails Girls for being the best part of my developing life. And yeah, that's all I have for you today.
experience of someone learning this really They are unconscious incompetence where you don't unconscious competence crowd. They don't remember on, conscious competence of unconscious four community. They are knowledgeable and between conscious and competence and conscious clouds and you don't remember. But I think most arrives and it says, are you asking how to build help prevent that. Just by asking, did that work incompetence is where some of the more obvious soon to be developers to a community and not just companies that will nurture them in the next step other women of color. She writes, having visible