· software-development

You and Your Research - Richard Hamming

Another paper that I read on my Sydney to London flight was one titled 'You and Your Research' by Richard Hamming.

It’s a transcript of a talk that Richard Hamming gave to Bellcore employees at the Morris Research and Engineering Centre in 1986.

The talk is aimed at computer science researchers and Hamming describes ways for them to do the best research that they can. I think several of the ideas in the talk relate to software development as well.

These were some of the bits I found interesting:

  • Hamming makes an observation about working conditions which I thought was quite interesting:

    So ideal working conditions are very strange. The ones you want aren’t always the best ones for you.

    From what I’ve noticed this is true in software development too. As a contrived example, the 'ideal' software project would have unlimited time and money but that’s never the case so we have to find ways to deal with the fact that we have to work within that framework. One of the benefits of this is that we try only to develop the features which are the most important rather than absolutely everything which might be the case if we didn’t have that constraint. I’m inclined to believe that when we’re working in a difficult environment we have more freedom to try things out because what’s currently being tried is probably not working anyway. This seems to be the type of situation where innovation can happen.

  • Hamming seems to touch on the idea of 10,000 hours of practice to achieve expertise that J. Anders Ericcsson has researched and Malcolm Gladwell popularised:

    On this matter of drive Edison says, ``Genius is 99% perspiration and 1% inspiration.'' He may have been exaggerating, but the idea is that solid work, steadily applied, gets you surprisingly far. The steady application of effort with a little bit more work, intelligently applied is what does it. That’s the trouble; drive, misapplied, doesn’t get you anywhere...the misapplication of effort is a very serious matter. Just hard work is not enough - it must be applied sensibly.

    This seems to cover the same type of ground that Geoff Colvin covers with the idea of deliberate practice where we should always look to practice something which is a bit beyond our current ability. That way we’re always improving.

  • I really liked the following part of the article:

    But most great scientists are well aware of why their theories are true and they are also well aware of some slight misfits which don’t quite fit and they don’t forget it. Darwin writes in his autobiography that he found it necessary to write down every piece of evidence which appeared to contradict his beliefs because otherwise they would disappear from his mind.

    I often forget that there are other ways of solving problems than the ways I currently use and it’s always good to read about people being successful with different approaches. That way we can keep questioning what we’re doing rather than just blindly doing so.

  • He also talks about the idea of bouncing ideas of other people because they will get you to think about the idea in different ways:

    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.

    I think this is where something like a technical book club can be invaluable. On every single paper or chapter we read in the ThoughtWorks Sydney book club others had different/better ideas than I did and it was really useful for showing me perspectives that I hadn’t even thought of. In 'Pragmatic Learning and Thinking' Andy Hunt suggests that whenever we read something we should try and explain the idea to a peer to see how well we understand the material and to get other ideas that we hadn’t thought of. I’d really recommend this approach.

  • There’s also some interesting advice about giving presentations:

    The technical person wants to give a highly limited technical talk...the audience wants a broad general talk and wants much more background than the speaker is willing to give. As a result, many talks are ineffective. ... You should paint a general picture to say why it’s important, and then slowly give a sketch of what was done...the tendency is to give a highly restricted, safe talk; this is usually ineffective. Furthermore, many talks are filled with far too much information. So I say this idea of selling is obvious.

    This is very similar to the advice Dan North gives. He suggests that three ideas/new things in a talk is all that people will be able to remember and anything more than this is a bit overwhelming.

There’s certainly other interesting ideas in this paper but those were some of the bits that stood out for me. Worth reading.

  • LinkedIn
  • Tumblr
  • Reddit
  • Google+
  • Pinterest
  • Pocket