Posts Tagged “advice”

Where your brain wants to Go

Years ago I attended a lecture from a famous master of the game of Go. He is revered not only for the many championships he has won, or even for his daring and distinctive style, but also for his insightful and even witty commentary on the games of other professionals. All of us who attended expected a once-in-a-lifetime treat.

(read more)

My Top Conference Attendance Tip

One of my PhD students is on his way to his first academic conference. Conferences are one of my favourite parts of research: I’ve met so many interesting people and started so many fun collaborations that way.

(read more)

Viva la voce

One of my favourite aspects of academia in the UK is the final oral examination for the PhD — formally called a viva voce, which everyone seems to call a viva (VEYE-vah). The viva is an oral examination that typically consists of the student and two examiners, one from within the University (the internal examiner), and one from outwith the university (the external examiner).

(read more)

Taste in research, and the paradox of deciding what not to work on

A large part of taste in research is deciding what not to work on. You might choose not to apply method X, even though you don’t really understand it, because it has a reputation for being fiddly and difficult to get right. You might choose not to work on topic Y because you think that even though there’s a lot of people writing papers about it, its goals are too ambitious to ever be met. This extends all the way to entire fields of research. I could name a few popular fields within computer science — with active research communities, large amounts of external research funding, leading researchers with fancy prestigious awards — that I suspect are being investigated in entirely the wrong way, and that I personally think are currently pointless.

(read more)

Ubiquitous capture and the ideas file

Ubiquitous capture is a great term from Getting Things Done. Like the best ideas from GTD, it is simple, obvious in retrospect, but changes everything. Ubiquitous capture means: When you think of something, you should write it down, right away, in some place where you will check it later.

(read more)

And can you teach me how to talk real slow?

A switch flipped in my head at the beginning of my lectures last spring. At that point I had lectured something like 5 full university courses and maybe something like 50 research seminars. I was an experienced speaker.

(read more)

Future Work

It seems customary for computer science research papers to list directions for future work at the end. This custom is immensely strange. If your idea for future work is really good, the last thing you want to do is tell everyone about it. Literally the last thing: right after you’ve done the research and written it up! On other hand, if the idea for future work is bad, why do you want other people to see it?

(read more)

A simple trick to encourage lecture participation

It’s the time of year when teaching is very much on my mind. In an essay about his teaching styleMichael Scott says something about encouraging student participation that stuck with me:

(read more)

About to graduate with your PhD? One more tip.

A rite of passage for US PhD students is the title page of their dissertation. The way that faculty indicate their approval of the final dissertation is by signing the title page, and students are required to leave space on the title page for this purpose. It’s up to the student to run around to all their committee members (mine had 5) and get them to sign. Holding the final title page, with all the signatures, this bland sheet of acid-free paper that signifies that your hard work has come to something… it’s a heady feeling.

(read more)

Principles of Research Code

Ali Eslami has just writen a terrific page on organizing your experimental code and output. I pretty much agree with everything he says. I’ve thought quite a bit about this and would like to add some background. Programming for research is very different than programming for industry. There are several reasons for this, which I will call Principles of Research Code. These principles underly all of the advice in Ali’s post and in this post. These principles are:

(read more)