A List of Books Appeared at Our Office This Month

Hamming on Brainstorming

That is cool


Question: Is brainstorming a daily process?

Hamming: Once that was a very popular thing, but it seems not to have paid off. For myself I find it desirable to talk to other people; but a session of brainstorming is seldom worthwhile. I do go in to strictly talk to somebody and say, “Look, I think there has to be something here. Here’s what I think I see …” and then begin talking back and forth. But you want to pick capable people. To use another analogy, you know the idea called the `critical mass.’ If you have enough stuff you have critical mass. There is also the idea I used to call `sound absorbers’. When you get too many sound absorbers, you give out an idea and they merely say, “Yes, yes, yes.” What you want to do is get that critical mass in action; “Yes, that reminds me of so and so,” or, “Have you thought about that or this?” When you talk to other people, you want to get rid of those sound absorbers who are nice people but merely say, “Oh yes,” and to find those who will stimulate you right back.

For example, you couldn’t talk to John Pierce without being stimulated very quickly. There were a group of other people I used to talk with. For example there was Ed Gilbert; I used to go down to his office regularly and ask him questions and listen and come back stimulated. I picked my people carefully with whom I did or whom I didn’t brainstorm because the sound absorbers are a curse. They are just nice guys; they fill the whole space and they contribute nothing except they absorb ideas and the new ideas just die away instead of echoing on. Yes, I find it necessary to talk to people. I think people with closed doors fail to do this so they fail to get their ideas sharpened, such as “Did you ever notice something over here?” I never knew anything about it – I can go over and look. Somebody points the way. On my visit here, I have already found several books that I must read when I get home. I talk to people and ask questions when I think they can answer me and give me clues that I do not know about. I go out and look!

You and Your Research

Joe Armstrong, creator of Erlang, mentioned  Richard W. Hamming’s talk “You and Your Research” in his interview. I read it today. Well, it is great. So many gems that can be applied to software development easily. You should read it.

Here are several cool quotes. Some of them are quite long, but I believe they will give right feeling about the speech.



One of the characteristics of successful scientists is having courage. Once you get your courage up and believe that you can do important problems, then you can. If you think you can’t, almost surely you are not going to. 


Most mathematicians, theoretical physicists, and astrophysicists do what we consider their best work when they are young. It is not that they don’t do good work in their old age but what we value most is often what they did early. On the other hand, in music, politics and literature, often what we consider their best work was done late. I don’t know how whatever field you are in fits this scale, but age has some effect.


You observe that most great scientists have tremendous drive. I worked for ten years with John Tukey at Bell Labs. He had tremendous drive. One day about three or four years after I joined, I discovered that John Tukey was slightly younger than I was. John was a genius and I clearly was not. Well I went storming into Bode’s office and said, “How can anybody my age know as much as John Tukey does?” He leaned back in his chair, put his hands behind his head, grinned slightly, and said, “You would be surprised Hamming, how much you would know if you worked as hard as he did that many years.” I simply slunk out of the office!

Given two people with exactly the same ability, the one person who manages day in and day out to get in one more hour of thinking will be tremendously more productive over a lifetime.

The misapplication of effort is a very serious matter. Just hard work is not enough – it must be applied sensibly.


It comes down to an emotional commitment. Most great scientists are completely committed to their problem. Those who don’t become committed seldom produce outstanding, first-class work.

If you are deeply immersed and committed to a topic, day after day after day, your subconscious has nothing to do but work on your problem. And so you wake up one morning, or on some afternoon, and there’s the answer.


If you want to do great work, you clearly must work on important problems, and you should have an idea.

Most great scientists know many important problems. They have something between 10 and 20 important problems for which they are looking for an attack. 

By changing a problem slightly you can often do great work rather than merely good work. 

Open/Closed Doors

Another trait, it took me a while to notice. I noticed the following facts about people who work with the door open or the door closed. I notice that if you have the door to your office closed, you get more work done today and tomorrow, and you are more productive than most. But 10 years later somehow you don’t know quite know what problems are worth working on; all the hard work you do is sort of tangential in importance. He who works with the door open gets all kinds of interruptions, but he also occasionally gets clues as to what the world is and what might be important. Now I cannot prove the cause and effect sequence because you might say, “The closed door is symbolic of a closed mind.” I don’t know. But I can say there is a pretty good correlation between those who work with the doors open and those who ultimately do important things, although people who work with doors closed often work harder. Somehow they seem to work on slightly the wrong thing – not much, but enough that they miss fame.


There are three things you have to do in selling. You have to learn to write clearly and well so that people will read it, you must learn to give reasonably formal talks, and you also must learn to give informal talks.

Educate your boss 

