What are your career goals?
To decide what to work on what on, first decide what goal any given piece of work leads to. I roughly divide career paths for researchers into these:- Academic researcher
- Academic teacher
- Industrial researcher
- Industrial advanced development
- start-up company
What are you good at?
This should be graded on the curve. Obvious candidates are:
- math
- systems programming
- prototyping programming and toolkit use
- collaborating with people from other disciplines (biology, econ, archeology)
What do you like?
This is visceral. When you have to make a code faster is it fun or a pain? Do you like making 2D pictures? Do you like wiring novel hardware together?
Where is the topic in the field ecosystem?
How hot is the topic, and if hot will it be played out soon? If lots of people are already working on it you may be too late. But this is impossible to predict adequately. Something nobody is working or worse something out of fashion on is hard to get published, but find a minor venue or tech report and it will get rewarded, sometimes a lot, later.
How does it fit into your CV portfolio?
This is the most important point in this post. Look at your career goals and figure out what kind of CV you need. Like stocks and bonds in the economic world, each research project is a risk (or it wouldn't be research!) and you want a long term goal reached by a mix of projects. Also ask yourself how much investment is needed before you know whether a particular project has legs and will result in something good.What is my advantage on this project?
If the project plays to your strengths then that is a good advantage (see "what I am good at" above). But access to unique data, unique collaborators, or unique equipment is a lot easier than being smarter than other people. Another advantage can be to just recognize something is a problem before other people do. This is not easy, but be on the lookout for rough spots in doing your work. In the 1980s most rendering researchers produced high dynamic range images, and none of us were too sure what to do with them, so we scaled. Tumblin and Rushmeier realized before anybody else that this wasn't an annoyance: it is a research opportunity. That work also is an example of how seminal work can be harder to publish but does get rewarded in the long run, and tech reporting it is a good idea so you get unambiguous credit for being first!
How hard is it?
Will it take three years full time (like developing a new OS or whatever) or is it a weekend project? If it's a loser, how long before I have a test that tells me it's a loser?What is the time scale on this project?
Is the project something that will be used in industry tomorrow, in a year, 3 years, 10 years? There should be a mix of these in your portfolio as well, but figure out which appeals to you personally and lean in that direction.
Now let's put this into practice.
Suppose you have a research topic you are considering:
- Does it help my career goals?
- Am I good at it?
- Will it increase my skills?
- Will it be fun?
- Is the topic pre-fashion, in-fashion, or stale?
- What is my edge in this project?
- Where is it in the risk/reward spectrum?
- How long before I can abandon this project?
- Is somebody paying me for this?
- Is this project filling out a sparse part of my portfolio?
Suppose you DON'T have a project in mind and that is your problem. This is harder, but these tools can still help. I would start with #6. What is your edge? Then look for open problems. If you like games, look for what sucks in games and see if you bring anything to the table there. If your lab has a great VR headset, think about whether there is anything there. If you happen to know a lot about cars, see if there is something to do with cars. But always avoid the multi-year implimentational projects with no clear payoff unless the details of that further your career goals. For example, anyone that has written a full-on renderer will never lack for interesting job offers in the film industry. If you are really stuck just embrace Moore's law and project resources out 20 years. Yes it will offend most, reviewers but it will be interesting. Alternatively, go to a department that interests you, go to the smartest person there, and see if they have interesting projects they want CS help with.
Publishing the projects
No matter what you do, try to publish the project somewhere. And put it online. Tech report it early. If it isn't cite-able, it doesn't exist. And if you are bad at writing, start a blog or practice some other way. Do listen to your reviewers but no like it is gospel. Reviewing is a noisy measurement and you should view it as such. And if your work has long term intact the tech report will get read and cited. If not, it will disappear as it should. The short-term hills and valleys will be annoying but keep in mind that reviewing is hard and unpaid and thus rarely done well-- it's not personal.But WAIT. I want to do GREAT work.
Great work is sometimes done in grad school. But it's high-risk high-reward so it's not wise to do it unless you aren't too particular about career goals. The good news in CS is that most industry jobs are implicitly on the cutting edge so it's always a debate whether industry or academics is more "real" research (I think it's a tie but that's opinion). But be aware of the trade-off you are making. I wont say it can't be done (Eric Veach immediately comes to mind) but I think it's better to develop a diversified portfolio and have at most one high-risk high-reward project as a side project. In industrial research you can get away with such research (it's exactly why industrial research exists) and after tenure you can do it, but keep in mind your career lasts 40-50 years, so taking extreme chances in the first 5-10 is usually unwise.
No comments:
Post a Comment