As a young student, I was undisciplined. Though I did well in mathematics, I often couldn’t be bothered to write down clean computations. I would do the work mostly in my head, and I would quickly jot down the answer. Such a strategy serves you well early on during your education. However, later on, it becomes a handicap.
In part, I blame my schooling. We reward kids that are fast. Who is the best math. student in the class? Whoever can solve the problem fastest. That is entirely wrong. Instead, the best mathematician is whoever can solve the most difficult problems. While speed matters, the ability of scale up with difficulty is much more important. Schools often teach the wrong lesson.
When working on a difficult problem, the problem space often exceeds the capacity of your short-term memory. Though some have better short-term memory than others, the really difficult problems are likely to exceed the memory capacity of any mortal. At that point, method trumps raw speed.
It is useful to think of your brain as a CPU. Modern CPUs are very powerful by historical standards, but they still have very limited memories. What sets apart the best software is how it is able to optimize memory usage so that the CPU does not have to remain idle.
I was never quite able to unlearn my bad habits as a mathematician when working on paper. Part of it is the medium. Though I make extensive use of pen and paper in my daily life, it is mostly for quick collection of simple facts. I never learned to use pen and paper to go deep in my ideas. Instead, at an early age, I learned programming. And it is through a computer that I learned to organize my thoughts.
I am not quite alone in my messiness. Van Emden had a post this week-end where he reports that the famous physicist, Boltzmann, was unapologetically messy as a mathematician. He felt that elegance was a luxury.
But once you see your brain as a CPU, then a more practical question arises. How do you organize the problems to maximize the efficiency of your brain…
I think I am smarter than when I was 22. I can solve more difficult problems more reliably. I am a better software programmer. I am a better mathematician.
- I go slowly. Instead of rushing at the end, I try to make sure I really understand the problem. I try to see its natural components. I divide up the problems in small, manageable parts (that fit in my short-term memory).
This is where my students most often go wrong. They are trying to go too fast. To try to teach them to go more slowly, I often simply ask them questions about the problem.
- As much as possible, I work locally. That is, I work on parts of the problem that only require a few facts. I only move to another part of the problem once I am done with the current part.
When I was younger, I would eagerly jump from one part of the problem to another, hoping for a breakthrough. Unconsciously, I was hoping for a flash of insight. I took me years to understand that insights are more likely to come if you focus on a narrow issue.
- I spend a lot of time contemplating alternatives. When I was younger, I would latch on the first credible approach I could think of. Why solve the problem in two different ways when only one way will do? I have since learned that comparing different approaches, and understanding why one is better than other, is often how you derive the most important insights.
- I spend almost as much time checking my answers than deriving them. I have since learned that even “obvious” facts should be triple checked. I cannot recall how many times I got “stuck” on a problem because of a faulty assumption, or faulty derivation.