Crossing the Canyon of Cognizance
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
Title |
| |
Subtitle |
| |
Title of Series | ||
Part Number | 56 | |
Number of Parts | 94 | |
Author | ||
License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
Identifiers | 10.5446/30653 (DOI) | |
Publisher | ||
Release Date | ||
Language |
Content Metadata
Subject Area | ||
Genre | ||
Abstract |
|
RailsConf 201556 / 94
1
4
7
8
9
10
11
13
14
16
17
19
21
24
25
29
30
33
34
35
36
37
39
40
42
47
48
49
50
51
53
54
55
58
59
61
62
64
65
66
67
68
70
71
77
79
81
82
85
86
88
92
94
00:00
Adventure gameCodeImage resolutionLattice (order)Control flowComputer programmingVotingHill differential equationLetterpress printingSign (mathematics)Membrane keyboardProgrammer (hardware)Inclusion mapRadio-frequency identificationOSI modelDressing (medical)Computer programLevel (video gaming)ForestMultiplication signPoint cloudTheoryPoint (geometry)Lattice (order)InformationCodeBlogWordContext awarenessPosition operatorAverageComputer programmingSoftware developerVideo gameCodeAngleDialectWater vaporCurveAreaWebsiteProgrammer (hardware)Perturbation theorySingle-precision floating-point formatDifferent (Kate Ryan album)Computer animation
05:30
CodeRight anglePoint (geometry)Computer animationMeeting/InterviewPanel painting
06:03
View (database)Figurate numberInternetworkingEvent horizonDirection (geometry)Reading (process)ForestPoint (geometry)Content (media)Meeting/InterviewComputer animation
06:51
Point cloudMachine visionBitNetwork topologyDirection (geometry)Population densityDifferent (Kate Ryan album)Personal identification numberCurve1 (number)Point cloudReflection (mathematics)Endliche ModelltheorieMereologyLevel (video gaming)Order (biology)CodeCycle (graph theory)Electronic program guideOnline helpGoodness of fitExpert systemMultiplication signPoint (geometry)Uniform resource locatorVideo gameSoftware developerGroup actionGraph (mathematics)Panel paintingComputer animationDrawing
10:08
ForestRuby on RailsKnapsack problemOnline helpBitMassEvent horizonDirection (geometry)Panel painting
11:13
Computer programmingWebsiteCodeMenu (computing)Local ringGame theoryVideoconferencingMathematicsRectangleAreaDiagramTerm (mathematics)ComputerMetreBroadcast programmingTranslation (relic)Well-formed formulaFormal languageSummierbarkeitVideo GenieHill differential equationGamma functionForestRoutingMultiplication signComputer programmingMereologyFunctional (mathematics)1 (number)Video gameKey (cryptography)Local ringArithmetic meanBridging (networking)Level (video gaming)LogicSeries (mathematics)Complex (psychology)Sound effectMassRange (statistics)Student's t-testSimilarity (geometry)WindowDirection (geometry)Formal languageBuffer overflowWeightMathematicsPoint (geometry)BlogCASE <Informatik>AlgebraOnline helpBitProgrammer (hardware)Software developerStack (abstract data type)Sensitivity analysisMessage passingInsertion lossGoogolVideoconferencingPanel paintingComputer animation
16:30
Perfect groupRule of inferenceFrame problemComputer virusSuite (music)Simultaneous localization and mappingDatabase transactionComputing platformServer (computing)Local ringData managementConfiguration spaceData integrityInformation securityConditional probabilitySet (mathematics)Right angleProcess (computing)Web 2.0Medical imagingPoint (geometry)DatabaseRevision controlInternet service providerInsertion lossSampling (statistics)Student's t-testString (computer science)WordOrder (biology)Multiplication signMaterialization (paranormal)Stack (abstract data type)Text editorElectronic program guidePlanningBuffer overflowBitTerm (mathematics)Computer programmingCodeLibrary catalogGlobale BeleuchtungMoment (mathematics)Online helpScripting languageCausalityFrame problemNumberConnected spaceRuby on RailsPhysical systemLatent heatContext awarenessDependent and independent variablesPower (physics)Water vaporBridging (networking)Film editingMessage passingIntegrated development environmentTask (computing)Type theoryStaff (military)Confidence intervalSoftware testingKnapsack problemWeightGoodness of fitSystem on a chipGaussian eliminationCanonical ensembleSummierbarkeitEvent horizonRight angleFood energyFitness functionComputer animation
21:36
Link (knot theory)Source codeWeb pagePay televisionBand matrixFormal languageReading (process)LaptopPasswordAxiom of choiceLeakMobile appGamma functionMacro (computer science)Installation artVirtual machineInstallation artIntegrated development environmentSoftware developerValidity (statistics)Sheaf (mathematics)Video gameMatrix (mathematics)Partial derivativeMultiplication signNeuroinformatikDoubling the cubeVirtual machineWindowFrustration1 (number)MalwareRule of inferenceBridging (networking)Real numberComputer virusDecision theoryComputer animation
23:40
Goodness of fitInclusion mapCodeMassEmulationLevel (video gaming)Formal languageInstallation artProgrammer (hardware)Error messageMereologyPoint (geometry)Multiplication signBridging (networking)Direction (geometry)Online helpBitLevel (video gaming)Message passingVideoconferencingInformationCodeDaylight saving timeSearch algorithmSoftware developerCategory of beingType theoryRight angleWeightFormal languageText editorOrder (biology)Moment (mathematics)Gastropod shellTheoryComputer animationDrawing
28:09
CodeNP-hardSource codeNumberSeries (mathematics)Product (business)DivisorLattice (order)IntelPrime idealNormed vector spaceMIDICASE <Informatik>Maxima and minimaLipschitz-StetigkeitHydraulic jumpThermal expansionGenderText editorGenderMultiplication signSoftware developerSlide ruleConnected spaceForcing (mathematics)Bridging (networking)Observational studyNeuroinformatikAdditionComputer programmingWordSelf-organizationOnline helpEvent horizonFigurate numberMoment (mathematics)Point (geometry)Product (business)NumberCodeGame theoryMessage passingWhiteboardPeer-to-peerCellular automatonRight angleLocal ringReal numberFamilyNatural languageScaling (geometry)ForestPosition operatorDisk read-and-write headDecision theoryLevel (video gaming)SoftwareKnapsack problemCanonical ensembleNP-hardConfidence intervalSymbol tableProjective planeDrill commandsMixed realityType theoryWindowArithmetic meanView (database)Different (Kate Ryan album)WritingProcess (computing)Computer animation
35:09
GenderCodePosition operatorField (computer science)Graph coloringStudent's t-testCodeLevel (video gaming)ReliefMessage passingComputer programGroup actionBlogTwitterProcess (computing)Presentation of a groupArithmetic meanEndliche ModelltheorieSequenceCategory of beingSelf-organizationPower (physics)Computer animation
37:21
Food energySlide ruleDigital photographyVideo gameEvent horizonSinc functionGroup actionCodeBridging (networking)Focus (optics)Process (computing)ForestCodeMeeting/Interview
38:27
SoftwareMultiplication signStudent's t-testBridging (networking)Real numberRight angleSoftware developerLocal ringDiscounts and allowancesEvent horizonDifferent (Kate Ryan album)Video gameInternet forumMessage passingMereologyInternetworkingDependent and independent variablesSelf-organizationVector potentialInteractive televisionMassAreaWebsiteEndliche ModelltheorieValidity (statistics)ArmCellular automatonXMLDrawing
41:23
VideoconferencingArithmetic meanComputer animation
Transcript: English(auto-generated)
00:12
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?
00:25
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
00:45
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
01:02
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
01:27
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
01:44
learning, kind of didn't like the post at all. If you know Zed Shaw, he really only likes things or hates things, so he wrote a blog post that says please don't become anything, especially not a programmer, he dramatically disagrees with Jeff Atwood. And the people who agreed, I really only saw them in the comments because I don't go
02:05
to places like Hacker News where I might see agreement, but most of them probably from what it sounded like just only know about these new people in the abstract, like they've heard of hour of code and they're like that's weird, but they don't know anyone personally.
02:20
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
02:42
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 venture between the learners
03:02
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
03:21
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.
03:42
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
04:01
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
04:26
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
04:45
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?
05:02
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.
05:20
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.
05:55
That way too. That's funny.
06:02
Of course, people do go both ways. Unfortunately, Tenderfoot, at this point, must decide on her first few steps, just completely on her own.
06:21
Raven Covington, an Atlanta 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
06:42
arbitrarily and just pursue it. If someone's in the middle of a dark forest trying to cross a canyon and then climb a mountain, they must first get out of the forest. Whether they turn right or left and just start walking, they'll eventually reach the edge of the dense trees, and if they fall along the tree line, they'll eventually
07:00
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 goatellers
07:25
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.
07:41
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.
08:01
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.
08:21
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.
08:42
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,
09:03
conscious incompetence and conscious competence. Many enjoy climbing and rappelling 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
09:22
to see who might be on the other side. So if we were to pin your location somewhere on the mountain, where do you think you would be? If you feel like junior to mid-level, you probably feel somewhere between level two, maybe level three, cycling between conscious incompetence and conscious competence,
09:42
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 you 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,
10:03
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.
10:22
She says, Rails isn't easy, it's approachable. So this realization helped her through some things when she was feeling like she was struggling a little bit too much. And the more experienced people, if we remember that this is actually the truth, it will help us when we are working with others
10:41
to not discourage them when they are struggling. So Tenderfoot's been asking Bingle for help with basic directions, with achieving her ultimate goal. She's learning a little JavaScript, some Python, some Ruby on Rails, some HTML, some CSS. She's filling her knapsack with lots and lots of items. They're heavy, they're getting mixed up.
11:02
It's just a big garbled mess. She'll try to reach in to 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 Bingle is imperfect and indirect, but she eventually finds her way to the edge of the forest.
11:21
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.
11:42
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. Then she waits. So we've all seen this, right? The uninformed question on the Stack Overflow, the overeager questioner in IRC or a Slack channel.
12:04
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.
12:22
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.
12:40
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 and 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,
13:01
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 voted reply was long, obviously well thought out,
13:24
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.
13:40
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,
14:00
it's not a very encouraging answer. On the other hand, Sarah May wrote a blog post about when she was first starting RailsBridge, and she discovered that programming is not math. So imagine if Tenderfoot had heard from Sarah May instead of the well-intentioned Redditor. She writes, people came because they wanted to learn how to make websites.
14:21
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.
14:41
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.
15:01
We should craft kind and sensitive and 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.
15:20
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?
15:43
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 for my own laziness. Out, that really would hurt. If we were playing a video game, I think we would lose health points
16:02
when we would receive a reply like that. But without considering actual humans asking the questions, it's really easy to fall into the trap of laughing at jokes like this. I don't know if you remember this one, but it's, how do I do the thing? I'm not aware of how to use Google. First one's lazy functional answer. And this gets retweeted a lot.
16:21
I see it all the time. And then just last week, this XKCD comic was really popular. And it's so mean. It's code shaming and condescension as comedy. So we got to cut that out, but that's a whole other topic. So fortunately, the reply that Tenderfoot received is really just smug, not that aggressive.
16:42
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? Stack Overflow has a guide to asking good questions.
17:01
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,
17:20
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 Stack Overflow doesn't say is that you should kind of keep the same things in mind when providing the perfect answer.
17:40
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
18:02
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 it's doing this. What's going on? Or I want to do this, I'm trying it by this,
18:21
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.
18:43
So she lists the items 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
19:00
or else the foo will bezizzle. 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.
19:21
So this image is so big, we have to look at it in pieces, but it's what people are actually learning. I'm 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,
19:41
we have version control testing, agile processes with a capital A. Like that's, you know, 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.
20:01
So when we drop these phrases from our vocabulary when helping, it helps things go a lot better. But does this also mean we should change the words we use? Like isn't a string always a string? Sarah Simon, a graduate of Turing School and former art student and English major,
20:20
wrote down some of her biggest takeaways at the end of her time there. And surprisingly, one of her main points was about gaining fluency. So she says trying to understand something without having the vocabulary to speak coherently about it is a lost cause. So, oh, sorry. Pay your dues and learn the system before anything else.
20:43
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.
21:03
And when mentees catalogue and learn new terms and acronyms, they're able to receive more specific, precise, helpful answers. So Tenderfit spent some time parsing the latest note. She asked Bingle for helping translate some of the message, and eventually some of it begins to make more sense to her.
21:21
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,
21:40
feels at best tedious and at worst impossible. Installing tools to install other tools and dependencies, it starts to feel like installation-ception. Anyone who's volunteered at an install fest at, say, a RailsBridge or Rails Girls workshop has probably encountered some difficult setups.
22:01
And some of the ones I've seen are partial previous installations, double installations, weird OS decisions, ancient OS, ancient machines, viruses, I mentioned malware. Like, why do we see these things all the time? Well, it's because not only does someone need to know what to install,
22:24
they have to figure out how to install it along the way. Again, Stephanie Murillo, or Ruby1Konobi, 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.
22:40
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,
23:02
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.
23:21
Any ideas why? Here's another horrible answer. Because everything's harder on Windows and Linux. So what we're saying is, this is hard. I'm not enjoying it. You're making my life difficult, and your life will be more difficult as a programmer because of your computer. So don't do this. Instead, use these difficult installations
23:42
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.
24:03
So back to Tenderfoot. She still doesn't have a foo. She looks for one without any luck. She asks Mangle, where do I get a foo? But Mangle only offers, did you mean, where do I get some food? So given her experience with questions before, she wastes a really long time trying to figure it out.
24:23
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 meant to say a norf. Have a great day.
24:42
So here we have Tenderfoot having wasted precious, precious daylight hours hunting for a foo when she actually needed a norf. When we have tutorials with out-of-date information or assume that someone's using a Unix shell, we can cause them so much mental consternation.
25:01
Being careful with the helpful information we put out into the world falls under the same category as writing code for the developer who's going to find it later. It's common courtesy. And when we give half answers to questions, we can send new learners in the wrong direction for an indefinite amount of time. If you missed Kylie Stradley's talk yesterday,
25:21
I'm sorry, but you're just going to have to watch the video. And it's great because she talks about some of these common mistakes that if we were maybe a little bit more open about the mistakes we've made, we could save beginners from making. So checking in when possible can help prevent that. Just by asking, did that work for you,
25:41
might save them hours of time. So Tenderfoot now, armed with this new, updated correct information, uses Bingle to correctly identify and find a North. Yay. So she reviews and revises her instructions, grab your North and bar the baz.
26:05
With some help from Bingle 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
26:21
on her side of the canyon. She waits and nothing else happens. She's one step closer, but only one step of many. She timidly writes another note and flies it to her friends. I've successfully barred the baz.
26:42
I have a step in my bridge now, thank you so much. What do I do now to finish my bridge? Shortly a reply writes, 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.
27:00
So she bars the baz again, another step appears, bars the baz again, another step appears. So what is she doing now? If we borrow ideas from the five levels of psychomotor skills, we can say that she's in the first couple of steps where there's imitation, where she's observing and patterning behavior after someone else, where performance may be of a low quality,
27:22
and manipulation, where she's listening to instruction and performing it from that. Back in Reddit land, a tinderfoot Redditor asks, is it okay if I'm successfully going through code academy lessons while not fully understanding some of them? I'm about halfway through the Python course and it's not quite clicking yet.
27:40
I've not been having any problems with any of the lessons, but sometimes I'll type the code in and it will be correct, but I'll not understand why it worked. Should I just keep going and not worry about fully understanding it until I have more of a grip on the language? As tinderfeet began to build their bridge across the canyon of cognizance,
28:00
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. Is it going to figure it out?
28:22
Yeah, okay. This mix of imitation and manipulation around the halfway point between unconscious incompetence and conscious incompetence is where some of the more obvious aha moments
28:40
or maybe duh moments start to occur. Again, Raven Covington, a member of Rails Girls said that, yep, that's that side, that's that side. She said, when I was using Code Academy, I didn't realize how easily you can type something wrong and break your program. Seems obvious to me now, and I fixed the problem by asking someone at a weekend install fest.
29:02
I was missing a comma or something. So despite Code Academy having hints, she said it didn't occur to her at the time that the computer needed to know exactly what she needed it to do. So Eric Michael's over, I think summed it up the best. Zadshal describes this necessary repetition
29:21
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.
29:41
It'll be weird, just like learning any human language. You'll struggle with words, not know what symbols are what, and it'll be very confusing. Then one day, bang, your brain will snap, and you will suddenly get it. So some of Tenderfit's repetition can get a little lonely, but there's just some things she's going to have to figure out on her own.
30:02
She'll have to have her own aha and her own duh moments. She's counting on the bang, now I get it, as Zadshal 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,
30:20
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,
30:40
focusing on all the baz's 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 to answer her paper airplane messages, and she sees a goal. The mountain is finally in view.
31:00
She'll have to continue barring the baz, but by the time she gets to the other side, she has more informed questions. What happens if I baz the bar? How bad is a bazizzle? I know I needed a north, 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.
31:22
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,
31:41
and that's how do I get hired with my new skill? More senior developers need to be careful, again, with the advice we give. It needs to be actionable and practical, not theoretical. A former coworker of mine remembers being told that she should do all of the project oiler problems and to start a company
32:02
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?
32:20
They wrote lots of code, they went to all the hack events, but they still remained without a job for way too long. It's incomplete to only suggest write lots of code and go to hack events. This lacks the insight about what it means when a company hires a junior developer. Doing project oiler problems and attending hack events
32:41
is just busy work in the absence of building relationships with companies and developer communities. Rebecca Paulson, a new developer at Kickstarter, summed it up really well. She said companies who have decided to hire juniors have decided to take a risk. You have to connect personally to be the one they take that risk on.
33:00
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 meetup organizer set up and clean up. Volunteer to give a talk, even a lightning talk. Volunteer at events.
33:20
You'll hear about opportunities for internships or junior positions, you'll hear about them first, and then you'll have colleagues to give you both references, advice, and encouragement. Steering soon to be developers to a community and not just a network will help them find their footing
33:41
and help them find companies that will nurture them in the next step of learning. When people can picture you as a person and as a potential teammate and not just a random resume, they can work harder to find you a place on their team. Again, Rebecca Paulson gave a really good talk about what companies can do
34:00
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 Tenderfoot is going to do pretty well. Yeah, it's pretty exciting.
34:23
If the Canyon of Cognizance were a board game, we're about to add the Pioneer Expansion Pack. Tenderfoot has to accomplish the same things but without any help from the other side of the canyon. This time, Tenderfoot is the first to find her way to a forest,
34:41
stumble to the ledge of the canyon, and figure out how to get across. She doesn't see anyone on the other side. Knowing 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?
35:01
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 in tech positions at the same companies. So as bad as that looks, just imagine how that feels. When a Tenderfoot falls into one
35:21
or maybe even more of these categories, she probably won't find someone on the other side as a beacon of success. No one that she'll recognize is, hey, that could be me one day. No one she knows will respond to a message if she sends one, so she might not even bother. Stephanie Magdalia-Pye-Herrera
35:40
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 boardrooms to HR, there are women of color who understand our needs
36:00
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 M. Liddell,
36:20
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.
36:43
Ashley Nelson Hornstein wrote a blog post about one of her newly discovered heroes, Annie Jean Easley, an African American computer programmer who worked for the National Advisory Committee for Aeronautics, later NASA, from the 1950s through the 1980s. Ashley learned about
37:00
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.
37:22
Ashley talked to many of her friends about Easley's life and even got to meet Dr. Yvonne Cagle, a NASA astronaut, and when Ashley showed Dr. Cagle a photo of Easley, she said that Dr. Cagle had a tangible, emotional reaction. Annie Jean Easley was a pioneer.
37:41
She figured out her own way through the forest and across the canyon, but since Easley was not visible, Dr. Yvonne Cagle 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?
38:01
Whether you find yourself in an under or over-represented group, how can we improve the bridge-building process? Groups and events like Coding While Black, Rails Girls, RailsBridge, AlterConf, many, many others, they help members of underrepresented groups find familiar faces.
38:20
These smaller focus groups act as beacons and can be visible from across the canyon. Just this Monday, we had a RailsBridge 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
38:41
and organizers not too long ago were RailsBridge 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,
39:00
Rail Girls, but I can fix it. There we go. So hopefully now, more and more pioneering Tenderfeet 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,
39:20
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,
39:40
should recognize the difficulty of the journey they've begun. And with each well-crafted message and interactions, we're helping Tenderfeet 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.
40:01
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 it's something familiar to our new companions. We can solve new and exciting problems together. We just have to get them across first.
40:22
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 Tenderfoot's true potential.
40:42
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,
41:00
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 like the best part of my developing life and yeah, that's all I have for you today.
Recommendations
Series of 22 media