Information for Graduate Students

Prof. Alberto Cerpa, University of California, Merced

The following is a compendium of ideas and observations based on my own experience as a graduate student, as well as many interactions with other researchers, including (in alphabetical order) David Culler, Deborah Estrin, Ramesh Govindan, John Heidemann, Kris Pister, Miodrag Potkonjak, Mani Srivastava, Gaurav Sukathme, and many others to name a few. Most of the following suggestions are from Kris Pister, with appropriate modifications as I see fit. Any useful insight or bright idea came from some of the above people and/or many others researchers I have interacted in the past. Any problems or mistakes with the following advice is exclusively due to my own wrong doing.

Collaboration and Sharing of Ideas

Talk about your ideas. Help your colleagues work out their problems. Pay attention to what other people are doing, and see if you can learn something, or if you can contribute.

Other than the mundane goal of getting your PhD ;-), you are in graduate school to push back the frontiers of knowledge. You do this by generating and exploring new ideas. There is no way that you will ever be able to explore all of the ideas that you generate, but some of those ideas that you discard might be just what some of your colleagues are looking for.

Human nature tends to make us want to hoard our own ideas. You have to fight against that. Human nature also tends to make us treat other people's ideas with disrespect. The closer the idea to our own area of research, the more likely some part of our brain will try to find fault with it. Fight against that even harder.

You will find many people in academia who give in to the dark side. These Stealth Researchers never discuss what they are working on, except in vague and deceptive terms. They are experts at finding fault with the work of their colleagues. The Stealth Researcher writes papers that make very grand claims, but you can never quite figure out what they've accomplished and what they haven't. He is a master at omitting the key detail of the design or process that would enable others to follow his work. The Stealth Researcher is a knowledge diode, a roach motel for information. He has replaced the fundamental goal of discovery and publication with the twin evils of ego and empire.

Be open about what you are working on. Be honest about what you've done, and even more honest about what you haven't. Don't ever hide an idea for fear that someone will steal it, even if you are talking to a Stealth Researcher. With patience, maybe we can cure them.

Purchasing Equipment and Supplies

In general: Buy it!

Many graduate students have a hard time adjusting to the idea of spending hundreds of dollars on equipment that they may only need for one experiment. The reality is that equipment is one of the most important assets that a lab can have. The more stuff we've got lying around, the more likely we can do experiments the right way, and do them quickly.

So buy it!

Funding a graduate student full-time for a year costs about $71,000 for a California non-resident student and $55,000 for a California resident student at UC Merced as of 2010 (I realize that you don't see much of that, unfortunately). From a bean-counting point of view, if you spend a few hundreds dollars each month buying equipment or software that doubles your productivity or rate of progress, it's a big win. Worse, students often waste months or even years of their graduate careers making lousy measurements with lousy equipment or running jobs on slow computers. Advisors only have a certain amount of time that they can spend with students, which limits the number of students we can have. If the students waste their time with lousy and/or old equipment, everyone loses.

So buy it!


A research university exists to train students and to discover and disseminate. Traditionally dissemination has taken the form of publication (although the web is changing that somewhat, or at least changing the definition of publication).

Workshop publication serves to expose a particular research community to your ideas and results, even if they are not "fully cooked". Probably less than a hundred people will see your paper within the first few months of its appearance, reviewers may give you good feedback to improve the work, and the workshop may allow a venue for lively discussion tȇte-à-tȇte. Very few copies of the workshop proceedings will probably exist after a decade has passed.

Wireless Sensor Networks (WSN) workshops tend to have pretty fast turnaround. You submit a short paper (typically 4-6 pages long double column font 10 including figures) 4-5 months before the workshop. A couple of months later you find out if you are accepted. If accepted, you have another month to write the full/final version of the paper.

Conference publication serves to expose a broader research community to your ideas. Several hundreds of people (perhaps even thousands) will see your paper within the first few months of its appearance. In current times, with the advent of the Internet and electronic forms of communication, the conference proceedings of the top conferences in your field may probably still be going hard after decades have passed.

The top WSN conferences tend also to have pretty fast turnaround. You submit a long paper (typically 9-14 pages long double column font 10 including figures) 7-8 months before the conference. Three to four months later you find out if you are accepted. If accepted, you have another month to month and a half to write the full/final version of the paper. In the WSN community, the top conference are the preferred venue for top quality publications, but this varies for different research communities. In the systems community within computer science, that WSN is part of, the top conferences in the field are the preferred venue for top quality publication.

Journal publication (sometimes known as archival publication) serves to preserve your ideas and results indefinitely. Hundreds or thousands of libraries will keep copies of your paper for decades, BUT your audience may be a bit more limited. Most top people in the WSN community, read most of the papers from the top conferences, and perhaps only few selected articles from journals.

There are many resources regarding the issue of conferences vs. journal publication in computer science, but specifically the three more authoritative studies I've found are:

The last report is an extremely good read for anyone in the computer science field, and analyzes and evaluates things like the research evaluation and its role, the different fields and cultures within computer science (e.g. theory vs systems), publication channels, co-authoring, bibliometry and assessment formulae. It also has an entire section dedicated to the Thomson Scientific's ISI Web of Science, and shows how miserably it fails to evaluate computer science, and how their indexes should not be used in computer science evaluation.

Now, what if you have some work that you have published in a conference, but you would like to also publish in a journal. The following are some rule of thumb guidance you should follow:

LPI vs. Innovation

Many people seem to like to pad their resumes with conference publications from less reputed conferences, where the acceptance rates and overall quality of the work is not as good as the top conferences. This leads to phrases like "least publishable increment" and "epsilon improvement". Don't do this.


Most academic communities are pretty small, and the people on top usually have pretty good memories. As a result, your reputation is extremely important to your success.

Things to avoid:

Note that your reputation is intimately tied with the reputation of your advisor, your colleagues in your group, UCM EECS, and to some extent UC Merced as a whole. On the plus side, you get a dose of reputation by doing the right thing. On the down side, if you screw up you put a little tarnish on the reputation of everyone you work with.

Writing Research Papers

Be absolutely brutally honest. Describe carefully what you have done, what you haven't done, and what you expect to show in the paper.

In general, you should try to answer three questions whenever your write a paper:

Author Lists for Publications

There are no simple guidelines for who should go on the author list, or in what order. If someone is involved in the creation of the ideas that are in the paper, then they should definitely be on the author list. If they helped out with some of the testing, or helped you debug a design, or edited a version or two of the paper, then they deserve a mention in the acknowledgments for sure, but not necessarily inclusion in the author list. In general, adding another person to the author list doesn't "cost" you anything in terms of credit, so it's ok to err on the side of inclusion.

Highest Goal

Publish something that other people find so useful that they start doing it themselves.