I am a lifelong learner, creator, explorer, and tinkerer. This is a collection of my experiences.
As an undergrad, I studied mechanical engineering. After graduating. I returned to visit a friend who was still there. He was getting his masters in a specific area of mechanical engineering. I stopped by his lab to check out what he was doing. After I got an explanation, I left the lab, still not sure what he did. From kindergarten up through graduating college together, we took the same classes. Yet, with all the shared knowledge and vocabulary, he was unable to explain what he did.
I was one of those bad teachers. I failed to connect with my audience. I have also been on the receiving end of bad explanations.
Over the last few years, I have focused on improving my explanations. I have developed skills to become a better teacher. I'll share those tips here.
Pick a technical word that you feel you're an expert on and define it to yourself. For programming, I'd go with "string". For electronics, I'd go with "resistor". Jot down or keep your answer in mind. As you move through each section, think about your answer and how you might adjust it.
In 2016, the D-Lab at MIT invited me to lead a student trip from to Bogota, Colombia to work at a hackspace for 3 weeks. As part of the experience, students developed a workshop they could teach. Several of the students decided to make projects around the Arduino, an electronics platform. None of their projects offered an introduction, instead focusing on applications. At the time, I was teaching an Introduction to Arduino workshop at the Cambridge Hackspace so I decided to translate it to Spanish and teach it.
I speak Spanish but didn't have a good grasp on the vocabulary needed for the workshop. I set out to make flash cards for the words I would need to learn.
One day, I was struggling to find a translation for the term "for loop".
In English, a for loop is a programming term for something that repeats itself a specified number of times. For example, you could consider the process of counting out loud from 0 to 10 to be a for loop. You start at 0, say the number, increase by 1, and keep repeating until you hit 10.
While trying to translate the term, someone asked me - why are you looking up these words? Why not use the words you already know? It was a bit of an aha moment. My Spanish vocabulary was much smaller than my English vocabulary. I definitely didn't know any electronics vocabulary. Without knowing the technical words, in presenting, I would have to search for alternative descriptions. These descriptions would end up being much simpler than using the technical terms.
Imagine I hadn't used the longer definition of a for loop in my workshop. I would have continued to reference the term throughout the rest of the talk. At some point, I would have used the term as part of the definition of another term. Then that term would define another term. And So on.
What started out as my inability to explain a single term has snowballed in to the next term. Then the next. Until it's difficult or impossible to follow the workshop.
I'll start losing the attention of people in the room. For the rest of the workshop, they'll check out mentally. Some of them might blame me for being a bad teacher. That would suck. Even worse are people deciding they're too stupid to understand electronics. They might even abandon the subject altogether. That would suck.
It's probably obvious that you can talk above someone's experience level. However, the opposite is also possible. It's probably not a good idea to give a software engineer a 10-minute explanation of what a for loop is.
How do we avoid these two effects?
Each year, Cambridge hosts a science festival. They invite local organizations to setup tables to share what they're working on. I went one time to represent the Cambridge Hackspace. We filled our table with various projects including everything from electronics to woodworking.
A child, about 7-years-old, approached our table. He was curious about all the flashing lights. One electronics project caught his eye and he asked what it was. Someone else at the table chimed in with an answer. "It's a device for visually measuring decibel levels."
I could almost hear the whoosh as the description passed right over his head. Curiosity killed. He turned and walked away. If the description had been for a fellow maker, it would have been perfect. For a 7-year-old, I would have opted for something like "it lights up when you make noise."
It's important to tailor what you say to your audience. If you already know your audience, problem solved. If not, you will need to learn a bit first. I have found two ways to do this.
The first is passive observation from the context of the interaction. If they're 7 years old, they don't have a degree in electrical engineering. If you're at an International Convention for Electrical Engineering, they have some technical background.
I couldn't use passive observation at the Science Festival since it was open to the public. I needed a bit more of an understanding about their backgrounds. Two questions I would have used first would have been "How much do you know about electronics and/or music?" and "How much of an explanation would you like?"
From these answers, I would then have enough context to give the proper explanation.
Now that you know how to talk to individual learners, how to address a larger audience?
In my Intro to Arduino workshop, I'll get attendees with varying degrees of experience. One attendee wants to learn how to include lights in the clothing they make. They have no technical background. Another attendee works as a mechanical engineer. They took one or two electronics courses in college.
To reach everyone, I like to keep my workshops open ended and cater to each level of experience. I created the material so that the slowest learner would still be able to enjoy the entirety of the workshop. For those that moved faster, I added extra challenges. As an example, in the first section, the goal was to make a light blink on and off. For those that finished early, I'd challenge them to make multiple lights blink together.
"Do you understand?" is a bad question to ask. The receiver of the question will most likely say yes. This yes will either mean "Yes, I understand" or "Yes, I don't understand but if I say no I'll look dumb".
Remove "you" from the question and rephrase it - "Did I explain that well?".
Even better would be to ask open ended questions to see how much they understood. From here, you can try and rephrase whatever topic you're on to help them better understand.
A few years ago, I attended IDDS, a conference in Cali, Colombia hosted by MIT's D-Lab. There was lots of down time in the evenings. Some nights were organized around random presentations on subjects of our choosing. I decided to do an Introduction to Photography. This was something I had never done before.
At the end of the talk, I asked an attendee I was close with what he thought. He told me I skipped the introduction and dove right into the technical deep-end. I talked about aperture, shutter speed, white balance, ISO, noise, and other complex subjects. All in the span of 10 minutes. It took me about 30 hours to learn those concepts well. I lost everybody the moment I opened my mouth.
I realized that I hadn't gauged my audience very well.
I took the feedback to heart and set to improve on it. This past week, I gave another Introduction to Photography talk. This time, instead, I focused on the basics and tried to appeal to everyone.
Several attendees gave me positive feedback and enjoyed my presentation. Much better than losing everyone from the start. Keep that in mind the next time you're teaching somebody something.
Think back to a time that you got lost in a conversation for whatever reason. That's exactly what it feels like to be on the receiving end of a bad explanation.