Computer science includes many different kinds of research efforts,
some of which are more tyrannosaurical than others. You can
contribute to one of these efforts in various ways.
- About the smallest bone that you can find in Computer Science is a
reproduction or implementation of someone else's work.
While this doesn't get you points for originality, it may
be useful, both to your education and to the field. If you can make
it useful to enough people (say, by making it portable and
Web-available), it might even get your name known.
[Update: It may also be a good starting point. King
(2006) describes "how to write a publishable paper by beginning with
the replication of a published article."
More here and here.]
- A significant small bone to look for is a tweak that improves a
well-known technique. (In many
subfields, you will be expected to demonstrate objectively that your
method is an improvement.) Much research is of this kind.
When reading papers, stay on the lookout for such bones. In
particular, notice when the author may be making harmful
simplifications or arbitrary choices in his/her approach. These are
opportunities for you to try something different.
- Along the same lines, you might make a controlled comparison of two
or more algorithms, evaluating them by some objective measure of
efficiency or accuracy. Designing a clean comparison does take
thought, and carrying it out is often a lot of work.
This is usually a medium-sized bone, depending on how much work it
takes and (more important) how surprising the establishment finds
your results. Note that quantitative studies of this sort are becoming
increasingly important in some areas of CIS (e.g., operating
systems, machine learning, natural language, algorithms).
- You can thoroughly review the existing research in some area.
Note that this takes a good deal of time to do well, and is not
likely to do much for your career unless a lot of people read and
cite your lit review. (To publish you'd typically need to co-author
with a famous advisor, or else find some decent journal that is
willing to publish high-level overview articles by lowly grad
students.)
On the upside, writing a lit review will make you something of an
expert, able to talk confidently with other researchers in the
area; it will give you an idea of the shortcomings of past
research; and it may suffice for a WPE II, an M.S.E. thesis, or
the first part of a Ph.D. thesis. You can make it available to
others via your Web page or an online paper archive.
- Build a large program or device of some kind. This gets you some
name recognition, since there aren't that many big systems out
there, and it also confirms your ability as a software engineer.
However, do consider carefully: Will this system be of direct use to
anyone? If not, will it at least beat performance records? If
again not, does it have other merits, such as demonstrating how to
integrate or scale up existing techniques, or introducing a
collection of new techniques or a new perspective?
If you are only one of many participants in a lab project, be sure
that you make a "separable contribution" -- some piece of the
work that is impressive, that stands alone, and that people will
associate you with.
- Your field identifies various problems or issues as
significant. These often represent big bones in the skeleton of the
field -- problems that arise often, and whose solution makes a
difference. Get to know some of these problems and the work that's
been done on them. If you see how to achieve the first-ever solution, or
a better solution, or a different style of solution, that's a big
deal. Sometimes finding a good solution involves changing the
problem slightly.
- If you are feeling ambitious and have a big-bone temperament,
study important papers in your branch of computer science, flip
through some conference proceedings to see what people are working
on, and ask: What problems (recognized or unrecognized) are
obstructing progress in my field? Can I solve them? If not, can
I at least formalize them? Can I prove to my colleagues that
solving them would make a difference?
- Talk to your advisor about problems that are ripe for the
plucking. Every field has its share of problems that everyone knows
are "kinda important," and that may even get mentioned a lot, but
on which no one has yet made a serious attempt. If you think you
spot such a problem, use your colleagues and the library to make
sure it hasn't been plucked yet.
- Finally, you can identify new interesting problems. This is often
not as hard as it might sound:
- Study existing (applied) systems and note what they do badly at.
- If your field is interdisciplinary, ask people in the other
discipline what they think is interesting. In fact, ask them
why they think computer scientists are irrelevant.
- In many areas, the data have a way of suggesting their own
problems. Linguists can find unexplained phenomena in any
magazine article. Systems programmers can collect data on
actual disk access patterns and study it for regularities to
exploit. Theoreticians of programming languages can look at
real programming languages, and graphics programmers can look at
real photographs and movies, for effects that they don't know
how to capture.