Now you might tell me you haven’t got control over what you have to work on. Well, when you first begin, you may not. But once you’re moderately successful, there are more people asking for results than you can deliver and you have some power of choice, but not completely. I’ll tell you a story about that, and it bears on the subject of educating your boss. I had a boss named Schelkunoff; he was, and still is, a very good friend of mine. Some military person came to me and demanded some answers by Friday. Well, I had already dedicated my computing resources to reducing data on the fly for a group of scientists; I was knee deep in short, small, important problems. This military person wanted me to solve his problem by the end of the day on Friday. I said, “No, I’ll give it to you Monday. I can work on it over the weekend. I’m not going to do it now.” He goes down to my boss, Schelkunoff, and Schelkunoff says, “You must run this for him; he’s got to have it by Friday.” I tell him, “Why do I?”; he says, “You have to.” I said, “Fine, Sergei, but you’re sitting in your office Friday afternoon catching the late bus home to watch as this fellow walks out that door.” I gave the military person the answers late Friday afternoon. I then went to Schelkunoff’s office and sat down; as the man goes out I say, “You see Schelkunoff, this fellow has nothing under his arm; but I gave him the answers.” On Monday morning Schelkunoff called him up and said, “Did you come in to work over the weekend?” I could hear, as it were, a pause as the fellow ran through his mind of what was going to happen; but he knew he would have had to sign in, and he’d better not say he had when he hadn’t, so he said he hadn’t. Ever after that Schelkunoff said, “You set your deadlines; you can change them.”

After all, if you want a decision `No’, you just go to your boss and get a `No’ easy. If you want to do something, don’t ask, do it. Present him with an accomplished fact. Don’t give him a chance to tell you `No’. But if you want a `No’, it’s easy to get a `No’.


Another fault is anger. Often a scientist becomes angry, and this is no way to handle things. Amusement, yes, anger, no. Anger is misdirected. You should follow and cooperate rather than struggle against the system all the time.


In summary, I claim that some of the reasons why so many people who have greatness within their grasp don’t succeed are: they don’t work on important problems, they don’t become emotionally involved, they don’t try and change what is difficult to some other situation which is easily done but is still important, and they keep giving themselves alibis why they don’t. They keep saying that it is a matter of luck.

The Paradigms of Programming

The Paradigms of Programming by Robert Floyd is a 30 y.o. lecture. However, it is still surprisingly relevant today. It contains right vision on programming teaching and predicts such modern things like DSL. Worth to read for sure. 

It is a brilliant concentration of deep thoughts and a clear vision of the future.

Some quotes:

The state of the art of computer programming was recently referred to by Robert Balzer in these words: “It is well known that software is in a depressed state. It is unreliable, delivered late, unresponsive to change, inefficient, and expensive. Furthermore, since it is currently labor intensive, the situation will further deteriorate as demand increases and labor costs rise.”

Again from Kuhn:
The older schools gradually disappear. In part their disappearance is
caused by their members’ conversion to the new paradigm. But there are
always some men who cling to one or another of the older views, and they
are simply read out of the profession, which thereafter ignores their work.

In computing, there is no mechanism for reading such men out of the profession. I
suspect they mainly become managers of software development

If the advancement of the general art of programming requires the continuing invention and elaboration of paradigms, advancement of the art of the individual programmer requires that he expand his repertory of paradigms

A paradigm at an even higher level of abstraction than the structured programming
paradigm is the construction of a hierarchy of languages, where programs in the highest level language operate on the most abstract objects, and are translated into programs on the next lower level language. Examples include the numerous formula-manipulation languages which have been constructed on top of Lisp, Fortran, and other languages. Most of our lower level languages fail to fully support such superstructures.

I believe that the continued advance of programming as a craft requires development and dissemination of languages which support the major paradigms of their user’s communities

If I ask another professor what he teaches in the introductory programming course, whether he answers proudly “Pascal” or diffidently “FORTRAN,” I know that he is teaching a grammar, a set of semantic rules, and some finished algorithms, leaving the students to discover, on their own, some process of design.

Expertise and Software Development

Students are commonly given an outline of all data that they might collect, organized by “social history,” “previous illness,” and so on, suggesting that medical diagnosis is a process of collecting data in a fixed order. The results is that students sometimes collect information by rote, without thinking about hypotheses at all!

This is the excerpt from the “Nature of Expertise” book I’m reading.

This example shows how educational system is broken. The first two things EVERY educational system should do are:

  1. teach how to learn the subject.
  2. give fundamental understanding of the subject and provides a formalized mechanism how to apply knowledge on practice in the most efficient way.

In software development people often learn new technologies like CSS, RoR, Java, etc., without fundamental knowledge of the subject. As a result, they have impressive list of technologies in CV, but fail to write a simple algorithm or explain why this particular solution is best to this particular problem.

  • Average developer can solve problems using google.
  • Good developer knows patterns and some clever techniques.
  • Great developer can explain EVERY decision he makes.