- Review research literature - Before you can contribute, you must be an expert on the current state of research in your and peripheral areas.
- Read lots of papers (IEEE, ACM, CiteSeer).
- Take notes for each paper you read because you will forget! Write a Related Work-style paragraph. Write notes directly on the paper indicating the overall paper quality, whether it should be cited, tools mentioned that you can use, and important points.
- Hint: References are valuable for finding relevant papers and conferences.
- Read lots of papers (IEEE, ACM, CiteSeer).
- Start by publishing workshop papers - Don't make the mistake I did and submit to a top-tier conference like PLDI from the get go. You'll just waste a lot of time and have nothing to show for it but rejection letters. Make sure you vet your ideas by communicating extensively with your research peers and by publishing workshop papers. The benefits of publishing workshop papers are:
- You can publish preliminary results and unfinished ideas to determine if your ideas are worth pursuing, find flaws in your logic/arguments, and learn what the main sticking points are and the common questions people ask.
- Allows your paper/ideas to be peer reviewed so the workshop paper is really just a rough draft for a future conference paper
- Meet people in your community
- Pad your publication record
- You gain practice giving talks. Hint: Practice your talk 2-3 times and make sure you don't exceed the alotted time.
- You can publish preliminary results and unfinished ideas to determine if your ideas are worth pursuing, find flaws in your logic/arguments, and learn what the main sticking points are and the common questions people ask.
- Attend conferences and workshops - In the beginning of your PhD program, you should go to conferences and workshops even if you don't have a paper there. This helps to:
- Make your name known. Remember, by the time you finish your PhD you should be "world renowned." This requires both publications and networking.
- Find future co-authors
- Get on future program committees
- Make your name known. Remember, by the time you finish your PhD you should be "world renowned." This requires both publications and networking.
- Learn your venues
- Find out the best conferences and journals in your field (for Software Engineering, look here). Find out where important people in your field publish papers. Subscribe to the SEWORLD and ECOOP Info lists to find out about calls for papers.
- Create a publication schedule that shows all the conferences and workshops in your area along with their deadlines. Eventually, your life will be structured around these deadlines. Periodically update the schedule so that you are always aware of upcoming deadlines.
- When considering publishing at a venue, become familar with the papers published in previous years. Is it easy to obtain the papers? Do the papers show up on searches like Google, ACM, IEEE? If the answers are no, publishing at this venue may lessen your paper's impact.
- Find out the best conferences and journals in your field (for Software Engineering, look here). Find out where important people in your field publish papers. Subscribe to the SEWORLD and ECOOP Info lists to find out about calls for papers.
- Get a summer research internship
- Line up post-PhD career - Summer internships are really just a recruiting vehicle. The company uses them to determine if they should hire you; for example, to determine if you can do great research. You should knock their socks off so they'll want to hire you after you graduate. Make sure you publish a paper.
- Fun and profit - Internships are usually great fun, you meet a ton of other interns and contacts, and you make a lot more money than if you stayed at school.
- Publish a paper - The best indicator of success for an internship is publishing a paper, either at the end of the internship or shortly after. This also communicates to the company that you can do research.
- Make contacts
- Hint:Apply in January
- Line up post-PhD career - Summer internships are really just a recruiting vehicle. The company uses them to determine if they should hire you; for example, to determine if you can do great research. You should knock their socks off so they'll want to hire you after you graduate. Make sure you publish a paper.
- Publish, publish, publish - My advisor (Al Aho) requires his PhD students to have "2 good ideas." This translates into 2 papers published in the best conferences (PLDI, POPL, ICSE, FSE, ECOOP, OOPSLA, etc.) and journals (TSE, etc.).
- Participate - Try to serve on several program committees, serve on an organizing committee, and organize a workshop.
- Find a job - You should be looking for a job now, not after you graduate.
- Talk to people at conferences, etc. When these people are deciding who to hire, it will help tremendously that they know you.
- Subscribe to job postings (CRA, Chronicle, SEWORLD)
- Try to graduate in May since universities and research labs typically hire on a regular academic schedule. Assistant professor positions for Sept are usually posted in Oct and Sept of the previous year, application deadlines are usually in Jan and Feb, interviews are in Feb and Apr, and offers are made in Feb-May. Labs usually use the same schedule although the start date is immediate.
- Talk to people at conferences, etc. When these people are deciding who to hire, it will help tremendously that they know you.
More advice:
- Ruthlessly eliminate activities from your life that do not get you closer to finishing your PhD. Throughout your PhD, and especially before embarking on time-consuming activities, ask yourself, "Will this be in my thesis?" If you're spending most of your time coding, there's something wrong. No one cares how much code you write and the elaborate tools and systems you create. They only care about how many good papers you author. For example, I wasted several semesters creating an elaborate system for dynamic aspect-oriented programming and it never produced any publications and was not even mentioned in my thesis. Of course, all research requires some coding. However, rarely does the code see the light of day after you graduate. So keep it simple, quick, and dirty (e.g., PERL is fine). Also, use off-the-shelf software or get someone else to write it (see below). Research papers are a great source for finding out about tools that you can use such as metrics, profilers, compilers, static analyzers, etc.
The only exception to this is if you are building something that many people will use, thus increasing your reputation. Your dissertation defense committee will appreciate this kind of research contribution. Companies also appreciate this kind of practical work. However, you'll need to develop, support, and market the software, which can be a huge time waster, especially if you don't have any help.
The same caution about coding goes for teaching, reading, reviewing, meetings, demos, administrivia, etc. - Mentoring - Undergrads and master's students can help shoulder some of the coding burden. However, they can also be a huge waste of time and result in a negative net gain.
- Experience - I like excellent programmers with industrial experience. Industrial experience means they are more likely to produce quality code, are good at collaborating and taking direction, and are likely to be familiar with source control. The more the student needs to learn (programming language, OS, source control, etc.), the more of your time they'll require, and the longer it will take for them to be productive (if ever). For this reason, I eschew undergrads, since they usually have very little programming or industrial experience.
- Time constraints - I required all students to commit to at least 8 hours a week to working on my project. If the student is taking more than 2 other classes, it is likely they won't be able to meet this. This is another reason why I eschew undergrads, since they usually take a full course load and give the project low priority.
- Management - You want self-motivated and self-managing students, otherwise you'll spend alot of time managing them. Create a project roadmap that provides enough detail for them to go complete the project. It should include an overview, requirements (checklist of things they need to do), use cases (concrete examples of scenarios they must support), and milestone dates. They should agree to the roadmap before signing up for the class. If you have the time, a good technique is to meet with the students in-person once a week for a combined status meeting and coding session. Create an agenda for student meetings to ensure all issues are addressed
- Go deep - My mentor at Microsoft Research told me to find a concrete problem and "go deep." Don't try to solve a problem in the abstract. What do you want other people to consider you to be an expert on? Decide what that is and then know that thing better than anyone else in the world. While it may be fun to learn about tangential research areas, you want to be a world renowned expert in one thing not a jack-of-all-trades.
- Focus on the hard problems - What's the point of getting a PhD if your work has no impact. Your success is measured by your contribution. If you're not working on the most important and hardest problems in your field, then you're contribution is muted. My advisor liked to ask, "Is this a $1000 problem or a $1B problem?"