A great physicist, and how he worked
muller.lbl.gov
muller.lbl.gov
An obligatory favorite passage:
"You'll never learn experimental physics by sitting at a desk," he abruptly said. "Get over to Building 46, where the real physics is being done!"
I was embarrassed. "But I don't understand anything yet. I don't know how to help. I'd just be in the way," I protested.
I remember his answer very clearly "That doesn't matter," he said. "just go over there and hang around. Do anything anybody asks you to do. Sooner or later someone will see that you're there, and they'll ask you to hold a screwdriver. Get your hands dirty Pretty soon you'll know how things are constructed. Once they have seen that you're around a lot, they may ask you to help test the apparatus. Before long you'll know how everything works. You can read memos anytime, in the evenings, at home, but you can only learn experimental physics by being in the laboratory, by doing it."
Skepticism, the ability not to be fooled, was clearly
important, but it is also cheap. It is easy to disbelieve
everything, and some scientists seemed to take this
approach. Sometimes Luie was skeptical, but more often
he seemed to embrace crazy ideas, at least at first. He
rarely dismissed anything out of hand, no matter how
absurd, until he had examined it closely. But then one
tiny flaw, solidly established, was enough to kill it.
His openness to wild ideas was balanced by his firmness
in dismissing those that were flawed. He had a finely
honed skepticism. Perhaps that was part of his secret
talent.
Related:
I've been trying to come up with a good frame for an upcoming talk (about an open source programming project), and I think that putting it in terms of the scientific method is just the thing. That is, in making code, just like in making science or in any other kind of "hacking", it's essential to first and continually "get your hands on the machinery", figure out by fiddling how things work, stop worrying about breaking things, and just see what happens when you push something here or there (of course, that doesn't mean we should throw caution to the wind, but just that we should take some risks), and then after that, after the parts are understood, take a step back and build a little bit, and then dive back in.
One important part (to writing code, and therefore a subject for my talk) is figuring out how to layer abstractions one on the other, so that we can avoid duplication of effort, and can separate out logic into clearly understood parts, small enough to be effectively tinkered on, and independent enough so that each one doesn't break the others. But we can't let worrying about the purity of those abstractions, and analyzing them, ultimately get in the way of actually diving in to fiddle, and figuring out what smells, first hand.
"You don't always understand what you are doing; if you do, it probably means that you aren't really near the forefront of knowledge."
- http://www.amazon.com/dp/142662459X - http://www.physicsforfuturepresidents.com/
Did anyone check his homepage, he's got a fantastic sense of humor.
http://muller.lbl.gov/pages/welcome.html
Rich's graduate students Tim Culler and Alex Kim have been hard at work setting up their home pages, instead of working on their thesis research. Rich's other graduate student Matthew Kim has no home page, and will undoubtedly graduate first.
Every great company had been started from several small innovations. I knew youtube or any site that was playing video with flash was going to be big. Its because we had just developed the flash player to do it.
I learned then that playing with any new idea/software gave me much more than some curiosity.
He had learned just enough about every subject; he could go back and fill in the gaps later, when and if that was necessary. The gaps in his knowledge were surprisingly large, but not detrimental to his work.
In some ways, teaching and learning specific subjects very deeply may be a form of premature optimization.