Helping a kid who made a math mistake
kidswholovemath.substack.com
kidswholovemath.substack.com
Try very hard not to be patronising. Kids struggling with maths can be super sensitive. They can misinterpret a smile as a smirk. If they had the courage to seek help, don't belittle them. For example a phrase as simple as "that's easy" can be a huge burden.
Beware misunderstood questions. If you seek to help by asking them questions be mindful if they do not understand the intent of your question, you may add to their burden not reduce it.
Some set work requires a specific method be shown to be used. It's fine to show them other methods, but you may have to help them project the answer back into the one they will be assessed in.
If they only want debugging, then help them find the bug, the mistranscribed value, the divide by zero, the specific mistake. If they have no insight into the problem then more exploratory help may be useful.
Time out can help. Stress hormones don't make maths any easier.
After all, programming is just a subset of mathematics anyway..
I am quite proud;-) to have once trolled a group composed of mathematics and computer science students with one sentence: "What is computer science? It's that part of mathematics which is of any use." (FTR: I'm a theoretical mathematician turned programmer.) The best part (I think) is that it has some truth to it!
Not sure it is such a sick burn for mathematicians. A lot of these guys see non-usefulness (maths for maths itself) as a badge of pride! :)
It's more of engineering subset. The resulting artefacts are rarely mathematically provable (bugs and Rice theorem).
I'm at the stage where I constantly notice this, which adds to my already non-zero job fatigue. I try to keep my sanity by threatening (myself) to start my own company, but maybe I just need to stop caring and grow up...
In those cases this technique is great! You can guide them to that moment of epiphany, and it is very rewarding and efficient.
Much more commonly it feels like pulling teeth. I think this is because most kinds of misunderstandings and confusions are hard to identify from the inside. For example, when some one learns a new thing that is in contradiction with something else (that they perhaps misremembered, never fully understood, or misunderstood a nuance in a way that was internally consistent) the resulting inconsistency can be very difficult to identify and verbalize. If you can help them identify and resolve it on their own then great- my experience is that when that works it is exhausting and time consuming and that taking a more active role in identifying the conflict is much more productive.
In programming it commonly takes people years to learn enough background context that this method becomes effective. I think it is better to be quick with examples and explanations, there is just too much to know to make this sort of highly examined introspection efficient or effective.
Other times its simply because the student isn't intrinsically motivated to learn the material and this style of teaching involves a lot of emotional labor in order to be effective. Turns out people shut down a little when you ask them to explain their thought process and they feel they should not tell you frankly they care not one wit for Pythagoras or your damned flag pole .
But I tend to do two steps:
1. I’ll tell you what the right formula/process/etc is — as a hint on the problem.
2. If you still don’t get it, I’ll walk through the right steps with you.
I’ve never found it particularly useful to dig into what you have wrong or try to guide you into self-correcting unless the problem is minor (eg, you clearly understand and just need a nudge), you ask, or I’m dealing with someone that has a professional interest and will invest the effort debugging.
I can’t imagine how badly I’d hate it if StackOverflow tried to guide me on some Socratic journey every time, rather than just tell me the correct syntax for the magic invocation of pandas that solves my problem.
I’d probably just quit.
Teaching the "tricks" can help people who already have a mindset for relationships, but often people who struggle with math don't have this, and it takes practicing fundamental methods so they can apply them.
I also found a primer in symbolic logic greatly improved student comfort and familiarity with most other materials. Knowing the formal language and rules of logic and relationships is key to being able to express and interpret mathematics.
This also happens after teaching them how to use their calculators. When they begin to be able to visualize what the approximate bounds are by understanding eg- an expression and what it applies to, it's the difference from someone who only reads word by word and someone who reads with respect to the content of the arc or chapter.
So much of math is contingent on parallels to other subjects, and I've always felt not enough was done to relate to students the similarities between the formal rules.
Ie- when teaching linguistic notation for grammar and syntax, you can have students reduce sentences to expressions (a la Backus–Naur form) and then "solve" for them using, eg- a semantic net. This is often much more comfortable to the numerically adverse, since the logic of language is often understood more intuitively. It can also be taught at any level using simple substitution, parts of speech, etc with the added benefit as a primer for its applications to machine learning.
I had one mentor that was ruthless in forcing me to explain myself and almost pedantic in his insistence on correct vocabulary at all times (programming), but I was also able to interrogate the hell out of him and had practical strategies for identifying and rooting out my own misunderstanding - it was incredibly rewarding but frequently exhausting, half the time we'd wrap up and I'd feel like my voice had grown horse from shouting.
It wouldn't have worked if we didn't trust each other, or if ever I had grown discouraged by my own ignorance, or if he hadn't worked on a compiler team and been able to describe in detail and on command the function of any part of a computer system.
And I suspect most success stories using that method are somewhat like this; deeply personal, probably shouldn't be your expectation or plan A.
The problem is that the student would spend so much time on figuring out their mistakes. If you pass the attention span of children, all they feel is that they made a mistake and feel defeated while getting lectured on something they don’t understand anyway. It is not that easy to find a mistake that you made, even I made mistakes that took me long to find out.
I’m actually in favour of the traditional way, show them the right way and let them try. It is fine to make mistakes, but don’t put focus on the mistakes. Instead focus on good practices. Asking them to figure out their own mistakes/making explanations should be done very sparsely.
And the wonderful thing about exploration is you don't even have to know the subject. You can just keep asking and engaging in a conversation. The student learns. And so do you.
This sets up a self correcting feedback loop for the students learning process AND their correctness checking process. It is brilliant! It is like teaching someone to swim, ride a bike or in this case know that what you know is correct.
Hopefully it will. Although I guess in some cases the issue is reversed parameters to a function, or whatever, where the underlying knowledge is weak (or faulty).
But it's certainly worth a try.
Whenever I’m making a plan, or figuring something out, be it engineering or code or physics or whatever, I rubber duck - that is, I explain what I’m doing and why, verbally, in exhaustive detail, to nothing and nobody in particular (for I do not have a rubber duck), and ask questions of myself that a rubber duck would ask. I often catch a snag where I would otherwise have thought my scheme flawless.
Who knew?
Once you find it - fixing it is easy. Provide simple counterexamples showing why it's wrong, and watch the person solve the problem on their own.
E.g. for multidigit addition instead of adding up units then carry, they are taught to just add everything up. Learning the carry method only happens later.
She can't explain how she does it, and I can't either, it's been a frustrating experience.
I hope I can still be useful when she gets to harder stuff that requires more steps :)
Let's say that the distinction here is how we establish that an answer is correct. A proof is correct if it typechecks (no really). A computation is correct if it faithfully executes the algorithm.
This distinction is more than a little artificial, but in practice it matters a lot.
I’ve also found this method very helpful for proofreading.
There are algorithms (and heuristics) that have been known for centuries to verify (or estimate) check most results from arithmetic to calculus.
It’s as if programmers were not taught how to do logging or assertions.
In math there are two types of errors, not understanding the problem and mistakes. Redoing the work won’t help at all for misunderstanding or lack of understanding and has only a marginal chance of catching the mistake.
But still, typos happen.