Rambles around computer science
Diverting trains of thought, wasting precious time
Mon, 02 Oct 2006
Some thoughts and tips about Part II Projects
Part II projects are a decidedly tricky part of the Tripos course, and it's easy to unwittingly make mistakes early on which really compromise your chances later. It's also the case that the Lab's official advice, as contained in the "pink book" and meted out at the Project Briefing, is incomplete and in some cases misleading. Although much of it is good advice, a very few points are (in my humble opinion) not so good.
As someone who, despite being fairly conscientious and (I like to think) fairly competent, ended up with a decidedly average project mark when I took Part II in 2005, I've written up a few pieces of hard-learnt advice. Please don't take them as gospel: if you follow them and subsequently aren't as successful as you hoped to be, I won't be held responsible for your perceived failure. Nevertheless, I hope they're useful.
- The idea is important. Get thinking early; don't leave it until the last minute. (Exactly what makes a good idea, or rather a bad one, I'll try to cover in later points.)
- Pick something achievable. You might think, based on the pink book's claim that your dissertation is judged on its "computer science content", that as long as you can talk about what went wrong and what you would have done given lots more time, failing might not be such a disaster. There might be a shred of truth to this, but only a shred: in practice, the marks come far more easily if you're writing about something that was a success.
- Pick something with "core" and "extension" elements. The pink book doesn't make much of this, but if you read these examiners' notes from 2005 (which you really should) it appears to be a recommended pattern. Note also that the "extension" should ideally be something that you're able to do! [Update, 2008-08-15: the page has since disappeared, but most (if not all) of the important stuff is mentioned here.]
- Pick something quantitatively evaluable. The pink book does mention this. The "quantitative" part is important! (A few people do opt for more qualitative evaluation methods, such as user studies, and sometimes do a good job. But this is much harder, and takes a long time. Save yourself the headaches if at all possible.)
- Have an application. Even if you're writing something low-level and systems-oriented, rather than an application itself, having a neat demo really will count for something. (When doing any systems work you should really expect to be asked what it's useful for, and how well it works in practice.)
- "Computer science content" means "Part II content". It might seem paradoxical, given that you've barely started Part II when you write your project proposal, but showing understanding of technical content from Part II courses (or comparably advanced material) in your dissertation will gain you a lot more marks than the material you're already familiar with. There's no easy solution to this: reading ahead will help you a little, but there's no avoiding a certain leap of faith and the corresponding risks.
- Interesting algorithms and data structures are essential. I think that says it all: their presence is a sure-fire way of impressing the examiners, and their absence is certain to be remarked upon. In general, the marking of a dissertation is done fairly hurriedly and in a formulaic way: this is one of the really important hoops through which you need to jump.
- If you have research ambitions, don't feel that this is the place to start. As someone who wanted to go on to do a PhD after my Part II, I thought that my project was the place to start working on my ideas and showing them to people. It wasn't. That's not to say that you can't do a research-oriented project, but I'd seriously only do so if your idea meets all the other criteria. A good project in some slightly-displaced area will do you more favours than a compromised research-oriented project, even if the latter has some neat ideas behind it.
- When looking for a supervisor, don't use e-mail. Or rather, if you do,
pester like mad. Finding a project supervisor is a crazy free-for-all
which really should be better coordinated. The pink book recommends e-mail, but
I disagree: there's nothing worse than having people take ages to reply to your
mail, or never reply at all, and this happens often.
(One of my friends was led on a wild goose chase by this
e-mail process. By the time he found an interested supervisor, he was turned away for
being "too late" -- the supervisor had already taken on enough students. The pink book
doesn't seem to cover the case where you can't find a supervisor for any of your ideas.)
The best way to get results is to meet in person,
or telephone. Try calling your target from Student Admin and arranging a time to meet.
If you can't get hold of them, try contacting one of your (current or former) course
supervisors from the same group: they might have some idea of your target's
whereabouts, or be able to suggest alternative supervisors. If that fails, try a
lecturer. Don't just sit back in the hope that your e-mail will be answered eventually,
because you can easily run out of time.
[Update, 2008-08-15: to clarify, you should of course try e-mail first, and may well get a prompt response. If you don't, and it's coming up to proposal-writing time, try the other strategies. Most importantly, don't sit back, and don't be timid!] - Your supervisor is important. Don't underestimate the potential benefits of getting advice from someone more experienced. Some supervisors are proactive and interested in the projects they supervise, while others could hardly care less. Pester your supervisor. Try to arrange fairly regular meetings, though don't feel the need to make them more frequent than you're comfortable with. If your supervisor really doesn't seem to care, talk to your overseers. You might also get some useful informal advice from one of your course supervisors.
I hope some of the above proves helpful. If you have any questions, comments or disagreements, please contact me.
(You might cynically wonder why, after all these pearls of supposed wisdom, I'm not suggesting any project ideas this year. I guess it's because I consider finding suitable ideas a hard problem, and not one to which I'm prepared to claim any good solutions right now. Maybe next year....)
[Update, 2008-08-15: thanks to the netos list for a productive discussion about these topics. And this year, I have even put forward some suggestions, found on this page!]
[Update, 2011-10-13: Andrew Moore supplies this very helpful set of notes from his duties as examiner in 2011! It's worth reading ahead of time, but arguably even more useful when writing up---see my later blog post about that.]
[/teaching] permanent link contact
