Book Review: Pale Fire

Pale Fire is a 999-line poem written by John Shade.  It is also a novel by Vladimir Nabokov that contains an introduction by Charles Kinbote, the poem, and Kinbote’s extended commentary on the poem.

On the surface, Pale Fire is straightforward.  The poem is a touching — but not, it would seem, terribly good — autobiography and meditation on mortality.  Kinbote turns out to be the deposed king of Zembla, a small country in northern Europe, and is hilariously self-important, generally telling his own story rather than commenting on the poem.  When he briefly returns to the poem, it is usually to misread it entirely.  Nabokov clearly had great fun writing this, and he deadpans it all the way through.

Looking a little deeper, the story is more tangled.  Kinbote is detached from reality and we begin to suspect that he is not really a deposed king, that Zembla may not exist (within the novel), and that Kinbote may not, in fact, even exist.  One thing I think we can take for granted is that Shade is dead at the end of the novel; what author would waste “Shade” on a living man?  Second, it is pretty obvious that Kinbote is insane and/or a fabrication. Towards the end of the novel the Kinbote voice begins to slip and very late the bizarre Gradus/Gray distinction is made.

In the end it seems clear that Kinbote has murdered Shade and stolen the Pale Fire manuscript, that Gradus/Gray is a total fabrication, and that Kinbote is writing his commentary while hiding from the law.  I’ve heard other explanations, for example that Gray is the murderer; this doesn’t feel right.  Also Kinbote has told us that playing word golf he can turn “live to dead in five steps,” surely not a coincidence.

Pale Fire is a wonderful puzzle. It is strongly reminiscent of Gene Wolfe’s work, Peace in particular.  My guess would be that some of the odder words used in Wolfe’s novels (nenuphar, psychopomp) indicate that he was influenced by Pale Fire.

Book Review: Surviving Your Stupid Stupid Decision to go to Grad School

Good jobs have barriers to entry.  Sometimes these barriers are natural (not everyone is capable of writing a novel or being a leader) and sometimes they are artificial (not everyone is born in the right place or to the right parents).  Many well-paid jobs requiring very specialized skills are protected by — among other mechanisms — the requirement that applicants have an advanced degree.  For some people, the substantial costs of acquiring one of these degrees are worth it, for others they are not.  Because graduate students’ experience varies greatly across disciplines, across departments, and across individuals within a specific department, it’s hard to make useful generalizations about it.

Surviving Your Stupid Stupid Decision to Go to Grad School, nevertheless, does a good job capturing and satirizing important universal aspects of the graduate school experience: the insecurity, the low or nonexistent pay, the whims of advisers and committees, the potential for wasting what could be productive and happy years, etc.  Because the book is targeted at people already in grad school, its purpose is not to inform, but rather to entertain and also to reassure people that some of the more absurd parts of grad student life are, in fact, widely experienced.  No serious advice is given until the epilogue, which manages to say what is perhaps the single most important thing that a grad student can hear: don’t just sit there, take control.

Surviving is very funny in places, but for my taste it tries too hard.  The hit rate for jokes is not that high; one hopes that Ruben — who, according to the back cover, has a stand-up comedy act — doesn’t quit his day job. I read it on a plane flight; not just any plane flight, but one with my three and five year old boys, and without my wife.  As anyone who flies with kids can tell you, it’s not a good time for heavy reading.  An undistracted reader could polish the book off in an hour.

One day soon, I am going to leave this book in the lab where my grad students work.  Then I am going to walk out, chuckling in an evil way.

How to Get a Grant (from NSF, for Computer Scientists)

Learning to write good grant proposals is hard. First, while we learn to write papers in grad school, most of us only learn to write grants after completing a PhD, and possibly only after getting a faculty position. Second, the hit rates for grants are typically lower than for papers. Third, it’s fundamentally harder to write compelling text about a problem that you have not yet solved. For similar reasons, the PhD proposal is a major stumbling block for many folks. Fourth, grant review panels are smaller and have much higher variance in expertise than do top-tier conference program committees. Finally, there is less visibility into the proposal evaluation process than there is into the the paper evaluation process.

