Derman and Wilmott:
Simple clear models with explicit assumptions about small numbers of variables are … the best way to leverage your intuition without deluding yourself.
— “Financial Modelers’ Manifesto,” January 7, 2009, Posted at http://www.wilmott.com/blogs/paul/index.cfm/2009/1/8/Financial-Modelers-Manifesto , accessed 20111214. (Forum discussion at http://www.wilmott.com/messageview.cfm?catid=3&threadid=67869)
Jim Coplien writes:
Failure can be your friend.
…
The very nature of kaizen [dpb: 改善] in Japanese culture is rooted in an introspective state of hansei [dpb: 反省]: of deep reflection and of identifying with the problem. Only then are we truly in a position to understand how we can relate to solving the problem, either by removing its cause, or working with others to do so, or to embark on a program of continuous practice to remove the problem. Also intrinsic to kaizen is that improvement comes not so much from solving the problem, but from going to the next level to remove its very cause. There is lasting value in fixing a software bug. There is broad, lasting value from improving the process to diminish the chances that such kinds of bugs can ever arise again. But we need those bugs, those problems, to trigger the process changes. In that sense we celebrate the opportunity that presents itself when a problem arises, though we soberly assess our place in that system.
Speaking of intentional practice, periodic reflection is a good thing. Explicitly take time to reflect on opportunities to improve — as an individual, a family, a team, or as a corporation. It takes trust and courage, but it builds trust and courage as well. William James said “The error is needed to set off the truth, much as a dark background is required for exhibiting the brightness of a picture.”
— Blog entry “There is No Failure — Only Feedback,” 20111130, on line at http://www.computer.org/portal/web/buildyourcareer/Agile-Careers/-/blogs/there-is-no-failure-%E2%80%94-only-feedback , accessed 20111205.
From “Science: Problems, Aims, Responsibilities” (1963):
There is only one way to learn to understand a serious problem — whether it is now purely theoretical or a practical problem of experimentation. And this is to try to solve it, and to fail. … Even if we persistently fail to solve our problem, we shall have learned a great deal by having wrestled with it.
— Karl Popper, “Science: Problems, Aims, Responsibilities” (1963), The Myth of the Framework, ed. M.A. Notturno, (London: Routdedge, 1994), p. 99.
I continue to reflect on different kinds of thinking I rely on in my current activities.
My study of and research on Chinese involves a kind of technical thinking about abstract linguistic categories, but those categories and the evidence for them require doing long stretches of basically mechanical, clerical work — collation of field notes or minute philological details — the aptitude for which the people at the Johnson O’Connor foundation call “graphoria”. In this work one does relatively little interesting original thinking, except to the extent that one is aware of the higher-level problems to which the mechanical work and the minute details will contribute. And there is also something meditative and satisfying about paying close attention to minute details for a long stretch of time, so the work by no means simply mindless rote action. Working with Chinese words, spoken and written, in particular, seems to stir my musical and graphic-analytical proclivities, and I have the sensation that Chinese grammar moves a kind of structural thinking, as well. So the mechanical work is not without its interest and satisfactions, though those do not compare to the kind of thinking one can eventually do when one has the necessary data assembled for actually attacking a problem in a unified way. I often think that one of the things that makes formal linguistics so uninteresting is that its practitioners seem to spend a lot of time avoiding actually handling data at length.
In programming and mathematics, however, neither the graphoria nor any aspect of language or music aptitudes seem to be directly helpful. In fact, I often find that my motivation to turn my mind to non-linguistic quantitative thinking is hindered by whatever time I have recently spent on mechanical or linguistic work, because those are inevitably easier to pick up quickly than math or a complex programming task. I experience a wrenching “code-switching” moment when I have to do this. I have still to find a good way to get my mind into the mood for math quickly if I have been doing those “lower”-level tasks. The only effective way I have found so far is to put clerical tasks completely away from myself for weeks at a time, but in real life it is not possible to do that, and certainly not for the coming half year, until my last two or three book projects are done.
I get a little help from using a timer to force myself to to spend some period of time working concentratedly on one type of task before switching to another. But the code-switching remains jarring even with the pressure of the timer to aid the switch. I wonder daily if overcoming code-switching is after all simply a matter of patience and concentration.
What experiences well known to me involve an altered perception of time?
One of them is improving a piece of my own prose. After laboring to bring ideas into being as words and then to cantilever those words themselves until everything balances like a Calder mobile, I may raise my head – feeling that a very long time has passed – to find that not even an hour has gone by on the clock. There follows the relief of realizing that less time has elapsed in the material world than in my experience of it — relief since so often it is the other way around, and when it is the other way around I feel a little cheated and frustrated.
Another case is the enlivening of words by music. Sometimes the result is what known as “opera time”, in which the events of a musical drama are out of step with the tempo of the same events in real life. I mentioned this effect in passing in recent posts about Donna Elvira and the cantus firmus in some of the Bach choruses. Because altered perception of narrative time is related to the visceral appreciation of music, I think of this effect as having something in common with kinesthesia, the subjective sensation of body movement and position, an idea and feeling of keen interest to me in my daily life and study habits. Of course, not all music produces this effect to the same extent and I know different listeners react differently, too.
Since taking the first steps toward making my peace with mathematics almost two years ago, I have struggled with a third form of altered time-perception: a special feeling that comes about in trying to read and understand a mathematical idea, to fully follow or compose a proof, to formulate and solve a problem. There has been nothing in my life up to now as a humanist — linguistic fieldworker and student of the Chinese script and medieval prosody — that has prepared me for this experience. Part of the sensation is that my mind is being forced into a lower gear-ratio: suddenly, my engine has to make many more revolutions to get the wheels to turn just once.
The low-gear feeling reminds me of a half-hour spent some years ago in a tiny café in Longyan 龍巖, a small Chinese city where a market for coffee developed around 2004. In order to serve my companion and me two cups of coffee, perhaps 8 ounces in all, the café owner ground beans in a hand-operated burr mill for ten minutes, cranking rapidly the whole time. Long before he was done I felt embarrassed at the exertion he had taken on himself to make a good impression on me. He had few customers but I was the first foreigner his shop had ever had, so it was a matter of some moment for him. He had paid a lot of money to have an expert come up from Xiamen 廈門 to teach him how to make and serve coffee the “right way”, exactly the right way. His coffee was thin — but after all it was pretty good, better than you would get today in one of the big-name coffee chains here in New York.
In studying Classical Chinese, or reading collections of philological notes on an ancient dictionary manuscript, or collating piles of handwritten dialect data, you learn not to crave instantaneous satisfaction and even to distrust any result arrived at quickly. But by comparison with mathematics, all of those feel like short-term activities whose conceptual finiteness is easy to demonstrate. The reason for the difference must be that the kind of thinking we do in solving humanistic problems does not require such continual recasting of hypothesis and mindset, or for most of us (I hope I am not shocking anyone) as much rigor, either.
Unlike the other two examples I have cited — polishing my own writing, listening to thoughtfully constructed vocal music — the bending of time by mathematics is unpleasant, except in retrospect after I have succeeded in reaching a solution of some sort. I hope more practice will bring me more facility — that is a prescription that certainly works in studying Chinese, and it is what divides the good students from the mediochre ones. Sometimes mediochre students are vastly more brilliant than good ones, but Chinese requires more than brilliance for its mastery; it also requires the investment of time in what may appear to be drudgery. It requires, in short, commitment to some partial vision of the future along with a willingness to ignore the clock. As for math, impatience is certainly my chief obstacle, and impatience is one of what Epictetus calls “things that are up to us”. I have tried techniques to increase my stamina and concentration, and to recover more quickly from periodic cognitive exhaustion. And to suppress the arrogant expectation that I can cut through the difficulties quickly. Nothing I have tried helps in a way that I could call striking — I mean that nothing lives up to my arrogant expectation that I can continue to indulge in arrogant expectation — and most of it does not help at all, except to distract me and waste enough time to make me feel a little cheated and frustrated again.
In the end, I think what will really matter is my own willingness to suspend impatience and all expectation of achieving finality, to refuse to feel them. I do not find it hard to attain this suspension on some occasions — when I listen to Beethoven’s late music — but in doing math you are not listening; it is as though you are actually composing the music, yourself.
For studying calculus, doing problem sets is the main thing, until the process becomes more or less mechanical. You can do that on your own for the most part.
If you crave understanding, however, you cannot find better on-line lectures than those of Prof. Herbert Gross.
Prof. Gross taught mathematics at MIT and Bunker Hill Community College for a lifetime, and around 1970 he prepared a series of videos — the clearest instructional films I can remember seeing.
The main series, “Calculus Revisited”, is part of MIT OpenCourseWare. The multivariable calculus videos are not included there yet, however, so has posted them himself on his own website:
Note that there are extensive paper (PDF) materials intended to supplement the videos.
Prof. Gross’s videos are far and away the best of their kind that I have seen, and never mind that they’re vintage 1969 and black and white. (Calculus itself dates from around 1660-1860 and the era of ink and quill.)
I contacted Herb Gross earlier this year and asked him about the origins of his project. He told me that he developed this curriculum over about three years with Harold Mickley, the director of the Center for Advanced Engineering Study (CAES) at MIT. It was intended for industry. Gross and Mickley went over the lecture plans in detail to ensure that everything was as clear as possible. No cue cards (the predecessor of the teleprompter) were used, since the blackboard content was written out in advance and provided a running outline of each lecture. He added, “Our feeling is that it was fine to overload the content because people could view the video at their own pace, pausing the video and/or fast forwarding it as desired. To keep things from being boring or looking ‘canned’ to the students, we left enough space on the board for me to interject supplementary remarks with the black chalk.” I asked about the filming schedule; he was not positive but said he thought it was two or three videos a day twice a week.
He said, “By MIT standards I was a mediocre math student but an excellent math instructor.” Not only an excellent instructor but a most generous one. Herb Gross and MIT have done the calculus student an immense service.
From an interview by Mihai Budiu:
The fundamental idea behind verification is that one should think about what a program is supposed to do before writing it. Thinking is a difficult process that requires a lot of effort. Write a book based on a selection of distorted anecdotes showing that instincts are superior to rational judgment and you get a best seller. Imagine how popular a book would be that urged people to engage in difficult study to develop their ability to think so they could rid themselves of the irrational and often destructive beliefs they now cherish. So, trying to get people to think is dangerous. Over the centuries, many have been killed in the attempt. Fortunately, when applied to programming rather than more sensitive subjects, preaching rational thought leads to polite indifference rather than violence. However, the small number of programmers who are willing to consider such a radical alternative to their current practice will find that thinking offers great benefits. Spending a few hours thinking before writing code can save days of debugging and rewriting.
The idea of doing something before coding is not so radical. Any number of methods, employing varying degrees of formalism, have been advocated. Many of them involve drawing pictures. The implicit message underlying them is that these methods save you from the difficult task of thinking. If you just use the right language or draw the right kind of pictures, everything will become easy. The best of these methods trick you into thinking. They offer some incentive in the way of tools or screen-flash that sugar coats the bitter pill of having to think about what you’re doing. The worst give you a happy sense of accomplishment and leave you with no more understanding of what your program is supposed to do than you started with. The more a method depends on pictures, the more likely it is to fall in the latter class.
At best, a method or language or formalism can help you to think in one particular way. And there is no single way of thinking that is best for all problems. I can offer only two general pieces of advice on how to think. The first is to write. As the cartoonist Guindon once wrote, “writing is nature’s way of showing you how fuzzy your thinking is.” Before writing a piece of code, write a description of exactly what that piece of code is supposed to accomplish. This applies whether the piece is an entire program, a procedure, or a few lines of code that are sufficiently non-obvious to require thought. The best place to write such a description is in a comment.
People have come up with lots of reasons for why comments are useless. This is to be expected. Writing is difficult, and people always find excuses to avoid doing difficult tasks. Writing is difficult for two reasons: (i) writing requires thought and thinking is difficult, and (ii) the physical act of putting thoughts into words is difficult. There’s not much you can do about (i), but there’s a straightforward solution to (ii) — namely, writing. The more you write, the easier the physical process becomes. I recommend that you start practicing with email. Instead of just dashing off an email, write it. Make sure that it expresses exactly what you mean to say, in a way that the reader will be sure to understand it.
Remember that I am not telling you to comment your code after you write it. You should comment code before you write it.
Leslie Lamport, interview by Mihai Budiu, 20070503, http://www.budiu.info/blog/2007/05/03/an-interview-with-leslie-lamport/
I have posted this little macro, together with a .tex and .pdf file for illustration, at bitbucket.org/dpb/chiuan . Here is what it looks like in use:
The name “chiuan” is the Gwoyeu Romatzyh spelling of the Mandarin word for ‘circle’, Pinyin quān 圈.
Mr Machin told me that telling Sir I. once that he admired very much his fine problems in Geometry, but infinitely more his Theory of the Moon for which he had no rule that was all sagacity – Sir I. smiled & said his head never ached but with his studies on the moon —
Halley told me he often pressed Sir I. to compleat his Theory of the Moon saying no body else euer could, Sir I. told him it had made his head ach & kept him awake so often that he would think of it no more, but Sir I. said afterwards to me that if he lived till Halley had made six years observations he would haue t’other stroke at it.
From “Drafts of portions of John Conduitt’s intended Life of Newton”, The Newton Project http://www.newtonproject.sussex.ac.uk/view/texts/normalized/THEM00169
