Last summer, I spent a good chunk of my time doing an undergraduate research project during which I worked on a project largely by myself, under the supervision of a math professor. I then took a graduate level course in a related area this fall, where I investigated the theoretical underpinning behind my summer project. I had no idea what I was doing or what I had gotten myself into. As a result, I learned a lot, and tried to keep note of the various things I had learned. This is the first installment, on what I learned from trying to read math and theoretical CS papers.

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.

I’ve been spending a lot of time thinking about how I dress lately, which I think is something that happens to you when you’re in your early twenties and trying to figure out how to be a “professional”. I think dress codes were always sort of a sticking point for many people, but from what I understand, in the pre-covid era there were many workplaces with very strong implicit or explicit dress codes that (I am told) made it very easy, or at the very least, easier to understand how you were supposed to dress.

When you call yourself a “talentless hack” (which you probably don’t, but you might if we share a similar sense of humour), it’s likely for one of two reasons: either you’re caught in a situation where you suddenly have to perform or get results or do something, with zero experience or knowledge of what’s going on (at which point feeling like “a hack” is somewhat legitimate), or you’re doing it out of self-deprecation because you have imposter syndrome.