Learning Fluency:

an essay

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 and can we really achieve it and 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. I’m here to tell you all what it means to be fluent in a language I only started to learn last year. It’s an absurd premise, but I’m going to run with it.

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 art school, where I studied creative writing, and then I went to a liberal arts college where I majored in English and spent an entire year and a half studying 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. I don’t know if you all like hamantaschen, but I do.

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 Italian cousins and also probably of that high school Spanish teacher who had rooted hard for the romance languages, I was pretty bad at Italian, too.

So what is this about again? I’m writing about languages and fluency and how to learn languages and how to achieve fluency, and so far all I’ve covered is how I’ve failed at learning languages.

I spent a few years working for an afterschool program in Boston’s Chinatown, teaching elementary school students who spoke Cantonese or Mandarin or both at home. 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.”

They looked at me for a second 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, Teacher 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 five was that I loved playing in chess tournaments because I never had to wait in line to go to the bathroom. Two decades later, here I am attending tech conferences. The difference is that now I would very 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 abandoned movie theater. I did that one actually a few years in a row because I was Judy so, as anyone who’s familiar with the movie knows, Judy’s eaten by zombies halfway through it and she never comes back as a zombie. The show started at midnight, so by 12:45am I was dead and I just got to go backstage and take a nap.

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 very 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?”

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 knowing how to think ahead two, three, five, even ten moves into the future. 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 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 really do think there are ways to train in both.

I’m writing this piece because I really like language. 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, then why should the reader accept that character c performs 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?”

You misname one character. Misuse one reference. Throw one refrigerator into the kitchen of a home that’s really got to have an icebox out back, and you immediately lose your reader. You immediately lose your user.

Really, 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 all a puzzle.

And fluency is the key.

So, hi. I’m Sara. I used to work at a Rails shop in Minneapolis.

I liked the people. I liked the pace. I liked the puzzles. 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 Ruby or JavaScript — the copywriting, contracts, proposals, tweets, emails. The joke was that I programmed in Microsoft Word.

So I was there, and I absolutely 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 parents and children and somebody named Hubot and bouncing unicorns and hating waterfalls.

On paper, software developers have really strange 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.

Sara: “Google, what’s the best first programming language to learn?”
Google: “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 really bad. I mean, I think I nailed it, but it looks really bad and we really need 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 learned 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 all I’ve ever learned from doing and making and building is how not to do or make or build. I never should have started that tower with those green and blue blocks. They didn’t match. They were not stable.

These 5,000 people made me feel like I was living in a world built on green and blue blocks. 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 building with no foundation.

I took a step back and thought a bit about the people who had told me that in order to learn Ruby, I simply needed to come up with a project and jump on in. I thought a bit about this group and, hey, 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 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 cool. Right? There is absolutely, 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.

We reward young boys when they experiment and try things and jump on in; we reward young girls when they listen and do what’s expected of them and follow the rules.

I live in Vermont, home of Middlebury College. The school hosts a full-time summer language program isolated in the rural town of Middlebury about 45 minutes 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, recite the daily dictation, and watch as the classroom of students furiously attempted to scribble down what they 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.

I loved the tingxie 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 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 6pm to 7pm. At 7, I’d find a good spot to sit and then 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 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 I’d violate my language pledge by saying,


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.

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 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.

A few weekends ago, when I was supposed to be preparing this all as a talk for the 2015 Burlington Ruby Conference, I did some serious procrastinating. I watched the entire new season of Orange is the New Black, and then I decided to do something a little more productive.

I went on a walk.

I took a really long walk through and around Burlington. Podcasts are really great when you’re on this kind of walk.

I was listening to Reply All — a Gimlet production, a podcast about the Internet.

It’s a pretty reliably interesting podcast and what I like especially about it is that its episodes are really short, so when I’m out trying to half procrastinate and half exercise, it’s easy to be like,

“Oh, just one more episode. I’ll just keep going and do one more.”

One of the episodes I listened to on that walk was the episode with Paul Ford. You may know him from Twitter as @ftrain. You may know him as the author of the really long “What is Code” article for Bloomberg. Now, you can also know him as the guy who was on the episode of the podcast while I was on a walk.

This episode specifically was about Paul’s anxiety. He’d had this paralyzing anxiety about so many things in his life, and so he came up with a method to deal with it. I’m paraphrasing the podcast here, but basically he built a bot that was programmed to understand all of his fears and anxieties, and then every day, sometimes multiple times a day, it emailed him these nasty, almost degrading emails.

At first, I thought he was just bullying himself into addressing his issues, but I really liked the way he explained it.

He said that we’re so used to getting spam emails all the time. Now all of a sudden, in a spam folder filled with emails about various Ponzi schemes or Viagra alternatives was an email about how terrible of a person he was. How he’s a waste of a human being. And then he treated that email with the same amount of ludicrous falsehood as its companion spams.

It’s genius.

Anyway, the whole thing got me thinking about almost a kind of gamification. About a daily practice that we could bully ourselves into. An email sent to us every day or even multiple times a day reminding us to do certain things or to not do certain things.

GitHub uses green squares.

Codecademy sends emails when you’ve kept up a good streak.

I’ve never used Duolingo, but they have a little owl at the top right corner of their homepage.

I don’t know what an XP Goal is, but it sounds important.

I do think there’s something about gamification that works. Right? It’s everywhere, so it definitely works, but there’s something about it that might come in handy when trying to learn a language.

It might be in the routine. In setting an expectation that there is work to be done and that more often than not, a little concentrated work here, a little concentrated work there is a more sustainable and efficient and productive method than a lot of willy-nilly work throwing things together all at once.

I took this picture in a classroom outside of Beijing.

The banner says:


Study hard, study diligently, and every day you will see progress.

I work in news now, so pace, speed, and fluency are all things I think about on a daily basis.

There have been times when a story that really should have had a big web build didn’t get a big web build because the deadline hit. Because I dropped the ball. Because web development is hard and tedious and time consuming.

I look constantly at what The New York Times interactive 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.

But I feel lucky, because truly, one of the fantastic parts about working in public media is that it’s called public media for a reason.

(Aside: Melody Kramer has started a Media Public, now, too. Drop everything. Stop reading this. Go check it out.)

Every line of code I’ve written so far at Vermont Public Radio is publicly accessible on GitHub. You can pull it up right now and see all of the mistakes that I’ve made and all of the tests that I haven’t written.

(I’m so sorry, Ruby community. I’m so ashamed. I’m so sorry.)

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 really just a garbage developer.

The scarier thing, though, scarier than pushing up garbage code, is the idea of working in a world where people don’t share their code. Sometimes it’s garbage and that’s fine, but if we never share, we never move forward. We never get better.

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. Finally when I sat down to read it, though, I learned very 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.

(If you’re looking to tweet a quote from this piece, that one’s only 17 characters.)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

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.

(Another 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:

The important thing I remind myself here is that it doesn’t really 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 2015, right, and nobody’s hating on creativity but sometimes I also feel like nobody quite knows what it means.

To me, creativity stems from an intense and intimate understanding of a mechanism.

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 — eager, even — to manipulate it.

To bend it.

To twist it.

To Bop It.

To see what happens when you

e x t e n d ⌯ i t s ⌯ s h a p e

or when you

alter its filter

or when you

← evitcepsrep sti egnahc ←

I’ve said this a million times before, and I’ll say it forever:

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 1) You’re wrong. They’re hard to find but they do. And 2) Until they’re more easily accessible and until there are more of them, we’re 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.