One of the things that has been repeatedly drilled into me over the past year or so is the fact that if you want people to do things for you, you’re most likely going to have to harass them. (I don’t mean literal harassment, by the way – please don’t commit a criminal offense and say I encouraged you.) This is true especially when working with highly busy people like managers and professors. If you want something, you can’t just assume they’ll intuit that and give it to you – you have to ask (and assume they’ll forget, then ask them again). If you need them to do something for you, you’ll need to remind them, and inform them of the deadline, likely multiple times. Everyone has their own problems to worry about and the thing you need might not be top of mind. The burden of remembering is on you.

Last summer, I was tasked with writing a report about the research I completed and submitting it to my supervisor by the end of the summer. I, of course, had never done this kind of writing before, so I learned several lessons. The hard way. The learning process was super painful, but it did come in handy when I had to write two other research reports in my classes last fall. Here are a few of the lessons I learned.

Today, I found out that some students at Carleton University have started a “webring” (or well, close enough) for students in computer science and engineering to post their personal websites. (In fact, this blog also joined that webring, and you can find a link to the rest of the pages in the webring here.) I thought this was a really cool idea, so I asked how they came up with it. It turns out that a few other CS and software engineering (+ adjacent) programs in Canada have also started such webrings.

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.

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.