The idea is that I somehow make it sound... too easy? Like it should be obvious. But when it doesn't immediately click, it makes the listener feel stupid.
Dismissive Language
It's common to want to put your student at-ease by saying things like this:
- "You just need to transmogrify the jabberwocky."
- "All you need to do is reverse the polarity on the tachyon emitters."
- "After you call the recursive stochastinator, the rest is easy."
- "Of course, the next step is to liquify the whatchamacallit."
Humans use this kind of language to reassure the person we're talking to. We're trying to say "don't worry, it's not as bad as you think it is!" - the problem is that this usually has the exact opposite effect.
By telling somebody that something should be easy, we're alienating them when it's not easy, which in computer science is quite often. "My teacher told me this should be easy, but I'm really confused, I guess I'm just really bad at it."
Mathematical Microaggressions discusses this language. It's from a math perspective, but it's a good primer.
To improve this, the first thing I'd do is monitor your own language. Maybe record yourself speaking and then listen back to it.
The Process
As others have said, it's also important for you to demonstrate the process of solving a problem rather than jumping straight to the answer.
When teaching something, especially if you have more experience than the topic you're teaching, it can be tempting to lay it all out at once. "To get the total of an array of integers, you'd track the sum in a variable, then use a for loop to iterate over the array and increment the variable by the value at each index."
There are a couple problems here:
- You haven't checked in with your student, so they're probably lost. "I stopped understanding what you were saying about 3 words in..."
- You haven't shown them how you obtained this information in the first place. "How am I supposed to remember all of that?"
- You haven't demonstrated what to do when things go awry, or when they encounter a slightly different problem. "Okay now I've memorized how to compute a sum, but what about an average?"
To improve this, I think it's important to show your student how you got this information, and what steps they should follow when they're facing something similar by themselves. This should also include steps like planning, getting error messages (which is a totally normal part of programming, but is often skipped over when teaching), and debugging.
"Let's start about by coming up with a goal. What do we want to do? Okay, how can we break that down into smaller steps? Now let's focus on the first step. Where can we find more information? Oh, we got an error message, that's totally normal! Let's read through it to figure out what it's saying..."
Shameless self-promotion: I wrote up a little meta-tutorial on this process here.
Engage
I also think it's important to make sure you're meeting students where they live. Specifically, I would make sure that your student is interested in whatever topic you're discussing, or that you at least "brand" the topic with something personal to them. If you're talking about getting the sum of an array of integers, make that the total number of <insert thing your student is interested in>
.
This can all feel pretty tedious, especially if you have more experience than your students. It's tempting to jump to the "interesting stuff" without making sure your students are along for the journey.
But teaching is a different skill than writing code. And like any skill, the best way to improve is through practice.
You could also take a step back and try to find a set of tutorials that you and your daughter can enjoy together, instead of putting all of the teaching on yourself. Coding Train has a bunch of beginner-friendly videos that might be fun.