I’ve pretty much neglected this blog since last summer, but with the current school year over (yay!) I thought it would be a good time to do some retrospective blogging.
I had the pleasure of collaborating with a various great people on research projects this semester.
Jack Feser, Micah Smith and I collaborated (under supervision of Sam Madden) on a database for dynamic missing value imputation and wrote up a paper, which after a round of review-based revisions, turned out quite nicely I think (we still have to hear back on this latest round of reviews).
I also worked with Phillip Stanley-Marbell and Martin Rinard (my advisor) on two interesting projects related to color perception. The first project constitutes the first large-scale color perception study across different countries, based on iOS data, while the second used the same dataset to perform customized image compression. We wrote up the second of these and submitted to a small conference, and are in the process of polishing off the first before submitting to a conference venue.
I think I managed to get a lot out of these three research experiences. Working with great people pushed me to try to improve my own skills and bring more to the table. I wanted to sum up my thoughts and personal lessons in a list of observations. As a disclaimer, I’m certainly not trying to give advice to anyone else on this. I have no real qualifications to do so, and a year of phd program is hardly a long time as far as experience goes, but I thought I’d like to keep this for posterity for myself (and maybe it will help some other first-year in the future). So some takeaways from all of this (in bullet form, and in no particular order):
- Revisiting ideas is extremely worthwhile. Our first stab at the image compression project flat out failed. I had the wrong approach to it. The second time around, rather than stabbing in the dark, we brainstormed about the core issue with what I was doing and our goals, and tried to find a solution that bridged the two. The second approach that came out of this worked.
- Many systems make tradeoff decisions for the user. Exposing these tradeoffs and letting the user choose for themselves feels like a cleaner approach. Indeed, these tradeoffs themselves can be the most interesting part of your system. Our database work showed that formulating these tradeoffs in a rigorous way can be a novel contribution itself.
- Writing up the paper, as you work through the problem, can help direct your efforts. It is basically a concrete way of tackling the question: “what do I need to show to convince a colleague of the novelty/effectiveness/impact of my idea/technique/system?”. This isn’t my own observation, but rather the product of great advice from Phillip and a Simon Peyton-Jones video he recommended. I highly recommend doing this and plan on doing this going forward.
- Related to the point above: spending time writing up your problem statement before diving in. This helps formalize the problem, which in turn can expose good approaches to tackling it, or point you in the right direction. This is an approach Martin emphasized from day one, and I think it has a lot of real benefits.
- Have two projects going simultaneously. When I had a single project, getting stuck or not feeling excited about the problem was a big drag on my productivity. When I started working on two projects at a time, I could just switch to the other problem whenever I got tired of one. This made work a lot more enjoyable and productive. Some people may be able to manage more than two projects, but for me three started to get too hectic.
- In terms of school work/classes, I had to make a big effort to switch the way I approached classes. In undergrad, and even in my masters, courses were a big focus, so it always made sense to spend additional time polishing homeworks/projects or studying for a test. Although there were diminishing returns on that time, it felt worthwhile. This time around, I’ve tried to switch my approach. I put in enough time to make sure I understand the core idea or takeaway, but after that, a couple of points are not really worth it, and that time is better spent on research.
- Volunteer to organize at least one event for your department or lab. Advisors seem understanding of the fact that you are getting used to new work, a new environment, and potentially, a new field or research area. This means research output is not necessarily the right metric for the first year. This also means that you can volunteer for events that you might not want to (or be able to) once you are steeped deep in your research work. I had the pleasure of collaborating with a bunch of great people this semester on organizational events. In doing so, I met other students (junior and senior), faculty members, and community members that I wouldn’t have otherwise had the chance to meet as easily. Candace Ross and I helped put together the first diversity panel at the EECS admitted students visit weekend, and along with Ivan Kuraj, I helped plan the 2017 programming languages offsite.
- Recognizing that different people have different research styles and tastes is incredibly useful. For example, I’ve learned that, at least at this point in my grad career, I like starting out with a concrete problem (e.g. missing values in a database are a pain to work with) and then letting the problem steer me to the appropriate solution. Other people may like the idea of developing a core technique, and then finding a problem that it solves. While the latter sounds cool to me, I have a hard time conceptualizing solutions without concrete and motivating examples.
- I’m making a conscious effort not to stress or place emphasis on producing “worthwhile” results. By that I mean: results aren’t just the final product of your research. Getting the database setup for your project, or finally setting up your VM for experiments, can also be “results”. This may seem like I’m simply redefining the meaning of results to suit me and feel positive. But it’s actually amazing how much of a psychological impact this redefinition had on me. During my first couple of months, I struggled with the fact that I wasn’t “producing results”. Eventually Martin pointed out that all of these small things were results, and that productivity took many forms. This insight was momentous for changing my whole mindset for the Spring semester.
- A related point: don’t think about research as producing results for your advisor, produce them for yourself. This isn’t to say that you should ignore specific requests from your advisor. Clearly, they are (likely/hopefully) providing you with funding and the opportunity to work with them, so you do have a responsibility to deliver on that. However, the results you produce, and the work you do, should be for yourself. There is a large opportunity cost in attending graduate school, and you should make sure you do not short-change yourself by pursuing topics that you are not interested in. Martin has made this point to our group repeatedly, and is one of the points I think I have appreciated the most. I realize this is an enormous privilege to have, and I am working to deliver on that opportunity.
- A less positive point, but one that I think is very important: own your mistakes. I fudged up some data pre-processing for our database evaluation. We figured this out after Micah and Jack had spent a non-trivial amount of time dealing with frustrating queries that didn’t match up with expectation (based on what they thought the preprocessing had been). In the end, we realized there had been a miscommunication, along with poor documentation on my part. This was a good lesson and one that I’m happy worked out with no lasting negative impact on others or myself.
- Related to the prior point: own your mistakes, but also move on. There is no point in dwelling on something messed up. You fix it, apologize, take note for the future, and move on. Anything else is just bad for productivity and (more importantly) well-being.
- Asking colleagues for help when you’re stuck, and similarly providing help when you’re in a position do so, is one of the greatest benefits of being part of an academic community. I’ve been beyond pleased to see how open and helpful others are. I like to think I’ve been of help to others as well, but for the coming year I’m making a conscious effort to offer my help whenever possible.
- A bit more mundane: I’ve started using a time management application (Asana) to write out my TODOs by day and group them by project. It may be overkill for my purposes, but I have squeezed out a lot of order from my days this way. In general, I’ve realized that having two major TODOs per day, along with smaller tasks, is a good way to split up my time. I make an effort to make at least one of those major TODOs be research-related. Major TODOs in my mind are things like a significant amount of coding, writing up a problem, or setting up an evaluation benchmark etc.
Those are the main points, off the top of my head. I’m looking forward to this summer. I’ll be staying at school and getting started on a research project I’m very excited about. Hopefully I’ll get a chance to write up at least one blog post along the way.