Learning Fluency
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
Simon, Sara
All languages work in formulaic ways. Cracking these formulas takes discipline, time, creativity, trial and error. But is there an overarching formula to crack these formulas? Is there a designated set of steps we can take to guarantee fluency? In this talk, you will learn about the methods people use to learn both foreign languages and programming languages. As developers, we often just jump in and start building. Why is this? Does full immersion work best always and for everyone? What is fluency, and is it ever something we can achieve in Ruby? Let’s explore.
 All right, let's go ahead and get started. Hi, everyone. Thank you for coming today. My name is Sarah. It's a total honor to be here today. Today, I'm talking about languages. I'm talking about learning different languages and speaking different languages and using different languages to write code. I'm talking about programming languages and about the ways we can program our brains to learn languages. I'm talking about fluency and what that means and how to achieve it. What does it mean to be fluent in a programming language? And does that mean the same thing as being fluent in a foreign language? And what does that even mean? Before I get too deep into this talk, I do have to confess it's been a long time since I last touched Ruby. I have a Python job right now. Truly apologetic for everyone here about that. I took a Python job for a number of reasons, not the least of which is that the best way to better understand one language is to start to learn another. What I'm trying to say is that before I get too deep into this talk, I do have to acknowledge its irony. I'm here today telling you all what it means to be fluent in a language I don't know that well. That's the premise. I never know what to say when someone asks me what I do and I say I'm a web developer and they ask, oh, is that what you studied? Have you always been interested in that? The easy answer is to say no. It's not even close. I spent six years at an art school where I studied creative writing and then I went to a liberal arts college where I majored in English and I spent a year and a half writing a 75-page paper about Ernest Hemingway's childhood. In college, I did not take a single computer science class. I did sign up for a calculus class, but after failing the first midterm and having my professor tell me that I was, in his words, really bad at math and having my dean tell me to, in her words, drop the class like it's a hot potato, I withdrew. When I was little, I went to Hebrew school. This is a photo of me in a Purim parade in a sea of queen esters, dare to be the hamentashen. I stopped studying Hebrew after my bat mitzvah. I started to learn Japanese because I was supposed to be an exchange student in Japan. The trip was all set, but then September 11th happened and the program canceled all international student exchanges. I was in a Spanish immersion program in elementary school and then I took Spanish again actually in high school too, but it was never any good at it, largely because I didn't put in the effort, but maybe also because it was a public art school. The one teacher was thrown into a classroom of more than 30 students who together made up a class of four different language levels. Then I took Italian my first year of college and much to the chagrin of my mother of Italian heritage and also probably much to the chagrin of that high school Spanish teacher who had rooted hard for the romance languages. I was pretty bad at Italian too. What am I talking about again? I'm talking about languages and fluency and how to learn languages and how to achieve fluency. So far all I've covered is how I've failed at learning languages. Throughout college I worked in Boston's Chinatown giving homework help to elementary school students who spoke Cantonese or Mandarin, mostly Cantonese at home. These kids, these like six to 10 year olds, they were really struggling with learning English and it's totally legitimate. English is such a hard language to learn. Grammar, sentence structure, vocabulary, spelling, they always used to tell me about how hard it was to learn. I don't remember how it came up but one day they joked that I should learn Mandarin and I said all right, I will. And they looked at me with that fierce but fleeting curiosity found only in small children and then they all had a good laugh about it and they said no Sarah, you can't learn Mandarin, it's too hard. And that's the story of how I learned Mandarin. In hindsight I probably should have taken that same approach with a calculus teacher in college but I don't know, maybe there's something, there's some kind of sweet revenge that comes from proving a group of your own students wrong that you just don't find when it's merely the teacher you're trying to impress. I also used to be a tournament chess player. This is a photo of me and my brother, he was getting ready for a game and I was giving him a pep talk I guess. Our parents house in Oregon is cluttered in the same way that any empty nester house is cluttered when the two adult children of two adults move across the country and leave behind old books and backpacks and a cocker spaniel and a closet full of chess trophies. It's funny the joke when I was, I don't know, six was that I loved going to chess tournaments because I never had to wait in line to go to the bathroom. Here I am two decades later at a programming language conference. The difference of course is that now I would gladly have to wait in line. I also used to be an actor, call it professional theater, call it community theater, call it whatever, I did all kinds of weird things. I did a summertime production of a Midsummer Night's Dream on the Oregon coast. I did a Halloween production of Night of the Living Dead in an old rundown movie theater. I did this one actually a few years in a row because I was Judy so if anyone who's familiar with the movie knows and spoiler to anybody who's not Judy's eaten by zombies halfway through it and she never comes back as a zombie so the show started at midnight by 1245 I was dead and I got to go home. I was in a production called the Apple Tree, a musical, the fictional account of Adam and Eve. I did a show called Columbinus about the Columbine shootings. I did Henry V, I did Footloose, I did the importance of being earnest, I reluctantly did high school musical. All this to say, I never know how to respond when someone asks me what I do and I say I'm a web developer and they ask oh is that what you studied? Have you always been interested in that? Again, the easy answer is to say no, it's not even close. The better answer is to say yes entirely. I'm giving this talk because what I learned through chess was the importance of technique and of strategy. The importance of knowing how to think ahead two, three, five, even ten moves into the future because in a good game of chess you know that's what your opponent is doing. I'm giving this talk because what I learned through theater was the importance of improvisation. The importance of knowing how to make things up when you need to make things up because your scene partner apparently took an extra long smoke break and has not yet appeared on stage for your scene. I'm giving this talk because building software is half strategy and half improvisation and I do think there are ways to train in both. I'm giving this talk because I like learning languages. Because the more I write object oriented code the better I understand Chinese where each stroke represents one idea, each character is made up of a collection of strokes, each collection of strokes represents one meaning and each word is formed when these different collections compose. I'm giving this talk because the more I study Chinese the better I understand English because the better I understand English the better I write code. The better I understand English the more concise my methods, the more straightforward my documentation, the more thorough my tests. I'm giving this talk because the more thorough my tests the better I think about creative writing. If I expect result A when I run command B I can learn to expect that character C must have a specific kind of reaction when the plot twists with action D. When I started to learn to code people told me that the hardest thing I was going to have to get used to was learning how to Google and I just wanted to be like have you ever tried to write a story? I used to write historical fiction. You misname one character. Misuse one reference. Throw one refrigerator into the kitchen of a home that's got to have an ice box out back and you immediately lose your reader. You immediately lose your user. It's all connected. How to manage and how it plays out and how to learn it and how to build upon it and maintain it. How to master its technique and how to think about it in the long term and how to improvise with it and how to turn it into something that people want to use. It's a puzzle and fluency is key. Straight out of college I took my English degree and I moved to Minneapolis where I got a communications job at a software consultancy. I liked the people. I liked the pace. I liked the puzzles. At the time I was the only person on the team with a non-dev, non-designed background. Basically I got the job because I said I do all of the writing that didn't need to be done in code. The contracts, proposals, tweets, emails. The joke was that I programmed in Microsoft Word. So I was there and I loved it. They were a completely fantastic team. But a huge part of my job was to translate what they were talking about and they started talking about things like rakes and cucumbers and capybaras and forks and somebody named Hubeaut and bouncing unicorns and hating waterfalls. Let's all please pause for a moment and acknowledge the fact that we have ridiculous sounding jobs. I mentioned I work in Python earlier. Which is fine. I'm enjoying it. But don't you dare try to convince me that an egg is a serious name for a serious component in a Python package management system. I realized quickly that I needed to learn this language. And then the more I learned about it, the more I realized that I didn't just want to write about software anymore. I wanted to write it too. I hit Google. Google. What's the best first programming language to learn? Ruby. That sounds great. Actually back in Oregon I used to nanny, a little girl named Ruby. And she was the sweetest, most perfect handful I've ever met. So I figured like, okay, if that's a good, you know, prediction of how this is going to go. At least I understand. I can prepare myself. But hey, I figured I've tried to learn languages before. I can handle another. So I started to learn Ruby. I was learning my hashes. I was learning my instance variables. I didn't understand why everyone around me was caught up in a heated discussion about which text editor I was supposed to be using because what did I care? Approximately 5,000 people told me that the best way to learn to code was by coming up with a project and jumping on in. They insisted on this. This was how it worked. If you want to learn to code, you simply have to jump on in. I just had to trust them on this. But the jumping on in was terrifying for me. That's me in the bottom right corner, by the way. I tried to do an accurate emoji representation of diversity in the tech industry. It looks bad, right? I mean, I think I nailed it. But it looks bad. It is bad. And we are way past overdue to fix it. I trusted these people because they were the pros. The pros were telling me this was the only way to make it happen. If I wanted to learn to code, I had to jump on in. And for me, what this meant was that for my first few months of learning Ruby, I had jumped in to an environment that praised project-based learning. It was an environment filled with people who knew how to get their hands dirty, as they say, people who learned best by doing and by building and by making. Now don't get me wrong. I like to build things. You definitely want me on your Jenga team. But these people made me feel like I was living in a world with signs I couldn't read, and sound effects I couldn't hear, and hand gestures I couldn't understand. A world without structure, a map with no key, a city without sidewalks. I took a step back, and I thought a bit about the people who had told me that in order to learn Ruby, I, Sarah Simon, simply needed to come up with a project and jump on in. I thought a bit about this group, and had given the makeup of our industry, it should be no surprise. The vast majority of them were men, predominantly white, who had grown up struggling with school because they were bored in the classes they didn't care about, so they'd fidgeted and fumbled around until they found code on their own. And then they taught themselves by coming up with a project and jumping on in. Now that's cool, right? There's nothing wrong with that. It's just not me. It's not what I need. And chances are, it's not what a few other people might need either. Say what you will about the social construct behind me not needing this. And frankly, please do say it, because to a certain extent it's probably quite revealing, right? Reward young boys when they experiment and try things and jump on in. Young girls tend to be rewarded when they listen and do what's expected of them and follow the rules. I live in Vermont now, home of Middlebury College, GoPanthers. Every summer, Middlebury hosts a full-time language immersion program, isolated on a small campus in a rural town about an hour south of Burlington. I did the Middlebury language program a few years ago, summer of 2011. I signed a language pledge one of my first nights on campus and agreed to speak, listen, read, and write only in Mandarin all summer. Speak, listen, read, and write only in Mandarin all summer. This is serious, all summer. No breaks, no distractions, no going home at the end of the night. We were not supposed to call our friends and family. At Middlebury, classes began every day with a tingshia, a dictation quiz, literally a listen, write. The instructor every morning would stand at the front of the class, recite the daily dictation, and watch as the classroom of students furiously attempted to scribble down what they'd heard. We started with vocabulary words and then as the summer progressed, we moved to sentences and then paragraphs. It was a quick 10-minute routine at the start of class every morning. And the tingshia was great because we always knew exactly what to expect. At the end of each workday, after hours of class and a daily one-on-one with an instructor, my classmates and I were given a list of words that were all fair game for the next day's quiz. The list grew each week. By the end of the summer, I was memorizing 100 words a night. This is Mandarin, remember, so not only did I have to memorize the Chinese pronunciation and the English meaning, but also what the character looked like and how to write it. And again, because this is Mandarin, of those 100 words, the vast majority were composed of two or three characters, right, ting, which means listen, shia, which means write, together tingshia, to mean dictation. Here's a real photo from one of my old textbooks. Important vocabulary words here, clearly. I came up with a pretty good system. The Chinese school ate dinner from 6 p.m. to 7 p.m. This was very strict. The Italian school had the dining hall immediately after us and they would always give us such glares as we passed each other in and out of the building because they knew that we had eaten all of the good food and of course we had, but they weren't allowed to communicate in anything other than Italian and we couldn't communicate in anything other than Chinese. At 7 p.m. after dinner, I'd find a good spot to sit and I'd pace myself. I'd focus on one word at a time. I'd memorize its pronunciation and its meaning. I'd write the character once while looking at it, again while looking at it. I'd cover up my cheat sheet and write it once without looking at the character, again without looking at the character. When muscle memory took over, I moved to a new word. I worked in chunks of five. Every time I mastered the fifth word, I'd go back and repeat the previous five. At 20, I'd repeat all 20, the same with 40, 60, and so on. I did this five nights a week for eight weeks. The summer was exhausting. It was frustrating. It was the complete opposite of what so many people say is the best way to learn a language, but for me, it worked. There's a certain bond you develop with a group of people when you all have very limited vocabularies. Once a bee stung my foot while I was walking across campus and I spent an embarrassing amount of time wondering whether it would violate my language pledge, but I didn't know how to say bee sting in Chinese. This is the natural context. It's being thrown in the deep end and forced to swim to shore. It's popping open IRB when you have no idea if something's going to work, but you're going to try it anyway because you need some place to start. It's hands on learning. It's incredibly valuable. But in this process, we can't lose the importance of the practiced skill. The practiced skill is the daily tingshi, the hours of classes, the weekly exams, the mountains of homework, the extraordinary amount of time and discipline required to succeed in Middlebury's program, the extraordinary amount of time and discipline required to learn a language. I took this picture in a classroom outside of Beijing. The banner says, ha ha shi xi, ti an tian sheng sheng, study hard, study diligently, and every day you'll see improvement. With time fluency works. With intention, it works faster. It's why we purchase flashcards when we enroll in foreign language classes. It's why multiplication drills exist or at least used to in elementary school classrooms. It's why chess players study famous games. It's why novice chefs use recipes. It's why ballet dancers start every day at the bar. It's why tennis players practice their serves. It's why English departments require majors to memorize the prologue to the cannerbury tales. It's why Zed Shaw calls it the hard way. It's why so many Americans give up on Chinese after the first year. They just can't be creative, so they move on and try to learn something else. With time fluency works with intention, it works faster. One of the most thoughtful essays I've read on this topic was published in Nautilus a few years ago, How I Rewired My Brain to Become Fluent in Math by Barbara Oakley. In the essay, Oakley walks readers through the story of her childhood of failed math and science classes, the childhood of thinking that because she had failed, she must simply not have a knack for success in the STEM fields. After a stint in the Army and an intensive Russian training at the Defense Language Institute, she went back at age 26 to learn remedial algebra and trigonometry. She learned calculus and then she went into a career in electrical engineering. Then she became a professor of engineering. Oakley writes, what I had done in learning Russian was to emphasize not just understanding of the language, but fluency. Fluency of something whole like a language requires a kind of familiarity that only repeated and varied interaction with the parts can develop. I didn't realize it then, but this approach to learning language had given me an intuitive understanding of a fundamental core of learning and the development of expertise, chunking. Oakley continues, chunking was originally conceptualized in the groundbreaking work of Herbert Simon, no relation, in his analysis of chess, relation. Chunks were envisioned as the varying neural counterparts of different chess patterns. Gradually neuroscientists came to realize that experts such as chess grandmasters are experts because they have stored thousands of chunks of knowledge about their area of expertise in their long-term memory. Chess masters, for example, can recall tens of thousands of different chess patterns. This level of true understanding and ability to use that understanding in new situations comes only with the kind of rigor and familiarity that repetition, memorization, and practice can foster. Time after time, Oakley writes, professors in mathematics and the sciences have told me that building well-engrained chunks of expertise through practice and repetition was absolutely vital to their success. Understanding doesn't build fluency. Instead, fluency builds understanding. It's tricky, right? Here we are in a country, in an era, where we are shouting innovation every chance we can get. And innovation stems from creativity and creativity stems from understanding, but how we master that understanding, how STEM teachers in schools across this country are taught to teach the mastery of understanding contradicts so starkly with how we know understanding to work. So what's the algorithm for fluency? Right? We're all developers here. We all write algorithms for a living. It's turned into this horrible buzzword, but you know what I mean. We are responsible for composing the patterns that tell systems explicitly how to do certain things and to not do certain things. And it's our job to study these patterns, to study how best to construct these patterns, to study how these patterns might work best for our specific user groups. My specific user group? I work in news, so pace and speed and fluency are all things I have to think about on a daily basis. I look constantly at what New York Times digital is doing and at what NPR visuals is doing and at what 19-year-olds who pull all-nighters in their college newsrooms are doing. It's easy to feel like a failure, like a person who is just not good enough, who is just not fast enough, who is just not fluent enough. And not only do I work in news, I work in public media, so every line of code I've ever written for Vermont Public Radio is publicly accessible on GitHub. There are still many days when I don't want to push something up, right? Because this is terrifying. It took me a long time to get used to the idea of working so publicly. And some days I'm just a garbage developer. We all are. We all have those days. It can be hard to balance the idea of open-source news. The reporters and editors I work with put a lot of effort into building relationships with sources. They put a lot of effort, it sounds almost silly to say, into not plagiarizing. They try to beat news organizations to a story and sometimes what that means is keeping a story quiet until they're ready to publish. And there are a lot of reasons why journalism needs to work this way. But what that means in a nutshell is that there's an argument to be made about the fact that fundamentally journalism contradicts open-source. Outside of the nutshell, of course, it's a much more nuanced discussion. Pair any two fields together. And though contradictions may be present, oftentimes the similarities outnumber and outweigh. For the 5,000 people who had told me that in order to learn to code, I simply needed to come up with a project and jump on in, there was one person who without any question or hesitation or doubt in his mind offered an additional approach. Sean Duckett out in Colorado, if your ears are burning, thank you. I met Sean through the Turing School where I was a student. He was assigned to be one of my mentors for the entire seven-month program. And I asked Sean early on in the program for book recommendations. He gave me a list of a few different books about thinking algorithmically. He suggested math. He stressed the importance of knowing the history of computer science. And then he told me to read Letters to a Young Chef by Daniel Balu. Obviously, I was surprised at this recommendation, right? It's a book about learning to cook. And Sean knew that I wanted to learn to code. But when I started to read this book, I realized very quickly why Sean had made the recommendation. Letters to a Young Chef is a book about discipline, about teamwork, about having such an inherent understanding of and respect for the work that came before. It's a book about entering a field where there is always more to learn, where innovation and creativity are highly respected, but only when they are backed up by hard work and results. It's a book about mastery, about learning and earning one's place in an industry. It's a book I never on my own would have thought to pick up, and in a sense, then, it's a book about interdisciplinary thinking, a book that highlights what we can learn about software development when we step away from our computers and into kitchens, when we step away from our computers and into newsrooms, when we step into chess tournaments, when we step into foreign language classes, when we step on stage. Learning is hard. If you're looking for a quote from this talk to tweet, that one's only 17 characters. Learning a language is hard because it's tedious. Because if you do it the way my brain does it, it's entirely unrewarding at first. It's hard for somebody who went to art school and who did theater and who reads all kinds of novels, both good and bad. To think about learning something new and having to temporarily give up the right to be creative, dare I even call it a right. Here's something neat, a total aside, nearly half of my art school class is now in STEM. We are in water engineering, in pharmacy, in med school, in science journalism, in botany, in math and in tech. When we were all wearing our tights and leotards and playing the saxophone down the hallways of our school, I don't think that any of us would have predicted that so many would end up in what are generally considered to be such non-artistic fields. But in hindsight, the transitions are clear. We studied empathy. We studied context. We studied creativity. Then we learned the rules of specific systems. Now we work within the constraints of those various systems. We work every day to bend the rules just a little bit to see what kind of creativity unfolds. These pages were at the front of an old sketchbook because I thought, and I still do think that it's important to stare at them every once in a while. Again, these ideas come from Barbara Oakley, fluency before understanding, discipline before imagination. The important thing I remind myself here is that it does not work reliably the other way around. Understanding does not always lead to fluency. And simply having an eager imagination doesn't always pass as a shortcut for putting in the hard work. I've been talking a lot about creativity, big buzzword, right? And it's one that gets big nods of approval. I mean, it's 2016 and nobody's hating on creativity, but also sometimes I feel like nobody actually knows what it means. Again, it's like innovation. This is my least favorite word. I work in public media. I work for an NPR member station and it will not be a shock to anybody when I say that the core group of our listeners is aging. We are told every day that we just need to innovate. And I'll say we're told every day in public media, but also in STEM fields, in education, in healthcare, in government. We're all told that we just need to innovate. Innovation is key. Innovation is crucial. All we need is innovation. And it's all just such bullshit because nobody knows what that means. Innovation appears out of hindsight. It's not something you recognize until you're five miles past the mark. So to me, innovation, creativity, these things both stem from an intense and intimate understanding of a mechanism, of a system, right? It's not just trying something new. Innovation happens when you know something, when you understand something so purely, so innately, so in-depth, when you've reached its fluency and you've become ready to manipulate it, when you've reached its fluency and you've become ready to bend it, to twist it, to bop it, to see what happens when you extend its shape, or when you alter its filter, or when you change its perspective. I've said this before and I will say this forever. The disregard of rote memorization is a failure of imagination. Now let's be explicitly clear here. I'm not saying that rote memorization works best always and for everyone. I'm saying the disregard of rote memorization is a failure of imagination. It's a refusal to trust in brains that are packed with fluency and poised for creativity. It's a refusal to trust in creative people who know far more than they let on, and that's simply because they know far more than they realize. You all might say that study materials don't exist in this industry, and I'll say one, you're wrong, they're hard to find, but they do, and two, more importantly, until there are more of them and until they're more easily accessible, we are going to keep shuffling in the same kinds of people, in the same kinds of learners, who tend to become the same kinds of developers into this industry. We can be more creative than that. We can be more innovative than that. We can learn fluency. We can do more. Thank you. APPLAUSE
 All right, let's go ahead and get started.  Hi, everyone.  Thank you for coming today.  My name is Sarah.  It's a total honor to be here today.  Today, I'm talking about languages.  I'm talking about learning different languages and speaking different languages and using  different languages to write code.  I'm talking about programming languages and about the ways we can program our brains to  learn languages.  I'm talking about fluency and what that means and how to achieve it.  What does it mean to be fluent in a programming language?  And does that mean the same thing as being fluent in a foreign language?  And what does that even mean?  Before I get too deep into this talk, I do have to confess it's been a long time since  I last touched Ruby.  I have a Python job right now.  Truly apologetic for everyone here about that.  I took a Python job for a number of reasons, not the least of which is that the best way  to better understand one language is to start to learn another.  What I'm trying to say is that before I get too deep into this talk, I do have to acknowledge  its irony.  I'm here today telling you all what it means to be fluent in a language I don't know that  well.  That's the premise.  I never know what to say when someone asks me what I do and I say I'm a web developer  and they ask, oh, is that what you studied?  Have you always been interested in that?  The easy answer is to say no.  It's not even close.  I spent six years at an art school where I studied creative writing and then I went to  a liberal arts college where I majored in English and I spent a year and a half writing  a 75-page paper about Ernest Hemingway's childhood.  In college, I did not take a single computer science class.  I did sign up for a calculus class, but after failing the first midterm and having my professor  tell me that I was, in his words, really bad at math and having my dean tell me to, in  her words, drop the class like it's a hot potato, I withdrew.  When I was little, I went to Hebrew school.  This is a photo of me in a Purim parade in a sea of queen esters, dare to be the hamentashen.  I stopped studying Hebrew after my bat mitzvah.  I started to learn Japanese because I was supposed to be an exchange student in Japan.  The trip was all set, but then September 11th happened and the program canceled all international  student exchanges.  I was in a Spanish immersion program in elementary school and then I took Spanish again actually  in high school too, but it was never any good at it, largely because I didn't put in the  effort, but maybe also because it was a public art school.  The one teacher was thrown into a classroom of more than 30 students who together made  up a class of four different language levels.  Then I took Italian my first year of college and much to the chagrin of my mother of Italian  heritage and also probably much to the chagrin of that high school Spanish teacher who had  rooted hard for the romance languages.  I was pretty bad at Italian too.  What am I talking about again?  I'm talking about languages and fluency and how to learn languages and how to achieve  fluency.  So far all I've covered is how I've failed at learning languages.  Throughout college I worked in Boston's Chinatown giving homework help to elementary school  students who spoke Cantonese or Mandarin, mostly Cantonese at home.  These kids, these like six to 10 year olds, they were really struggling with learning  English and it's totally legitimate.  English is such a hard language to learn.  Grammar, sentence structure, vocabulary, spelling, they always used to tell me about how hard  it was to learn.  I don't remember how it came up but one day they joked that I should learn Mandarin and  I said all right, I will.  And they looked at me with that fierce but fleeting curiosity found only in small children  and then they all had a good laugh about it and they said no Sarah, you can't learn Mandarin,  it's too hard.  And that's the story of how I learned Mandarin.  In hindsight I probably should have taken that same approach with a calculus teacher  in college but I don't know, maybe there's something, there's some kind of sweet revenge  that comes from proving a group of your own students wrong that you just don't find when  it's merely the teacher you're trying to impress.  I also used to be a tournament chess player.  This is a photo of me and my brother, he was getting ready for a game and I was giving  him a pep talk I guess.  Our parents house in Oregon is cluttered in the same way that any empty nester house is  cluttered when the two adult children of two adults move across the country and leave behind  old books and backpacks and a cocker spaniel and a closet full of chess trophies.  It's funny the joke when I was, I don't know, six was that I loved going to chess tournaments  because I never had to wait in line to go to the bathroom.  Here I am two decades later at a programming language conference.  The difference of course is that now I would gladly have to wait in line.  I also used to be an actor, call it professional theater, call it community theater, call it  whatever, I did all kinds of weird things.  I did a summertime production of a Midsummer Night's Dream on the Oregon coast.  I did a Halloween production of Night of the Living Dead in an old rundown movie theater.  I did this one actually a few years in a row because I was Judy so if anyone who's familiar  with the movie knows and spoiler to anybody who's not Judy's eaten by zombies halfway  through it and she never comes back as a zombie so the show started at midnight by 1245 I  was dead and I got to go home.  I was in a production called the Apple Tree, a musical, the fictional account of Adam and  Eve.  I did a show called Columbinus about the Columbine shootings.  I did Henry V, I did Footloose, I did the importance of being earnest, I reluctantly  did high school musical.  All this to say, I never know how to respond when someone asks me what I do and I say I'm  a web developer and they ask oh is that what you studied?  Have you always been interested in that?  Again, the easy answer is to say no, it's not even close.  The better answer is to say yes entirely.  I'm giving this talk because what I learned through chess was the importance of technique  and of strategy.  The importance of knowing how to think ahead two, three, five, even ten moves into the  future because in a good game of chess you know that's what your opponent is doing.  I'm giving this talk because what I learned through theater was the importance of improvisation.  The importance of knowing how to make things up when you need to make things up because  your scene partner apparently took an extra long smoke break and has not yet appeared  on stage for your scene.  I'm giving this talk because building software is half strategy and half improvisation and  I do think there are ways to train in both.  I'm giving this talk because I like learning languages.  Because the more I write object oriented code the better I understand Chinese where  each stroke represents one idea, each character is made up of a collection of strokes, each  collection of strokes represents one meaning and each word is formed when these different  collections compose.  I'm giving this talk because the more I study Chinese the better I understand English because  the better I understand English the better I write code.  The better I understand English the more concise my methods, the more straightforward my documentation,  the more thorough my tests.  I'm giving this talk because the more thorough my tests the better I think about creative  writing.  If I expect result A when I run command B I can learn to expect that character C must  have a specific kind of reaction when the plot twists with action D.  When I started to learn to code people told me that the hardest thing I was going to have  to get used to was learning how to Google and I just wanted to be like have you ever  tried to write a story?  I used to write historical fiction.  You misname one character.  Misuse one reference.  Throw one refrigerator into the kitchen of a home that's got to have an ice box out back  and you immediately lose your reader.  You immediately lose your user.  It's all connected.  How to manage and how it plays out and how to learn it and how to build upon it and maintain  it.  How to master its technique and how to think about it in the long term and how to improvise  with it and how to turn it into something that people want to use.  It's a puzzle and fluency is key.  Straight out of college I took my English degree and I moved to Minneapolis where I got a  communications job at a software consultancy.  I liked the people.  I liked the pace.  I liked the puzzles.  At the time I was the only person on the team with a non-dev, non-designed background.  Basically I got the job because I said I do all of the writing that didn't need to be  done in code.  The contracts, proposals, tweets, emails.  The joke was that I programmed in Microsoft Word.  So I was there and I loved it.  They were a completely fantastic team.  But a huge part of my job was to translate what they were talking about and they started  talking about things like rakes and cucumbers and capybaras and forks and somebody named  Hubeaut and bouncing unicorns and hating waterfalls.  Let's all please pause for a moment and acknowledge the fact that we have ridiculous sounding jobs.  I mentioned I work in Python earlier.  Which is fine.  I'm enjoying it.  But don't you dare try to convince me that an egg is a serious name for a serious component  in a Python package management system.  I realized quickly that I needed to learn this language.  And then the more I learned about it, the more I realized that I didn't just want to  write about software anymore.  I wanted to write it too.  I hit Google.  Google.  What's the best first programming language to learn?  Ruby.  That sounds great.  Actually back in Oregon I used to nanny, a little girl named Ruby.  And she was the sweetest, most perfect handful I've ever met.  So I figured like, okay, if that's a good, you know, prediction of how this is going  to go.  At least I understand.  I can prepare myself.  But hey, I figured I've tried to learn languages before.  I can handle another.  So I started to learn Ruby.  I was learning my hashes.  I was learning my instance variables.  I didn't understand why everyone around me was caught up in a heated discussion about  which text editor I was supposed to be using because what did I care?  Approximately 5,000 people told me that the best way to learn to code was by coming up  with a project and jumping on in.  They insisted on this.  This was how it worked.  If you want to learn to code, you simply have to jump on in.  I just had to trust them on this.  But the jumping on in was terrifying for me.  That's me in the bottom right corner, by the way.  I tried to do an accurate emoji representation of diversity in the tech industry.  It looks bad, right?  I mean, I think I nailed it.  But it looks bad.  It is bad.  And we are way past overdue to fix it.  I trusted these people because they were the pros.  The pros were telling me this was the only way to make it happen.  If I wanted to learn to code, I had to jump on in.  And for me, what this meant was that for my first few months of learning Ruby, I had jumped  in to an environment that praised project-based learning.  It was an environment filled with people who knew how to get their hands dirty, as they  say, people who learned best by doing and by building and by making.  Now don't get me wrong.  I like to build things.  You definitely want me on your Jenga team.  But these people made me feel like I was living in a world with signs I couldn't read, and  sound effects I couldn't hear, and hand gestures I couldn't understand.  A world without structure, a map with no key, a city without sidewalks.  I took a step back, and I thought a bit about the people who had told me that in order to  learn Ruby, I, Sarah Simon, simply needed to come up with a project and jump on in.  I thought a bit about this group, and had given the makeup of our industry, it should  be no surprise.  The vast majority of them were men, predominantly white, who had grown up struggling with school  because they were bored in the classes they didn't care about, so they'd fidgeted and  fumbled around until they found code on their own.  And then they taught themselves by coming up with a project and jumping on in.  Now that's cool, right?  There's nothing wrong with that.  It's just not me.  It's not what I need.  And chances are, it's not what a few other people might need either.  Say what you will about the social construct behind me not needing this.  And frankly, please do say it, because to a certain extent it's probably quite revealing,  right?  Reward young boys when they experiment and try things and jump on in.  Young girls tend to be rewarded when they listen and do what's expected of them and  follow the rules.  I live in Vermont now, home of Middlebury College, GoPanthers.  Every summer, Middlebury hosts a full-time language immersion program, isolated on a  small campus in a rural town about an hour south of Burlington.  I did the Middlebury language program a few years ago, summer of 2011.  I signed a language pledge one of my first nights on campus and agreed to speak, listen,  read, and write only in Mandarin all summer.  Speak, listen, read, and write only in Mandarin all summer.  This is serious, all summer.  No breaks, no distractions, no going home at the end of the night.  We were not supposed to call our friends and family.  At Middlebury, classes began every day with a tingshia, a dictation quiz, literally a  listen, write.  The instructor every morning would stand at the front of the class, recite the daily  dictation, and watch as the classroom of students furiously attempted to scribble down what  they'd heard.  We started with vocabulary words and then as the summer progressed, we moved to sentences  and then paragraphs.  It was a quick 10-minute routine at the start of class every morning.  And the tingshia was great because we always knew exactly what to expect.  At the end of each workday, after hours of class and a daily one-on-one with an instructor,  my classmates and I were given a list of words that were all fair game for the next day's  quiz.  The list grew each week.  By the end of the summer, I was memorizing 100 words a night.  This is Mandarin, remember, so not only did I have to memorize the Chinese pronunciation  and the English meaning, but also what the character looked like and how to write it.  And again, because this is Mandarin, of those 100 words, the vast majority were composed  of two or three characters, right, ting, which means listen, shia, which means write, together  tingshia, to mean dictation.  Here's a real photo from one of my old textbooks.  Important vocabulary words here, clearly.  I came up with a pretty good system.  The Chinese school ate dinner from 6 p.m. to 7 p.m.  This was very strict.  The Italian school had the dining hall immediately after us and they would always give us such  glares as we passed each other in and out of the building because they knew that we  had eaten all of the good food and of course we had, but they weren't allowed to communicate  in anything other than Italian and we couldn't communicate in anything other than Chinese.  At 7 p.m. after dinner, I'd find a good spot to sit and I'd pace myself.  I'd focus on one word at a time.  I'd memorize its pronunciation and its meaning.  I'd write the character once while looking at it, again while looking at it.  I'd cover up my cheat sheet and write it once without looking at the character, again without  looking at the character.  When muscle memory took over, I moved to a new word.  I worked in chunks of five.  Every time I mastered the fifth word, I'd go back and repeat the previous five.  At 20, I'd repeat all 20, the same with 40, 60, and so on.  I did this five nights a week for eight weeks.  The summer was exhausting.  It was frustrating.  It was the complete opposite of what so many people say is the best way to learn a language,  but for me, it worked.  There's a certain bond you develop with a group of people when you all have very limited  vocabularies.  Once a bee stung my foot while I was walking across campus and I spent an embarrassing amount  of time wondering whether it would violate my language pledge, but I didn't know how  to say bee sting in Chinese.  This is the natural context.  It's being thrown in the deep end and forced to swim to shore.  It's popping open IRB when you have no idea if something's going to work, but you're going  to try it anyway because you need some place to start.  It's hands on learning.  It's incredibly valuable.  But in this process, we can't lose the importance of the practiced skill.  The practiced skill is the daily tingshi, the hours of classes, the weekly exams, the  mountains of homework, the extraordinary amount of time and discipline required to succeed  in Middlebury's program, the extraordinary amount of time and discipline required to  learn a language.  I took this picture in a classroom outside of Beijing.  The banner says, ha ha shi xi, ti an tian sheng sheng, study hard, study diligently, and every  day you'll see improvement.  With time fluency works.  With intention, it works faster.  It's why we purchase flashcards when we enroll in foreign language classes.  It's why multiplication drills exist or at least used to in elementary school classrooms.  It's why chess players study famous games.  It's why novice chefs use recipes.  It's why ballet dancers start every day at the bar.  It's why tennis players practice their serves.  It's why English departments require majors to memorize the prologue to the cannerbury  tales.  It's why Zed Shaw calls it the hard way.  It's why so many Americans give up on Chinese after the first year.  They just can't be creative, so they move on and try to learn something else.  With time fluency works with intention, it works faster.  One of the most thoughtful essays I've read on this topic was published in Nautilus a  few years ago, How I Rewired My Brain to Become Fluent in Math by Barbara Oakley.  In the essay, Oakley walks readers through the story of her childhood of failed math and  science classes, the childhood of thinking that because she had failed, she must simply  not have a knack for success in the STEM fields.  After a stint in the Army and an intensive Russian training at the Defense Language Institute,  she went back at age 26 to learn remedial algebra and trigonometry.  She learned calculus and then she went into a career in electrical engineering.  Then she became a professor of engineering.  Oakley writes, what I had done in learning Russian was to emphasize not just understanding  of the language, but fluency.  Fluency of something whole like a language requires a kind of familiarity that only repeated  and varied interaction with the parts can develop.  I didn't realize it then, but this approach to learning language had given me an intuitive  understanding of a fundamental core of learning and the development of expertise, chunking.  Oakley continues, chunking was originally conceptualized in the groundbreaking work of  Herbert Simon, no relation, in his analysis of chess, relation.  Chunks were envisioned as the varying neural counterparts of different chess patterns.  Gradually neuroscientists came to realize that experts such as chess grandmasters are experts  because they have stored thousands of chunks of knowledge about their area of expertise  in their long-term memory.  Chess masters, for example, can recall tens of thousands of different chess patterns.  This level of true understanding and ability to use that understanding in new situations  comes only with the kind of rigor and familiarity that repetition, memorization, and practice  can foster.  Time after time, Oakley writes, professors in mathematics and the sciences have told  me that building well-engrained chunks of expertise through practice and repetition was  absolutely vital to their success.  Understanding doesn't build fluency.  Instead, fluency builds understanding.  It's tricky, right?  Here we are in a country, in an era, where we are shouting innovation every chance we  can get.  And innovation stems from creativity and creativity stems from understanding, but how we master  that understanding, how STEM teachers in schools across this country are taught to teach the  mastery of understanding contradicts so starkly with how we know understanding to work.  So what's the algorithm for fluency?  Right?  We're all developers here.  We all write algorithms for a living.  It's turned into this horrible buzzword, but you know what I mean.  We are responsible for composing the patterns that tell systems explicitly how to do certain  things and to not do certain things.  And it's our job to study these patterns, to study how best to construct these patterns,  to study how these patterns might work best for our specific user groups.  My specific user group?  I work in news, so pace and speed and fluency are all things I have to think about on a daily  basis.  I look constantly at what New York Times digital is doing and at what NPR visuals is doing  and at what 19-year-olds who pull all-nighters in their college newsrooms are doing.  It's easy to feel like a failure, like a person who is just not good enough, who is just not  fast enough, who is just not fluent enough.  And not only do I work in news, I work in public media, so every line of code I've ever written  for Vermont Public Radio is publicly accessible on GitHub.  There are still many days when I don't want to push something up, right?  Because this is terrifying.  It took me a long time to get used to the idea of working so publicly.  And some days I'm just a garbage developer.  We all are.  We all have those days.  It can be hard to balance the idea of open-source news.  The reporters and editors I work with put a lot of effort into building relationships  with sources.  They put a lot of effort, it sounds almost silly to say, into not plagiarizing.  They try to beat news organizations to a story and sometimes what that means is keeping a  story quiet until they're ready to publish.  And there are a lot of reasons why journalism needs to work this way.  But what that means in a nutshell is that there's an argument to be made about the fact that  fundamentally journalism contradicts open-source.  Outside of the nutshell, of course, it's a much more nuanced discussion.  Pair any two fields together.  And though contradictions may be present, oftentimes the similarities outnumber and  outweigh.  For the 5,000 people who had told me that in order to learn to code, I simply needed  to come up with a project and jump on in, there was one person who without any question  or hesitation or doubt in his mind offered an additional approach.  Sean Duckett out in Colorado, if your ears are burning, thank you.  I met Sean through the Turing School where I was a student.  He was assigned to be one of my mentors for the entire seven-month program.  And I asked Sean early on in the program for book recommendations.  He gave me a list of a few different books about thinking algorithmically.  He suggested math.  He stressed the importance of knowing the history of computer science.  And then he told me to read Letters to a Young Chef by Daniel Balu.  Obviously, I was surprised at this recommendation, right?  It's a book about learning to cook.  And Sean knew that I wanted to learn to code.  But when I started to read this book, I realized very quickly why Sean had made the recommendation.  Letters to a Young Chef is a book about discipline, about teamwork,  about having such an inherent understanding of and respect for the work that came before.  It's a book about entering a field where there is always more to learn,  where innovation and creativity are highly respected,  but only when they are backed up by hard work and results.  It's a book about mastery, about learning and earning one's place in an industry.  It's a book I never on my own would have thought to pick up,  and in a sense, then, it's a book about interdisciplinary thinking,  a book that highlights what we can learn about software development  when we step away from our computers and into kitchens,  when we step away from our computers and into newsrooms,  when we step into chess tournaments,  when we step into foreign language classes,  when we step on stage.  Learning is hard.  If you're looking for a quote from this talk to tweet, that one's only 17 characters.  Learning a language is hard because it's tedious.  Because if you do it the way my brain does it, it's entirely unrewarding at first.  It's hard for somebody who went to art school and who did theater  and who reads all kinds of novels, both good and bad.  To think about learning something new and having to temporarily give up the right to be creative,  dare I even call it a right.  Here's something neat, a total aside, nearly half of my art school class is now in STEM.  We are in water engineering, in pharmacy, in med school, in science journalism,  in botany, in math and in tech.  When we were all wearing our tights and leotards and playing the saxophone down the hallways of our school,  I don't think that any of us would have predicted that so many would end up  in what are generally considered to be such non-artistic fields.  But in hindsight, the transitions are clear.  We studied empathy.  We studied context.  We studied creativity.  Then we learned the rules of specific systems.  Now we work within the constraints of those various systems.  We work every day to bend the rules just a little bit to see what kind of creativity unfolds.  These pages were at the front of an old sketchbook because I thought,  and I still do think that it's important to stare at them every once in a while.  Again, these ideas come from Barbara Oakley, fluency before understanding, discipline before imagination.  The important thing I remind myself here is that it does not work reliably the other way around.  Understanding does not always lead to fluency.  And simply having an eager imagination doesn't always pass as a shortcut for putting in the hard work.  I've been talking a lot about creativity, big buzzword, right?  And it's one that gets big nods of approval.  I mean, it's 2016 and nobody's hating on creativity,  but also sometimes I feel like nobody actually knows what it means.  Again, it's like innovation. This is my least favorite word.  I work in public media.  I work for an NPR member station and it will not be a shock to anybody when I say that the core group of our listeners is aging.  We are told every day that we just need to innovate.  And I'll say we're told every day in public media, but also in STEM fields, in education, in healthcare, in government.  We're all told that we just need to innovate.  Innovation is key. Innovation is crucial. All we need is innovation.  And it's all just such bullshit because nobody knows what that means.  Innovation appears out of hindsight.  It's not something you recognize until you're five miles past the mark.  So to me, innovation, creativity, these things both stem from an intense and intimate understanding of a mechanism, of a system, right?  It's not just trying something new.  Innovation happens when you know something, when you understand something so purely, so innately,  so in-depth, when you've reached its fluency and you've become ready to manipulate it,  when you've reached its fluency and you've become ready to bend it, to twist it, to bop it,  to see what happens when you extend its shape, or when you alter its filter, or when you change its perspective.  I've said this before and I will say this forever.  The disregard of rote memorization is a failure of imagination.  Now let's be explicitly clear here.  I'm not saying that rote memorization works best always and for everyone.  I'm saying the disregard of rote memorization is a failure of imagination.  It's a refusal to trust in brains that are packed with fluency and poised for creativity.  It's a refusal to trust in creative people who know far more than they let on,  and that's simply because they know far more than they realize.  You all might say that study materials don't exist in this industry,  and I'll say one, you're wrong, they're hard to find, but they do,  and two, more importantly, until there are more of them and until they're more easily accessible,  we are going to keep shuffling in the same kinds of people, in the same kinds of learners,  who tend to become the same kinds of developers into this industry.  We can be more creative than that.  We can be more innovative than that.  We can learn fluency.  We can do more.  Thank you.  APPLAUSE
