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.

7 Comments

  1. This really resonates, thanks for writing it down! I feel the same way: I am more confident also now that I am older that going slow and ruminating on ideas is even just a better idea for long-term efficiency (I’m doing IT/coding, for reference). There is usually so much peer pressure for doing things fast and the collateral damage seems so obvious but few people either recognize or have the will to slow things down and fix the process.

    One of the biggest things that helped me was, when asked the question “do you understand this?” was to answer “No.” But a confident “No,” not an ashamed one. And repeatedly doing so after having things explained. It usually confused people because when they probe me, I can usually answer their questions, but I have come to realize that I usually have different personal criteria for what it means for me to understand something. And it helps to be open and confident in my non-understanding, both with myself and with the people I work with. It usually leads to better understand for everybody (I hope).

    Comment by Matt — 10/3/2014 @ 11:07

  2. This really resonates with the way I struggle towards academic writing. I see my friends who can put together their ideas in a very elegant manner in no time. The words just flow for them. But for me, I absolutely need a dedicated block of time and iterations to get to a professional piece of text. At times I only manage to complete a paragraph after spending more than an hour.

    I can definitely see where the difference comes from. I was not exposed to formal writing during high school or even undergraduate studies. Being able to communicate the ideas in writing was never rewarded or seen as a skill. So, I need to put in this extra time now to polish my writing every now and then.

    Comment by Dippy Aggarwal — 10/3/2014 @ 11:41

  3. The title of your post alludes to this citation:

    Elegance is not a dispensable luxury but a quality that decides
    between success and failure.
    — Edsger W. Dijkstra

    I am reminded how I used to, and to a large degree still work out things and thinking things through on paper before even making a program text: A consequence of not having a computer for the first nearly four years after I begun learning about computers and programming. Imagine my surprise when I learned that the programs actually worked with only minor adjustments due to my incomplete understanding! All your points resonate with me: checking assumptions; working slowly; localize parts of a larger problem; and consider alternatives on several levels.

    Comment by Dennis Decker Jensen — 10/3/2014 @ 16:33

  4. This is also a weak point of coding interviews. They only look for quick, clever answers, rather than thought-out, deep answers. Having worked at a (large) software company, no one ever asked me, “Quick, I need a solution to this problem in the next 2 minutes!” The best coders were the ones who would take the time to think out a thorough solution.

    Comment by Adam G. — 11/3/2014 @ 5:42

  5. As a young student I face this issue on a daily basis. I look around me and everyone’s concern seems like “How to get the “right” answer, How to make sure the approach produces same answers as the test cases…”

    I consider myself slow compared to other students… But when reading your post I saw myself doing the steps that you describe. I spend too much time (compared to other students) trying to think of every possible way of solving a problem when everyone has already gone through implementations.

    This is a GREAT post! It’s always a pleasure to learn from you.

    Comment by AYMEN BEN — 11/3/2014 @ 12:29

  6. Bah! Others would call that “experience”, and the more cynical: aging! I often remind my students that methodology is hard to master, as it is generally so unpleasant and counterintuitive a way of working on a problem (mathematical, logical or philosiophical). And with experience and methodology, comes patience. Only ignorants always try to learn fast, as if knowledge was an easy thing to catch, not to mention to discover!

    Comment by Jean — 11/3/2014 @ 14:52

  7. Thanks for writing this very nice post.
    It makes me feel better about being “the slow one” when everyone on the team is trying to be fast and rushing to get the result.
    And then discovering that there were N important mistakes and relevant bugs.

    Although with some differences, your post reminds me of “the curse of the gifted” described by E.S. Raymond, available for example here
    http://lwn.net/2000/0824/a/esr-sharing.php3

    Comment by Davide — 12/3/2014 @ 15:19

Sorry, the comment form is closed at this time.

« Blog's main page

Powered by WordPress