The Exclusive Or

It’s hard to remember what machine learning conferences were like in person, but I think that I liked them a lot better when the field was smaller. It was easier to meet new people, to talk about new ideas in small groups of talented people who were really excited by them. The culture of the field has changed from back then, in intellectual ways that you know already, but the social ways are worth reflecting on, too.

Romanticizing the past is a sorry hobby for old men. I will not do that. All research communities have a callous system at their core — I’ve written about the toxic forces that drive and derail research careers — that’s always been the case.

I got a question the other day about how to start a career in machine learning. I gave the best answer that I could, but I’m not sure that my best was very good. Can you help? If so, join the discussion on social media (or send me a note privately):

If you’re reading this blog, then you already know about PhD Comics. If you really haven’t seen them before, click the link and read them now. They are more insightful and funnier than anything in this blog.

I’m a sucker for New Year’s resolutions. Every year I make up a half dozen resolutions, usually the same ones each year, and carefully track my progress for at least two or three months before I get busy and forget all about them. And in all seriousness, I’m happy about this, because sometimes, for maybe one resolution in four, I’m still able to make a lasting change in my habits. That’s more than enough to justify the effort, as long as I take the failures in good humor.

A lot of scientific communication happens at poster sessions. It’s a great way to learn about the field, and to meet new people with similar research interests. It’s also a great way to be noticed in a crowded research field. Presenting a poster is just as important, and requires as much specialized skill, as giving a 25-minute talk. Way back when, before this blog became what it is, I wrote advice for presenting research posters. Back when I started attending research conferences, advice like that was probably good enough.

The fourth in a tidal wave of posts about stress in research.

The third post in what is becoming an increasingly long series on stress in research.

The second post in what is perhaps a series on stress in research.

Perhaps the first post in a series.

We had a fun time on the professors’ Facebook the other day, swapping stories of the dumbest travel mistakes that we’ve made. You know, booking flights to the wrong country, forgetting to book a hotel, registering for the conference twice, and other such hilarity.

There’s lots of advice you can read about how to read a research paper. There’s some good advice in this paper:

I’ve tried a lot of different methods to organize my email. None of them work.

Several students have recently asked me for advice about time management. When people ask you a important and difficult question like this, usually the best thing is to think of someone else who can give a better answer than you. For time management, an obvious person to turn to is the late Randy Pausch, a noted computer scientist who became an internet sensation because of an inspirational lecture that he gave after he had been diagnosed with terminal cancer.

Of the many quirks shared by computer scientists, one that has somewhat entered the popular culture is the use of computing metaphors to speak about how we think. For example, “multitasking” is actually a technical term invented by computer scientists in the 1960s to describe the way a computer pretends to execute many programs at once, even if in reality it can only do one thing at a time. You can see why the term would have been quickly co-opted to metaphorically describe humans who attempt the same trick.

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.

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.

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).

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.

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.

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.

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?

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

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.

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: