Lessons from Being a TA
A routine question that I received while at Launch School was, “How did you become a TA?” Looking back, it was a favorite part of my time there and I loved every second of it. Still, my answer to “how” is a bit of a let-down: it just kind of happened.
Despite coming from an education background, I had no aspirations to be a TA. I was switching careers after all, not trying to blend them. But I knew that studying with, helping, and teaching others was the best way for me to learn, so it was only a matter of time. Chris noticed and the rest is history.
When I was a high school English teacher, I’d tell aspiring teachers that I learned 75%+ of what I knew by just being a teacher. I had great college professors who gave me an excellent example, but even they would say, you’ll figure it out in your own classroom.
Reflecting on my time as a TA at Launch School, I realize there are truths that transcend high school English and Ruby fundamentals. They’re lessons on how to share information in countless contexts. Here are a few.
Good Analogies Demystify
I’m a sucker for a good analogy, and I strongly believe that the simpler you can explain something, the better you understand it. Analogies are an excellent vehicle for that to be proven.
The purpose of analogies and parables intersect: use something familiar to explain something that is unfamiliar.
When teaching Ruby fundamentals, two of my most common analogies were:
Variable shadowing is like the ripples caused by a stone hitting the water. The rings start close and work their way outwards. When you ask Ruby to use a variable called
name, it will look closest first. If it can’t find it, it’ll keep looking further and further away until it finds
name or until it hits its limit (depends on the context). If variable
name is found in the first ring, it doesn’t keep looking for it (even if it exists in outer rings). So you have to ensure the closest ring with
name is the
name that you want.
Parameters are your brother and your friend. You can have someone in your life that is both your brother and your friend. Depending on the context, you’ll refer to him as one or the other. When defining methods or blocks, you’ll refer to them as parameters. But inside the definition or the invocation, you’ll refer to the same thing as local variables. Same element, different hat, depending on the context.
Explaining pointers involved a lot of hand motions and fingers pointing in different directions. That’s one of my favorites to explain.
It’s not only important to be a software engineer with precise language, but it is important to teach with precise language.
When teaching analogies and metaphors to a freshmen English class, it’s important to say they’re distinguished by how the comparison is done. Did you say “like” or “as” or did you say it just “is” something? Katy Perry’s “Firework” was one of the examples on the board, yes. (the chorus is a metaphor btw)
I love line numbers in programming because they allow you to be precise without giving away the answer. “What is the purpose of line 4?” “What is happening on line 2, and what is the purpose of the first and second word there?”
When explaining, then, you have the responsibility to be just as precise. Output is not the same as return value, what a block evaluates to is not the same thing as what it returns, and using a method isn’t the same thing as understanding what it does.
When people ask what words mean, explain it as simply and succinctly as possible. Answering exhaustively rarely helps people in the long run.
What is the return value? In Ruby, it’s what is being returned implicitly or explicitly. It’s what would be printed to the console if you were to print the method invocation, the variable, etc.
What is the output? In Ruby, it’s what is printed to the console. Sometimes it’s nothing because sometimes nothing is output.
Teach with Respect
In my first years of teaching high school, I was told to toughen up and be harsher otherwise the students would walk all over me. I tried a different approach. I was respectful before they were respectful.
Don’t misunderstand — I didn’t let them push me around. I mostly ignored their rude comments or asked them why they thought that was a good approach. I didn’t belittle or disrespect in response. Did it take time? Absolutely. But they felt respected (because they were) and they respected me in turn, even when they didn’t like how long the essays were, thought my standards were too high, or they didn’t like the book we were reading.
I’d say it’s easier to respectfully teach adults, but I’ve also been the recipient of some pretty condescending instruction as an adult. A lot of it comes down to tone of voice and word choice, but I think that is often shaped by the belief of the teacher. If you think the person you’re teaching is dumb, you’re probably going to have a hard time hiding it.
A teacher is not a better person than a student. They’re not necessarily smarter than the student, wiser, or more experienced. They just have more knowledge about something. Not even everything. Keeping that in mind brings a level of humility to teaching. It brings us closer to reality and makes it easier to teach with respect.
Say “I Don’t Know”
The vast majority of people don’t hold that sentence against you. They respect it. Nobody knows everything, so it’s okay to not pretend to be the exception.
I believe all good teachers are teachable. There are plenty of people who are better at sharing information than receiving it; but that automatically limits their capacity to teach, because it limits their capacity to learn.
I still love teaching and I’m sure I always will. Working with others, exchanging information and ideas, is one of the most challenging and rewarding ways to learn and grow. I’m intensely grateful for my time as a TA at Launch School. LS community, thank you for being who you are. You’re a gift to be a part of.