(Turns out that Margo Seltzer blogged on the same topic this week too! Great minds think alike.)
This year I have two new students -- Amos Waterland and Youngjune Gwon -- I'm kinda bummed that I'm on sabbatical and can't interact with them as much as I'd like, but they will be busy with classes anyway :-)
Don't let school get in the way of your education. My advisor, David Culler, was fond of this misquote of Mark Twain, but it's true. Classes and program requirements are important but what is far more important is becoming an expert in your area. If that means taking fewer classes each term so you have time to do some real research, so be it. Harvard's PhD program is course-heavy and I often advise my students to ignore the requirements on paper and spread the classes out over several years, taking no more than two "real" classes at a time. Otherwise they would get nothing done for the first couple of years of the program.
Just dive in and have no fear. I often liken starting a research project (or career) to wandering into a dense jungle and blazing a path -- ideally a new path (but sometimes the jungle has overgrown since anyone wandered in your direction). There's only so much you can learn standing outside the jungle looking in, or reading about it, studying it, pondering it, whatever. I also feel that you can't really understand a problem until you've tried to solve it, even if your approach is somewhat naive. So rather than sit around reading a gazillion papers, just dive in and start doing some research -- anything -- even if you think it might be a dead end. Half the time you discover that something you thought would be easy or uninteresting actually leads to a bunch of open problems once you get beyond a superficial understanding of the area.
When I started on my thesis, I spent a lot of time reading and talking and thinking before writing any code, and at one point convinced myself that my project idea was stupid and not worth pursuing. (Whether this is true or not is still open for discussion.) Finally I sat down (during the sessions at OSDI 2000) and pounded out a simple prototype to test my ideas.
Don't read too much (at first). Obviously a huge part of grad school is reading and reviewing papers, but the problem with reading too many papers (especially at first) is that it can make it look like all of the interesting problems have already been solved. I've seen more than one grad student get into a rut because they read too many papers. Certainly you should never read anything from the 1960's or 70's or you will realize that it all has been done before -- by Real Programmers who had to code in assembly on a trinary architecture with sixteen levels of virtual address space segmentation and only two registers -- but I digress.
There is a real advantage to the Zen Mind approach of jumping in with your gut instincts about a problem and not worrying too much if you are treading familiar ground. At some point -- say 2 or 3 months into a project -- you should take a step back and compare your approach to what has come before, and correct course if necessary. Arguably all great systems projects are just reinventing ideas and reevaluating assumptions in light of changing technology trends, but don't let that stop you. I made my career that way, you can too!
Keep track of the papers that you do read. Come up with a good system for tracking the papers you have read, need to read, and take notes on them that you can easily reference later. Printing them out and scribbling in the margins is OK, though there may be more environmentally-friendly approaches. I am a big fan of the Mac application Papers, which is like iPhoto for PDF files. Mendeley, CiteULike, and Bibdesk offer similar functionality. In grad school I just kept a huge text file of every paper I read and my notes on it. When it came time to write my thesis, this was invaluable for putting together the related work list (same for papers that I wrote).
Finally, take a lot of notes. A couple of my students have the habit of coming to meet me empty-handed, which is a problem when I give them pointers to related work or ideas to chase down, which they really should be writing down. (Hell, I'm never going to remember what I told them from one week to the next, so they need to keep track.) I find it really helpful to maintain a group Wiki with meeting notes where I can go back and see what we were talking about week to week.