Q&A: How to Help Bright Students Articulate Proofs

Cross-posted from here.

Question

Seeking guidance on how to assist students who possess a solid grasp of problem-solving concepts, allowing them to intuitively arrive at solutions, yet encounter difficulties when it comes to communicating their understanding through formal proofs and written formats.

These students exhibit a deep comprehension of the underlying principles and can often visualize the solution or approach to a problem. However, they face challenges in articulating their ideas in a structured and rigorous manner. It is crucial to help these students bridge the gap between their intuitive problem-solving abilities and their ability to express their reasoning formally.

Answer

I’ve worked with some of these types of students in the past. One trend I noticed was that these students often have experience with coding, which they tend to enjoy and excel at (since the computer tells them exactly how precisely they have to specify their ideas and will error in obvious ways if they’re not being precise enough or they’re skipping over important nuances).

When teaching proofs to students who fit this trend, I’ve had success leaning on analogies to coding as much as possible as a way to get through to them.

• I tell them to think of the proof as a program that runs in mathematicians' brains. The theorem being proved is like a new "software feature" that can be used in the future, and the proof is like the code supporting that feature. The goal is to "install" this theorem in somebody else's mind by having them "run" the proof.
• When you're coding at your computer, as long as you've got the right intuition/principles in mind, you can start with a vague, imprecise program and then get it working by running it, getting an error, and tightening up the code in the place where the error occurred. But you don't have an unlimited instant feedback loop like that when you're writing a proof. With human-to-human writing, you generally have one shot, and you have to make that shot count. So you need to be completely explicit with every step of the proof. It's like the code that you're writing is going straight into production, without testing beforehand.
• As a general rule, if someone could ask "why" or "how" about some assertion in your proof, and the answer to that question is not already contained in your proof, then an error is going to occur when that person tries to "run" the proof (and you won't be around to fix the error). For instance, if you have a mental image that makes an assertion obvious in your mind, you need to communicate that mental image in your proof so that it can be used by the reader as well. Otherwise it's like your program is attempting to import code from a package that is not installed in the environment where the code is running.