The upshot of all of these difficulties is that writing grant proposals is a bit of a frightening activity. One can spend a lot of time writing proposals before getting a hit. This is frustrating and, if it goes on very long, career-limiting. (Tenure committees usually evaluate candidates on research, teaching, and service — but all too often money is the ten-ton elephant hiding in the corner.)

This writeup is random thoughts, it’s in no way complete. You have to read the call for proposals and parts of the GPG carefully. You should talk to the program managers. You need to figure out how to work with your sponsored projects office and with your department’s internal grant-writing support people. Others have put useful information on the net; I found Cindy Grimm’s advice to be particularly good.

Writing a Proposal

To be funded, a proposal has to receive good reviews from respected researchers in your field. To get good reviews, there are three main things you need to show: a vision, a plan, and a capability. Let’s look at these in more detail, but first note that these don’t really match up with the parts of an NSF proposal as described in the Grant Proposal Guide. Rather, these are things that need to come out of the proposal as a whole.

Vision

The median annual income for a household in the United States is around $50,000. When you write a grant proposal, you’re typically asking the government to give you 2 to 100 times this amount. Think about it: every dollar you request will have to come from some hapless taxpayer (or corporation, or increase the debt…) and additionally won’t be used to cure cancer or put a person on Mars (unless, of course, your work directly attacks one of these problems). My opinion is that when you ask for this level of funding, the request had better be backed up by a damn compelling vision for how the world will be different if the money is awarded.

The vision part of a proposal is tricky. It has to be concise — probably around a page — and compelling, while remaining strongly connected to the proposed work. You can’t spin a story about ending disease and poverty, then immediately segue into open problems of the 5-bit frobnicator. The best vision parts of proposals leave panelists feeling that they have a mandate: the problem is so important that the work has to be funded no matter what. I’ve read proposals like this, they’re rare and wonderful. They always get funded.

In summary, the purpose of this part of a proposal is to convince your review panel that the problem that you are attacking matters, that it needs to be solved. It must not make people bored or irritated.

Plan

Here’s the really hard part: you have to convince the proposal review panel that you have an approach: a plan of attack for your chosen research problem. You must share your ideas, insights, and early results in order to paint a picture of a plausible research program that will come to fruition in 3-5 years. This is not the place to hold back on your most ingenious idea for fear of having it stolen. In general, it’s hard to find a piece of work that is plausibly doable, but that doesn’t sound like more of the same. Panels, in general, are not very interested in funding more of the same, they want new approaches.

One interesting question is: How much work should you do before writing a proposal? I’ve heard people say that you should basically have finished a piece of work before writing the proposal about it, and then you use that grant to fund the next piece of work. This seems pretty dishonest and in any case this approach would be highly risky if you’ve published the work. On the other hand, the reality is that it’s pretty tough to write a convincing proposal without having some kind of preliminary results. So I guess in the end the answer is pretty simple: you strike a balance that feels right.

Capability

A good proposal makes it clear that you are the best person in the world to do the work that you are proposing. You absolutely do not want a panelist thinking “Gee… that’s a neat idea, but who’s this schmuck? I bet Jones at MIT could knock off that project in six months.”

The capability to do research can be demonstrated in different ways. First, even if you’ve never received NSF support, you should briefly describe your previous accomplishments in the area of interest. Second, you might want to find an excellent (and probably more senior) collaborator who can be a co-PI on the proposal. Third, you can demonstrate capability by association, whether it is with equipment such as the huge cluster of Cray-27 nodes available only at your institution, or with people, such as your unique industrial contacts.

It can be daunting to realize that your competition may have been working in the field for 25 years, may run an operation with a budget 20 times larger than yours, and may have won every award the there is to get. In fact, these people often write incredibly polished proposals. However, it is highly likely that established people are working on established ideas. It is only the very best people in the field who keep doing extremely original work year after year, and you might as well just hope you don’t come up against them too often. In contrast, as a new person in the field you should have new ideas and approaches to bring to the table. Play this up in the proposal: it’s not just business as usual.

Other Issues

