It’s admissions season for Computer Science PhD programs.As I spend the majority of my week in zoom meetings with prospective students, I keep thinking about this post that I’ve been meaning to write ever since I defended my dissertation. There’s a ton of posts on the web about applying to grad school and how to be successful as a researcher and a student. However, there were a few small things that made so much more of a difference for me. These are things that most people don’t really talk about, so I figured I’d just haphazardly collect them in an incomplete list here.

1.) Go to your lab.

When it is safe, go to your lab. It’s nice being able to work remotely, and if the early 20’s have demonstrated anything, it’s that you can be very successful not on campus. However, most of the things on this list came out of conversations with other students, organically, as we slogged through classes and research in grad student offices. This list would be much shorter without random comments from others who glanced over at me and noticed what I was doing wrong.

2.) vim.

I mean, I guess emacs is ok as well, but I was peer-pressured into vim my first month of grad school. And I never looked back. Plus about a year later, I was in a meeting with a very senior researcher who I very much admired. He saw I was using vim and said “Wow! You use vim? That’s hardcore.” That pretty much made using vim worth it. Affirmation from a researcher with tens of thousands of citations because of my text editor made me feel like I was capable of being a collaborator … and I’m only sorta joking here.

Yeah, vim can be scary initially … but it is so powerful. Yes, the most viewed post on stack overflow is how to exit vim (literally over one million views). But once you are able to navigate splitting windows, adding tabs, using advanced search functions, etc. it makes it all worth it.

I think I can safely say, vim is also the only programming tool that I learned by playing an online video game. Seriously. Go play the game. It helps. vim adventures.

3.) vimdiff.

Sure, this is a feature of vim, but it merits its own mention. This is by far the most useful tool for source control merges. It is also super helpful when looking at NLP datasets to make sure files are correct. Here’s what it looks like … and why it is so much more powerful than diff.

And this is what it looks like when they are identical.

4.) git.

Git is currently the most popular source control tool out there. Just use source control. For everything. For homework. For projects. For latex for your papers. It’s even better if you are able to point to a specific commit for a certain set of experiments you run. This will save you time in the long run. Lots and lots of time. Fun fact. There are other tools out there besides git. I worked on codebases during grad school that used SVN and CVS. Nowadays, git is fine.

5.) tig.

This was another tool pointed out to me by officemates. It is literally just the word git backwards. I have a script that I run anytime I get a new linux box. ‘sudo apt-get install tig’ is one of the first commands in the script. I build it from scratch on environments where I don’t have root access. All you do is type ‘tig’ into your terminal in a directory that is part of a git repository. Using vim commands (like I said, use vim) it shows how files have changed between commits. For complicated merges or diagnosing bugs, this simple command line tool has saved me hours upon hours.

6.) LaTeX.

You will need this for papers. And group meetings. And homework assignments. And wedding announcements(?!?!!) Nowadays, having overleaf simplifies everything sooooo much. But make sure to download files occasionally (into a git repo). The site has crashed before paper deadlines. I’m still in awe when I see senior researchers’ ability to magically transform a paper into something more beautiful using less-known latex features. This is one that I’m continuously improving on … and assume I will for the rest of my career. Start learning this as soon as you can.

7.) detexify.

Remembering all the latex commands is hard. Detexify lets you draw a symbol and it uses computer vision to identify it and give you the command. Again, this has saved me on so many late nights.

When you are accessing remote clusters and grids, tmux allows you to save your session when you exit ssh. Use it. It is helpful. Or use screen. It too is helpful.

9.) qsub.

Or whatever other job scheduler that is on shared computers you use. You do not want to be the jerk hogging resources or making the login nodes unresponsive. You really don’t. If Dante was alive today, I’m pretty sure another circle would be added for people who abuse this on clusters. For interactive sessions, you can use qrsh.

10.) slide numbers.

Eventually, you'll give a research talk. People will ask questions. Slide numbers allow them to. One of my friends in grad school didn’t have them on slides during a defense. One of his committee members stopped his talk and made him add them before he was allowed to continue. Don’t be Gary.

11.) use graphs in slides.

Yes, a table is nice in a paper. When you are giving a talk, a bar chart can be much, much more informative. This will make people actually care about your work more.

Look how much easier the information is conveyed. People can refer to the paper to see the nitty-gritty details. You can also walk through the slide. Adding each method one at a time. Visually they can see why your method is the best.

12.) Images >> Bullet Points.

Every time I gave a practice talk in grad school, my PhD advisor would challenge me to add more images and less bullet points. My presentations were always much better.

Rather than writing out what a bitext is in a bullet point, a simple graphic like this can impart significantly more information.

13.) experimental management system.

These help you manage the large number of experiments that you are running. There are quite a few. Generally, they are all useful. Ducttape is a very popular one. I’ve also used EMS and JUST.

14.) take days off.

This is included in many posts about grad school, but it is so important that I’m adding it to my list as well. It’s often repeated that a PhD is a marathon not a sprint. It takes years. You need to take weekends off and occasional vacation days. Otherwise you burn out. My first year of my masters, I watched a lot of my cohort working long hours, every day, including weekends. I worked my ### off, but I still took time off for myself to do a low-stress activity, like watching football. I eventually got my PhD. The friends that I watched working constantly - not a single one did. You cannot maintain working constantly.

Minnesota Vikings (Photo by Stephen Maturen/Getty Images)

14 Weird Ways to Hack a CS PhD Program … You’ll never guess what number 3 is

1.) Go to your lab.

2.) vim.

3.) vimdiff.

4.) git.

5.) tig.

6.) LaTeX.

7.) detexify.

8.) tmux.

9.) qsub.

10.) slide numbers.

11.) use graphs in slides.

12.) Images >> Bullet Points.

13.) experimental management system.

14.) take days off.

Contact Me

merci

sulpayki

gracias

شكرا لك

tack så mycket