Learning Fluency
Adapted from a talk at the 2015 Burlington Ruby Conference and reworked in November 2016 for RubyConf 2016.
Hi, I am Sara. That’s me in the hat.
I like thinking about languages. I like thinking about learning different languages and speaking different languages and using different languages to write code.
I like thinking about programming languages and about the ways we can program our brains to learn languages.
I like thinking 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?
This is called Learning Fluency and I want to be clear: I’m not unaware of its irony. It’s been a long time since I last touched Ruby, and yet I wrote this originally as a talk for a Ruby conference. I wrote this originally to tell you all what it means to be fluent in a language I still 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. Then, I went to a liberal arts college, where I majored in English. I wrote my thesis 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 really little, I went to Hebrew school. This is a photo of me in a Purim parade. In a sea of Queen Esthers, dare to be the hamantaschen.
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 9/11 happened and the program canceled all international student exchanges.
I was in a Spanish immersion program in elementary school, and then I studied Spanish again actually in high school, too. I was never any good at it, though, largely because I didn’t put in the effort but maybe also because it was a public art school and the one teacher was thrown into a classroom of more than 30 students who together made up a class of four different language levels.
And then I took Italian my first year of college, and much to the chagrin of my mother of Italian heritage and also probably to the chagrin of that high school Spanish teacher who had rooted hard for the romance languages, I was pretty bad at Italian, too.
I spent a few years working for an after school program in Boston’s Chinatown, teaching elementary school students who spoke mostly Cantonese but sometimes Mandarin at home. These six to 11 year olds, they all used to talk to me about learning English. They used to tell me about how hard it was to learn grammar and sentence structure, vocabulary and spelling.
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. Then they all had a laugh about it and said,
“No, Sara. You can’t learn Mandarin. It’s too hard.”
And thus, the story of how I learned Mandarin.
In hindsight, I probably should have taken that same approach with the calculus teacher in college. Maybe there’s something, though, there’s just a 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 me and my brother. He was getting ready for a game and I was giving him a pep talk, I guess.
It’s funny. The joke when I was six was that I loved playing in chess tournaments because I never had to wait in line to go to the bathroom. Two decades later, I attend programming language conferences. The difference, of course, is that now I would gladly have to wait in line.
I also used to be an actor.
Call it community theater, call it professional 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 movie theater. I did that one actually a few years in a row because I was Judy. Anyone who’s familiar with the movie knows that Judy is eaten by zombies halfway through it, and she never comes back as a zombie. The show started at midnight, so by 12:45a, I was dead and I just got to go home.
I was in a production called The Apple Tree, a musical, the fictional account of Adam and Eve. I was in a production called columbinus about the Columbine shootings. I did Henry V. I did Footloose. I did Titus Andronicus. 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 writing this piece 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 10 moves into the future, because in a good game of chess, you know that’s what your opponent is doing.
I’m writing this piece 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 onstage for your scene.
I’m writing this piece because building software is half strategy and half improvisation, and I do think there are ways to train in both.
I’m writing this piece 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 writing 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 straightforward my documentation, the more concise my methods, the more thorough my tests.
I’m writing 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 a lot of historical fiction. You misname one character. Misuse one reference. Throw one refrigerator into the kitchen of a home that’s got to have an icebox out back, and you immediately lose your reader. You immediately lose your user.
It’s all connected. Language and how it plays out and to how to learn it and how to build upon it and maintain it 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-design background. Basically, I got the job because I said I’d do all of the writing that didn’t need to be done in code—the copywriting, contracts, proposals, tweets, emails. The joke was that I programmed in Microsoft Word.
I was there, and I loved it. They were a 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 Hubot and bouncing unicorns and hating waterfalls.
On paper, Ruby developers have ridiculous sounding jobs.
I quickly realized 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 turned to Google.
“Google, what’s the best first programming language to learn?”
“Ruby.”
Easy enough. 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. It was how it worked. You just jump on in. You come up with a project, and you figure out how to build it.
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. I mean, I think I nailed it, but it looks bad. It is bad, and we’re way past overdue to fix it.)
I trusted these 5,000 people because they were the pros. The pros were all telling me that this was the only way to make it happen. If I wanted to learn to code, I simply had to jump on in. I simply had to trust them on this.
For me, what this all meant was that for my first few months of learning Ruby, I had jumped into 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 learn best by doing, by making, and by building.
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 city without sidewalks. A map with no key.
I took a step back and thought a bit about the people who had told me that in order to learn Ruby, I, Sara Simon, simply needed to come up with a project and jump on in. I thought a bit about this group and given the makeup of our industry, it’s no surprise—
I noticed that 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 just jumping on in.
Now, that’s great. Right? There is absolutely 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 need, either.
Say what you will about the social construct behind me not needing this. Frankly, please do say it, because to a certain extent, it’s probably quite revealing—
Young boys tend to be rewarded 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, home of Middlebury College. Go Panthers. Every summer, the school hosts a full-time language immersion program isolated in the town of Middlebury about an hour south of Burlington.
I did the Middlebury Language Program a few years ago, the 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. This is serious. All summer. No breaks. No distractions. No going home at the end of the night. Legitimately all summer.
At Middlebury, classes began every day with a 听写 tingxie, a dictation quiz. Literally a listen write.
听写 tingxie, dictation
听 ting, to listen 写 xie, to write
The instructor would stand at the front of the class every morning, recite the daily dictation, and watch as the classroom of students furiously attempted to scribble down what they had heard. We started with vocabulary words and, as the summer progressed, moved to sentences, then paragraphs. It was a quick ten minute routine at the start of class every morning.
The tingxie was comfortable, because I always knew 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. 听写 tingxie, listen write, to mean dictation, for example.
Here’s a real photo from one of my old vocabulary lists. I can’t remember if this was a Middlebury list or not. Regardless, it gives you an idea of what I was working with. It also showcases the world’s most confusing collection of vocabulary words.
At Middlebury, I came up with a pretty good system. The Chinese school ate dinner from 6p to 7p. At 7p, I’d find a good spot to sit. I’d pace myself and focus on one word at a time.
I’d memorize its pronunciation and meaning. I’d write it once while looking at the character, again while looking at the character, I’d cover up my cheatsheet 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 it worked.
There’s a certain bond you develop with a group of people when you all have limited vocabularies. Once, a bee 🐝 stung my foot while I was walking across campus, and I spent an embarrassing amount of time wondering whether I’d violate my language pledge by saying,
“Bzzzzzzzzzzzzzzzz.”
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 somewhere 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 tingxie. 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:
好好学习，天天向上
Study hard, study diligently, and every day you will see progress.
With time, fluency works. With intention, it can work 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 games. It’s why novice chefs use recipes. It’s why musicians practice scales. It’s why ballet dancers start every day at the barre. It’s why tennis players practice their serves. It’s why English departments require majors to memorize the prologue to The Canterbury Tales.
It’s why Zed Shaw calls it The Hard Way. It’s why so many native English speakers give up on Chinese after the first year.
They just can’t be creative, so they move on and try to learn something else.
One of the most thoughtful essays I’ve read on this subject was published in Nautilus a few years ago. How I Rewired My Brain To Become Good At Math, by Barbara Oakley.
In the essay, Oakley walks readers through the story of her childhood of failed math and science classes. A childhood of thinking that because she had failed, she must simply not be set up for success in the STEM fields. But after a stint in the Army and intensive Russian training at the Defense Language Institute, she went back at age 26 to learn remedial algebra and trigonometry. Then, she learned calculus, went into a career in electrical engineering, and became 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 in his analysis of chess — chunks were envisioned as the varying neural counterparts of different chess patterns. Gradually, neuroscientists came to realize that experts such as chess grand masters 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-ingrained chunks of expertise through practice and repetition was absolutely vital to their success. Understanding doesn’t build fluency; instead, fluency builds understanding. In fact, I believe that true understanding of a complex subject comes only from fluency.”
It’s tricky, right? Here we are, in a country and 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 nation 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? As developers, we all write algorithms for a living. It’s turned into a horrible buzzword, but you know what I mean. As developers, we are responsible for composing the patterns that tell systems explicitly how to do certain things and how not to do certain things. 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, speed and fluency are all things I have to think about on a daily basis.
I look constantly at what The New York Times digital team is doing and at what NPR Visuals is doing and at what nineteen-year-olds who pull all-nighters in their college newsrooms are doing. It’s easy to feel like a failure. Like a person who’s just not good enough. Who’s just not fast enough. Who’s just not fluent enough.
And not only do I work in news, I work in public media, so every line of code I’ve written so far at Vermont Public Radio is publicly accessible on GitHub. It took me a long time to get used to the idea of working so publicly. There are still many days when I don’t want to push something up because I know it’s garbage code. Because let’s be honest, some days I’m just a garbage developer. We all are.
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 other news organizations to a story, and sometimes what that means is keeping a story quiet until they’re ready to publish.
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 complex discussion.
Pair any two fields together, and though contradictions may be present, oftentimes the similarities outnumber and outweigh.
For the 5,000 people who 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, 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.
I asked Sean one day 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 Boulud.
Obviously, I was surprised at this recommendation.
It’s a book about learning to cook and Sean knew that I wanted to learn to code. When I sat down to read it, though, I learned quickly why he 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’s 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. Most importantly, 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 languages classes. When we step onstage.
Learning is hard.
Learning a language is hard because it is 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 starting to learn something new and having to temporarily give up the right — dare I even call it a right — to be creative.
An aside: Nearly half of my art school class is now in STEM. We are in water engineering, in pharmacy, in medical school, in science journalism, in botany, in math, and in tech. When we were all wearing tights and leotards and playing our saxophones down the hallways of our school, I don’t think any of us would have predicted that so many would end up in what are generally considered to be such non-artistic fields.
In hindsight, though, it’s so clear:
We studied empathy, context and creativity, and now we all work within the constraints of various systems. We work every day to bend the rules just a little bit to see what kind of creativity unfolds.
These pages are at the front of my sketchbook because I think it’s important to stare at them every so often. Again, these ideas come from Barbara Oakley:
The important thing I remind myself here is that it doesn’t work reliably the other way around.
Understanding does not always lead to fluency, and simply having an eager imagination does not always pass as a shortcut for putting in the hard work.
I’ve been talking a lot about creativity. It’s a big word, and it gets some big nods of approval. It’s the 21st century, right, and nobody’s hating on creativity but sometimes I also feel like nobody actually knows what it means.
It’s like innovation. Innovation is my least favorite word. I work in public media. I work for an NPR member station. It won’t be a shock to anyone when I say that our core group of listeners is aging. We are told every day―not only in media, I’ll say, but also in the tech industry, in all of STEM, in education, in government, everywhere―we are 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 it means. True innovation appears out of hindsight. It’s not something you recognize until you’re five miles past the mark.
To me, creativity and innovation? These things stem from an intense and intimate understanding of a system.
Innovation isn’t just trying something new. It’s 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:
or when you
or when you
I’ve said this a million times before, and I’ll continue to say it:
The disregard of rote memorization is a failure of imagination.
I want to be explicitly clear here. What I’m not saying is 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 the tech industry and I’ll say:
- You’re wrong. They’re hard to find but they do.
- Until they’re more easily accessible and until there are more of them, we are going to keep shuffling in the same kinds of people and the same kinds of learners who tend to become the same kinds of developers into the industry.
We can do better. We can be more creative than that. We can be more interesting that that.
We can learn fluency.
We can do more.