It’s important to make life easy for the people who will be evaluating your proposal. Assume yours is buried in the middle of a pile of about 20 proposals, and it will be read (probably on a plane to DC) by an exhausted person who would rather be doing something different. To make things easy for reviewers, keep it simple. Don’t assume everyone is interested in the deepest mathematics that you are capable of writing about. Use plenty of figures and graphs to break up the flow of text. Since some panelists like to skip around, try to make parts of the proposal as self-contained as possible and use informative section titles. Don’t refer to the previous work as nascent or vacuous since probably that work’s authors are on the panel.

Many of your colleagues have served on NSF panels. Get them to read your proposal and give feedback. Unfortunately, this will require that the proposal not be coming together on the day of the deadline.

Getting a Grant

Ok, so far this post has actually been about how to write a proposal, now let’s talk about how to get a grant. Realistically, unless you are both very good and very lucky, you need to submit more proposals than you are really interested in writing. One of my colleagues (not jokingly, I suspect) talks about submitting them faster than they can be rejected. Writing lots of proposals is sort of a bummer since each one keeps you from doing something else important, like writing a paper. Also, you never, ever want to write a proposal for work that you don’t actually want to do, since of course that proposal would end up being the only one funded.

When a proposal is rejected there are several things to keep in mind. First, it may not have been reviewed by any experts in your exact field. Second, if you revise and resubmit the proposal, it will be evaluated by an entirely new panel. A friend of mine once had a proposal rejected, but with strong reviews — it was barely in the not-funded category. He diligently revised the proposal and the next (much better) version got only lukewarm reviews. Again, he revised and resubmitted and the third time around got quite negative reviews. This kind of experience is not terribly uncommon and for this reason a different friend of mine makes a point of never reading his NSF reviews at all (or so he claims).

Predicting Grad School Performance

I enjoy going out drinking with my colleagues, although it only seems to happen a few times a year. It should come as a surprise to nobody that professors are natural bullshitters and people always have good stories: nearly destroying a ticket booth at Alta while doing avalanche control work, barely sub-nuclear pyrotechnic displays out in the desert, skiing across Siberia during the good old days of the USSR, things like that. It is perhaps relevant that one of my colleagues, Erik Brunvand, is the son of the guy who popularized the term “urban legend.” We also tell work stories; these are slightly less colorful but this is one of my favorites:

At some point before my time at Utah, some professors got together and decided to bring a few principles to the chaotic process that is graduate admissions. The experiment worked like this.  First, the applications to graduate school from a number of previous years were gathered up and a spreadsheet was created containing every current graduate student in addition to all of the quantitative data from their applications.  This spreadsheet was sorted by various fields such as GRE score, undergraduate GPA, etc.  Then, the resulting lists of names were passed out to the faculty without telling them what the sorting keys were. Each professor was asked to choose which list or lists best sorted the graduate students by ability. Finally, the results were tallied up.  The most important predictor of grad student quality turned out to be whether the student arrived with a MS degree or not, followed closely by social security number and then phone number.  GRE and GPA were not predictors at all.

Can I Stop Lecturing Now?

In Fall 2010 I’ll teach my Advanced Embedded Systems course for the fifth time.  This is a class that I enjoy teaching and that students generally enjoy taking.  I created it from scratch and am fairly proud of it.  There’s just one problem: I’m ready to stop giving the lectures.  First, although I tweak and improve them each year, I’m getting somewhat bored with them.  Second — and much more important — I’ve become convinced that (in this case, not necessarily in general) lectures aren’t the best use of class time.  For one thing, even when students are actively engaged with the material, it’s hard for them to sit still and listen to someone for 75 minutes.  For another, the thing I really want students to get from the class is a taste of real-world embedded systems design and implementation.  They should be learning skills such as working in a team, understanding requirements, evaluating software architectures and other implementation choices, creating maintainable code, debugging in challenging environments, reviewing code, and figuring out how to test complex combinations of hardware and software.

