Aaron Turon on Rust: From POPL to Practice, POPL ‘17

Why and How Undergraduate Students Should Attend Academic Conferences

Fortune Cookie Insights from PLMW@POPL

Don’t worry if you don’t know what’s going on during a talk,” my professor and research supervisor Ron Garcia said to me a few days before we were to fly to Paris, “Most of the people in the room don’t either.”

Looking over the program, I was a bit anxious about trying to create a schedule for my week at Principles of Programming Languages (POPL) when I couldn’t even understand any of the titles of the talks.

But attending a conference as an undergrad is especially awesome because:

  • you see the current research being conducted in the field
  • you meet lots of more senior students and researchers and start building relationships
  • you learn how to digest information from technical talks and papers
  • you discover new interesting papers from going to talks, and then have some background when you go to read them later
  • you can ask real researchers about what life in academia is really like, and the (many) different paths you can take

Luckily, as a student I was slated to go the Programming Languages Mentoring Workshop before POPL, which was supposed to be a day of sessions on the coolest new PL research that people were working on, as well as talks on how to best prepare for and navigate a career in academia from some of the most vibrant researchers in the programming languages community. It ended up being indispensable to me as a guide on how to attend POPL later that week, and also how to approach this undergraduate research project I’m starting with Ron.

So, I’ve compiled (ha, ha) some of my favourite bits from the workshop and throughout the week, hopefully as digestible as fortune cookie fortunes, to any computer science student curious about academia.


On seeing the cutting-edge stuff

There’s so much cool stuff going on in computer science that I’m constantly finding new things to geek out about. Thankfully, some amazing research is happening at the intersection of fields, which means I don’t have to choose.

For example, let’s talk about code generation.

There are so many public codebases out on Github. Martin Vechev and his lab at ETH Zurich are looking at using probabilistic learning to generate code solutions to hard problems. In other words, why don’t we use machine learning to teach computers how to predict code to help software engineers? (Of course, this is a very difficult problem, one of the challenges being that we have to decide what it is that determines how to fill in the blanks in a line of code.)

I just love the idea of zipping together concepts from computer science subfields (like in this case, combining machine learning, programming languages and software engineering — all things I’m finding super neat right now).

On how to meet people at conferences

So I didn’t realize that famous people go to these things.

But as a student, while you still don’t know who the famous people are, you should feel free to talk to whomever you want! After you Google them, you might lose your nerve.

It also helps if you go with someone who can introduce you to other people (thanks, Ron!). That’s why attending PLMW before POPL was so nice, because I could always approach the mentors and tell them what I enjoyed about their talk (which I did many times).

If you had a meaningful conversation with someone and you’d like to keep in touch, ask for an email or look them up and send them a note. You never know if that person could become a potential collaborator, a mentor or a new friend.

On how to give and listen to a good talk

A talk has 4 parts: the motivation, the key idea and contributions, the explanation of the key idea, and the conclusion.

Don’t skip the motivation! You must clearly state your problem to convince your audience that it is a hard problem, and that they should care. Then you can proudly state your contributions and give your audience the take home message: your key idea.

When you’re a student with very little background and trying to follow the lengthy technical explanations of the solution is just about impossible, these are some great points to try and tease out as you follow along.

On how to read and write a paper

As a researcher, coming up with new information is not enough, and failing to communicate it effectively creates no value. Papers that are easy to read are hard to write because of the difficulty in imagining your reader not knowing what you know.

Whether you’re the reader or the writer, orient yourself by identifying the landmarks: the key idea and contributions. Try to relate every point made in the paper back to them.

Specifically on reading, the dense technical information is what gets in the way of your understanding. Try the three-pass read instead — read from the outside in (grasp the intro and conclusion first, then to understand the big ideas in the interior sections, then in fine detail).

On how to do research when you’re new

Research is all about producing new knowledge.

When you’re just starting, finding a problem that you can solve is difficult! You’ll have to shift your mindset on how to approach a problem because you don’t have a guarantee that there is a solution like you do in class. You don’t know how long it might take to find a solution, although you’re expected to constantly be making progress. You may have to redefine your problem and change the questions you’re asking along the way.

Keeping all of this in mind, a good thing to do is to get on a small project that a) someone you respect has deemed worthwhile and b) has a well-defined technical scope.

This is great because at the end of it, you’ll have collaborated with someone with more experience, learned some stuff about solution-finding methods, and have something tangible to show for your efforts (like a paper or some code). Undergraduate research with a favourite professor is the perfect way to do this!

On being happy while doing research

When trying to decide whether or not to pursue research, one thing to ask yourself is whether you get more satisfaction from building things yourself, or discovering ways to build things and then sharing this with others who will hopefully build on your insights (this was shared with me by Nada, who spent time at Google before deciding to return to school).

Computer science researchers usually go into either academia or industrial research. Doing research in industry can mean that your research outcomes evolve depending on the project, and sometimes you work on projects with more scientific impact and other times projects with more industrial impact or business value.

Wherever you end up, a research career requires making decisions about how you want to spend your time. There’s always more to do, and you don’t really have a boss telling you what’s important.

So you have to learn to say no.

It’s much worse to say yes to something and do a bad job than to just decline to do it. And get back to people about stuff quickly, especially if it’s a rejection.


Coming home from this conference, I’ve started imagining how I might be able to contribute to computer science research. I’ve started thinking about going to grad school. And I’d definitely love to attend POPL 2018.

You can find all of the slides from PLMW and POPL 2017 here, and this article contains many references to that material.