Unsolicited advice on CS independent work

Brian Kernighan

Sat May 11 18:00:52 EDT 2013

These observations on independent work in CS are based on my experience over the
past dozen years. Others will certainly have a different take on some of this,
so your mileage may differ. The bottom line, however, is the same for everyone:
independent work can be a great experience if you put some time and energy into
it.

The first problem is finding a topic, so you should be thinking about this the
semester before you plan to do IW. (Too late already? Sorry about that -- best
get started now.)

If you have a great idea -- something that seems sensible and turns you on --
start talking to faculty members who might be willing to be your advisor. Begin
with people who are in the right technical area, since you're most likely to
strike a chord there, but talk to others as well -- they may have hidden
interests, or they might be interested in branching out, or there might be
better personal chemistry, or your first choice might simply be too busy.

Even if you've got an idea that really appeals to you, it might be too big or
too small for a semester or a year. Advisors and others can help you adjust the
problem to the right size. Many initial ideas are way too big -- if you intend
to take on something that thousands have worked on for decades, you probably
won't knock it off in a semester as a junior. Lots of problems in AI -- natural
language processing, translation, etc. -- are like this, and trying to resolve
P=NP might be over-reaching as well. So part of the job is to find a manageable
piece of the problem, something about right for a semester or a year.

Sometimes the proposed problem is too small, more like a week of effort than a
semester. Here your advisor may be able to help you beef up the idea into
something that's an appropriate amount of work. Maybe there's some
generalization of your idea, or several related cases that add up.

On the other hand, if you have no clue at all about what to work on, it's time
to get started. Think about some area where computers might be used better, or
where a better program or tool or language or experimental result might be
useful -- there are lots of those, especially if you think outside the confines
of pure computer science. Think about places where some aspect of computing
irritates or frustrates you -- maybe you could do it better. Look at what other
students have done in the past few years; again, "I could do that better" is
often a good place to start. Think about an area or a language or a tool or a
system that you want to learn more about and how to parlay that learning
experience into something interesting.

After you've done some homework, you can visit likely advisors more profitably.
Most faculty have at least a few ideas that they think might make good projects,
or they have ongoing research projects that could use some help. Sometimes
talking with a student who has been thinking about potential topics will suggest
something to them. But don't just walk into faculty offices hoping for someone
to hand you the perfect problem. This is supposed to be your independent work;
trying to figure out what to do is a good place to start being independent.

How original does independent work have to be? There's no single answer, and
different advisors will have somewhat different notions, so this is a personal
opinion. There should be something about what you do that's new, but it's not
that the whole thing has to be brand new. Maybe you do a different version of
something that's already been done, or you find a different approach, or you
experiment with an new combination of things that already exist, or you do a
special case that hasn't been looked at carefully, or you revisit something done
long ago but attack it with modern systems and tools.

Again speaking personally, I think there should be something about your project
that builds on the fact that you're a CS junior or senior; just hacking together
an app for a phone doesn't seem enough. But if the domain is unexplored, or you
have some ideas about design or testing or evaluating user experience, those
will help make it a stronger project. Making something general rather than a
special case is also a way to make a project more substantive.

Once you've got at least a reasonable notion of what to work on, it's time to
think about breaking it into pieces. The ideal is to have a sequence of intended
results, such that you could stop at any time and declare success. You don't
want to have a project where nothing works until it all works, where everything
has to come together at once to make it work at all. You should also be wary of
projects that require exotic equipment or that depend on other people to provide
working code, fill out surveys, experiment with your system, etc.

Now you can sketch out a more detailed plan of what you'll do each couple of
weeks throughout the semester. This isn't cast in concrete; it's guaranteed to
change as you run into problems, find interesting new things to pursue, and so
on.

As you plan, don't forget the deliverables. You have to give a talk early in the
semester; having thought hard about what you intend to do makes your talk more
believable. There's a poster session at the end; thinking about what your poster
might look like will help you organize, and give you specific things to work
towards. Finally, you have to write a paper describing what you did. Again,
figuring out the general shape will provide a target. Be sure to include some
time for these in your schedule, and for the inevitable setbacks, other courses,
sickness, and having a life.

During the semester you should check in with your advisor pretty frequently, to
keep him or her abreast of progress (or aware that you haven't made any).
Preparing a weekly or bi-weekly note that says what you did, where you are, and
what you intend for the next period is a useful prod: it helps to answer the
advisor's question of whether you're doing anything at all, and it provides
useful material for the final paper. (If you want to work with me, be advised
that I will insist on this.) Prepare drafts of talks and the final paper well
ahead of time, not late the night before the due date. Feedback from your
advisor and others will help improve the product, and you'll gain some
confidence for when the real thing is due. In my experience, sending in a draft
for comments and then reacting to them can raise your grade by half a letter.
But you can't do this at the last instant.

As it is for one-semester projects, it's even more so for a senior thesis,
because you're expected to do something more substantial and you're going to be
working on it for twice as long. It's easy to procrastinate when the deadline
seems infinitely far away. Don't blow the fall semester. Indeed, don't blow the
summer -- that's a good time to be exploring and learning in the background.

Original: https://www.cs.princeton.edu/~bwk/advice.html