In the first part of this talk, I made the case that theory is useful because it allows us to find (or at the very least, have the correct toolkit and language to explore) solutions to real-world problems. In this part, we are going to look at some examples of such problems and develop mathematical language to be able to discuss them more abstractly. I’ve put the term “real-world” in quotes in the title, because I’m going to be talking about these problems in a lot of generality. However, I want to stress that specific instances of these problems are actually relevant in industry, and I think it’ll be easy to see why once I start talking about them.

I just finished a blog post where I discuss things I’ve recently learned about how to read research papers. I almost included this as a point in that post, but I think it’s important enough to warrant its own article.

Here’s the idea: you absolutely should not be reading the sections of a research paper in order.

It took me a while to learn this one – I can’t remember if I first read this advice somewhere, if someone told it to me, or if I reverse-engineered it from advice I got about how to write papers. It doesn’t matter which one came first, really – my point is that I only found this out in a roundabout way through googling and trial and error and harassing people with questions.

If you’re a computer science student, you probably had to take an introductory discrete math course at some point. Did you enjoy it? If so, this talk probably isn’t for you, so you can feel free to skip the rest. (Or not – hopefully you feel like you can still learn something from me!) Jokes aside, it’s actually okay not to enjoy your intro to discrete math course: like, personally, I loved mine, but I also completely hated my discrete probability course and would prefer never to see it again. But I pick on discrete math because I feel like if it’s taught well, it can be a turning point for many people, and it certainly was for me.

When I’m trying to approach a highly specialized topic for the first time, one of my tactics is to find a recording of a research-geared workshop about it and watch it as my introductory crash course. The benefits of this are as follows:

• I am learning about the subject from (hopefully) a credible expert in the field.
• Workshops and talks usually try to be self-contained, which means basic background info will likely be given and I won’t have to pore through 10 different research papers, searching for an obscure definition, in vain.
• Talks typically have the benefit of including visuals and informal intuition conveyed by the speaker, which generally won’t make it into academic papers, because they’re not rigorous. However, the visuals and informal statements and intuition are invaluable for gaining a better understanding of the information.
• The speaker will generally include a bibliography and mention related works, which is a great jumping off point for further investigation and saves me from having to figure out what the seminal sources are myself.

However, there are also some drawbacks:

One of my quests during the research project I did last summer was to find a way to simulate pointers in Python, or at the very least, get some sort of named reference-like behaviour from the language. Unfortunately, I quickly learned that this is quasi-impossible, because Python is a language that aims to abstract as many implementation details away from the user as possible, and gives programmers very limited ways in which to interact with the language.