Richard Hamming - "You and Your Research"

During a discussion on the subject of passion in programming, David Bremner on #haskell pointed out Richard Hamming's 1986 talk You and Your Research. Here's a taste:

At Los Alamos I was brought in to run the computing machines which other people had got going, so those scientists and physicists could get back to business. I saw I was a stooge. I saw that although physically I was the same, they were different. And to put the thing bluntly, I was envious. I wanted to know why they were so different from me. I saw Feynman up close. I saw Fermi and Teller. I saw Oppenheimer. I saw Hans Bethe: he was my boss. I saw quite a few very capable people. I became very interested in the difference between those who do and those who might have done.

Hamming clearly describes both the difference between the two and how you can be one of those who do.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Previously on LtU.

Previously on LtU.

I missed it the first time, t

I missed it the first time, thanks for (re)posting it.

Wow.

Great inspirational stuff. THanks for posting again.

Important problems

I saw this talk a few years ago and this part really stuck with me:

[...] And I started asking, ``What are the important problems of your field?'' And after a week or so, ``What important problems are you working on?'' And after some more time I came in one day and said, ``If what you are doing is not important, and if you don't think it is going to lead to something important, why are you at Bell Labs working on it?'' I wasn't welcomed after that; I had to find somebody else to eat with!

While it doesn't seem like a good idea to go around questioning peoples' research in that way (it doesn't seem to give you many friends!), it certainly is a good thing to ask yourself once in a while: "am I working on an important problem of my field? if not, why not?"

Knuth's take on "important problems"

To lift a quote from All Questions Answered (TUGboat, Volume 23 (2002), No. 3/4):
So my basic idea is to say, whoever you are, you’ve got a unique combination of talents that’s been given to you. Don’t decide . . . Your life is kind of like a binary search, you try things and find out you did well in this, you try other things, you find out you didn’t do so well in that, you go on and continue discovering what are the best ways to use the abilities that you were born with instead of what you think they ought to have been.

Hamming wrote a book on this topic

Hamming wrote a book that goes deeper into the topic of his talk: The Art of Doing Science and Engineering: Learning to Learn, Gordon and Breach Science Publishers, 1997. Very highly recommended.

Hamming's book out of print in the U.S.

It's too bad that neither the hardcover, nor paperback edition is available from Amazon in the U.S. Alibris has it at a price of over $250. Abebooks doesn't have it. Amazon's UK site seems to have it. Where else do people get books? (Other than interlibrary loan, I mean.)

Kindle edition

At Amazon (where else?).

There is a copy of this book

There is a copy of this book on gigapedia

Thinking Big Thoughts

I particularly liked his notion for saving friday afternoons for thinking Big Thoughts. Far too much time is spent in tiny actions.

That would be a Good Idea for a web site. (Anyone with spare capacity on their hands?) A Big Thought Friday web site. Where you invite users to Think Big Thoughts in a envitonment where chilling little thought "it won't work" put downs are held back by the moderator until monday.

Big thoughts and project proposals

Actually, when I try to think Big Thoughts and something comes out of it, I usually try to write a project proposal first. I could post rejected project proposals, though. Almost always, the rejection has nothing to do with the technical quality :-).

"It won't work" is often a good thing.

I agree, except I believe that all of the little "it won't work" comments are absolutely essential to the process of engineering. The best scientists and engineers that I know are pessimists. They can list a million reasons that something will fail, yet in discussing these, they usually say, "but we can get around that by..." and both convincing themselves that it can work, and recognizing and eliminating lots of sources of failure before they happen, which is crucial.

Outstanding article, by the way. I've forwarded it around.

Long wait...

And now... the slides!

Don't mean any harm, but...

I've had a problem with the working harder is like compound interest statement since I first read this. To me that also means that if you happen to slow down just a little, the net effect is a huge drop in progress. But, from my personal experience, I don't remember ever being so disappointed with my progress just because I worked a little less hard than usual.

Finally acquired my own copy!

Nearly two years later, I finally found an affordable ($130) copy of Hamming's textbook. I'll post a review on my blog when I've finished reading.

Also inspirational in person

It was never my privilege to meet Dick Hamming, but an older colleague once described his experience working down the hall. This man (my colleague) was a strong software engineer, but was not a researcher or a scientist. As best I can reconstruct it:

Dick would come wandering down the hall, step into my office, and write enthusiastically on my whiteboard, explaining all the while what it was he was thinking about. I would nod and say "hmm" at various points, mostly not understanding a word of it. It was quite an amazing experience.

And judging by my colleagues tone during his description, it was perhaps awe-inspiring and a bit frightening in a low-grade sort of way. From the description I got, Hamming was probably explaining the foundations of error correcting codes.

John Cocke behaved similarly, though his soliloquies generally included a fair bit of colorful vocabulary. Most people found him intimidating, but I think that John may have loved nothing more than a well-founded, knock-down, drag-out, bare-knuckles technical argument. Ignorance was tolerated if corrected, but stupidity was like waving a flag before a bull: you were sure to be gored.