One of the best things that happened to me in 2014 is that I started to teach. First, a friend from Start Up Chile asked if I would help her organize a RailsGirls event, a weekend for women who wanted to get a taste of coding.
Later, in Chicago winter, a different friend convinced me to come to Dev Bootcamp and mentor beginning coders: fierce, persistent students, burning with the desire to master the strange symbols and unfamiliar logic that would make coding work for them.
One thing I learned is that good teaching starts with a question:
“What do you want to be able to do with this?”
You have to ask this question. If the answer doesn’t appear, you have to tease it out.
Without this knowledge, the piles of abstractions and instructions that make up coding hover close to the edge of meaninglessness. With the answer, every example you create, every problem you assign, can lean toward the goal and infuse the work with meaning.
Interested in the environment? Let’s build classes to model modes of transportation and their energy efficiency. Big fan of Harry Potter? Let’s practice making a Wand class and writing its functions.
One student answered the question this way: “I’m here to get a job.” That can be a noble goal — the bills must be paid. But if we’re going to make teaching and learning enjoyable (and the job search more fulfilling), we should see jobs as just the beginning of a conversation. What would the student do in her dream job?
Teaching blurs into mentoring here. The teacher has a responsibility to show more than the mechanics of the code — it’s the tasks to which we apply the tools that give them meaning. Civic technology, code and art, code and writing, hardware programming, security on the web… A student may come to code looking for a job, but if we can unearth the links to art and politics and cities and science along the way, they will come out with much more to show from their learning.
I’m not in Chicago or Chile anymore. When I moved to the Bay Area to work with Code for America, I didn’t think I’d be teaching much — mostly coding. But that assumption was challenged on Week 2, “Build Week,” where each team prototyped a sample app to set the tone for the year.
I’m part of a three-person team. One of my teammates is a phenomenally smart data scientist. She has coordinated major education research projects at Stanford and often works in R. She wants to learn how to contribute to the web stack and is starting with HTML and JavaScript. My other teammate is a wickedly talented designer whose professional work has been conducted in Photoshop and Sketch. He told me he wanted to sharpen his front-end coding to bring his designs to life.
That’s good, because I would much rather build a web app as a team than by myself.
As a small team, each of us will need to understand the others’ disciplines.
We will need to teach and learn about design processes as we build one together. We will need to teach and learn about data we work with: what it means, where it comes from, how to manipulate it. And all of us will need to understand code, the glue that will bring together data and design in our project.
So there I was, teaching again. Rails, ruby, git, GitHub, forking, branching, committing, pushing. And learning: how to read and parse education-related data; which design tools to use in which situation; where each of us comes from and how we prefer to collaborate.
We’ll be learning from our government partners, too: about their school system and communities, their groundbreaking work with data, their goals and their needs. And we hope to teach them some — about new processes and workflows, agile development and human-centered design.
Teaching is part of the work, I’m finding. Teaching multiplies the power of the team by spreading skills throughout. It brings each person closer to the work and to each other.