Brian Kernighan's unsolicited advice on CS independent work

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.

from Hacker News https://ift.tt/2xbhi85