Here’s my idea.  First, while giving the lectures this fall, I’ll arrange for good-quality videos to be recorded, so I can put them online.  Second, after this fall, I’ll give few or no lectures but rather ask the students to watch at least some of them online, outside of class.  Then we’ll spend the class periods — typically two 75-minute sessions per week — working out the design and implementation of a more open-ended and aggressive collection of projects than I had previously given (note that there are 3 hours of lab time per week in addition to the lecture time).  Also, after teams get their projects to work, I’ll require them to integrate these projects with each other, for example using a serial line or CAN bus.  Previously, when I have required interaction between different teams’ projects, this has turned out to be far more challenging than the students anticipated, even for relatively simple projects such as distributed time synchronization or a consensus protocol.  Also, I’d like to spend a fair amount of time in class doing code reviews.  It turns out that for a variety of reasons, such as the fact that they always get to throw away code after writing it, a lot of junior/senior-level CS and CE students are not exactly the kind of coders I’d hire for an ambitious embedded project.  Regular code reviews can help turn coders into real programmers. One final idea that I keep wanting to try, but haven’t yet, is to force teams to exchange code bases with each other partway through the semester.  This is basically evil and will probably cause me to take a hit on the teaching evaluations, but I think it is guaranteed to be a character-building experience.

Anyway, it’s possible that this experiment will make my course more awesome, or it may tank miserably.  I’d love to hear feedback and advice from readers, either in the comments here or in email. In a couple years I’ll let you all know how it went.

Book Review: Sustainable Energy — Without the Hot Air

The premises are simple.  First, energy consumption must be met by energy production.  Second, use of fossil fuels is unsustainable.  Third, no magical technological fix to the energy problem is going to arrive.  Finally, to understand a sustainable future, we must think quantitatively.  That is, to proceed with a debate about, for example, wind or solar without a firm understanding of the magnitudes involved is foolishness.  This last premise is where Sustainable Energy departs significantly from the vast majority of information available in the popular press, which trumpets dubious oversimplifications like “hydrogen is good” or “unplug your phone charger when not being used” without providing the larger context.

The central question this book deals with is: If we must stop using fossil fuels, can we keep expending the amount of energy that we currently do, or will our standard of living necessarily contract?  To attack this question, the first part of the book alternately describes the components of energy demand and potential alternative sources such as tides, wind, and solar.  Impressively, MacKay manages to create a certain amount of tension between the supply and demand sides of the equation, making this initial part of the book more entertaining than it perhaps sounds.

The second part investigates sustainable energy in more detail.  How much can we save by mass transit?  Electric cars?  Better insulation?  On the production side, what can we do with nuclear power?  With solar energy from Africa’s vast deserts?  The capstone of Sustainable Energy is a collection of five energy plans for Britain, each making different tradeoffs between nuclear or not, domestic power vs. imported, etc.  The message is clear: we can live without fossil fuels, but only at considerable expense and inconvenience.

MacKay’s presentation of the material is clever.  He writes in an engaging way, including plenty of personal opinions and anecdotes.  The graphs and figures are first-rate.  Person-sized units of power such as kWh per day help us understand energy at a level where we can each make a difference, as opposed to the more remote view promoted by nation-sized units like GWh per day.  Facts are backed up by simple, intuitive physical explanations that will appeal strongly to scientific-minded readers.  Finally, MacKay includes a lot of specific recommendations for ways that individuals can make a difference in their own energy consumption, often supported by data and stories from his own life.

One could easily quibble with some of the specific quantities used in the book, such as the average wind speed in Scotland or the amount of unmined uranium in Africa.  However, to do this is to miss the point.  MacKay isn’t so much providing a collection of facts as a framework for thinking about energy supply and demand.  It is a certainty that over the next few years estimates of energy reserves will be refined and technologies like solar panels and batteries will improve a bit faster or slower than expected.  This new information may alter the nuances of MacKay’s message, but the fundamentals are so large that no invention short of practical fusion will render the book obsolete.  Similarly, an American reader could become irritated with the UK-centric nature of the writing, but again this misses the point: from the American point of view the major difference is that in the UK they use far less energy per person than we do.  Also, towards the end of the book MacKay specifically addresses the question of adapting his energy plans for the USA.

In summary, entering the energy debate without reading this book is like debating Christian theology without having read the Bible.  MacKay has created a work that is enjoyable to read and also provides a framework for understanding and discussing one of the most important problems faced by the developed world in the next 50 years.  An electronic copy of the entire book can be downloaded for free.