Learning_Fluency_0_47.png Learning_Fluency_48_107.png Learning_Fluency_108_155.png Learning_Fluency_156_215.png Learning_Fluency_216_395.png Learning_Fluency_396_2267.png Learning_Fluency_2268_3359.png Learning_Fluency_3360_3599.png Learning_Fluency_3600_5735.png Learning_Fluency_5736_6539.png Learning_Fluency_6540_6599.png Learning_Fluency_6600_7523.png Learning_Fluency_7524_7715.png Learning_Fluency_7716_8783.png Learning_Fluency_8784_9827.png Learning_Fluency_9828_10163.png Learning_Fluency_10164_10967.png Learning_Fluency_10968_17555.png Learning_Fluency_17556_18863.png Learning_Fluency_18864_23195.png Learning_Fluency_23196_25811.png Learning_Fluency_25812_27539.png Learning_Fluency_27540_28739.png Learning_Fluency_28740_30551.png Learning_Fluency_30552_32243.png Learning_Fluency_32244_35579.png Learning_Fluency_35580_37331.png Learning_Fluency_37332_39299.png Learning_Fluency_39300_40055.png Learning_Fluency_40056_41483.png Learning_Fluency_41484_42083.png Learning_Fluency_42084_42275.png Learning_Fluency_42276_44039.png Learning_Fluency_44040_44207.png Learning_Fluency_44208_44363.png Learning_Fluency_44364_44398.png