Dear friends,
It has been a while, I know. My tweets, posts, and overall online ponderings have dwindled this last year. But a lot has happened! I finished up my Ph.D. research, wrote up and successfully defended my dissertation, graduated from the University of Florida, and started as a postdoc at Yale University.
Featured: my wife, Begüm, UF Ph.D. grad ’15, aerospace engineering.
Now that we are (almost) all moved and the work/life balance is settling into somewhat normalcy I have had some time to reflect on my graduate school experience. I was thinking about writing a post on “what I wish I learned sooner” or “what I would tell myself 6 years ago”, but after giving it some thought I realized that I wouldn’t change anything about my path through grad school. Every lesson that I learned “the hard way” was a necessary struggle. Nevertheless, I’d like to share some of the lessons I learned the hard way, and maybe if you are reading this as a first year graduate student you can keep them in mind as you forge your own path and learn your own lessons. So, off the top of my head, things I learned the hard way, in no particular order:
- Treat grad school like a 9-5 job.
When I first got to graduate school the postdoc in our lab suggested I treat graduate school like a 9-5 job. As in, have the discipline to go work every workday, even if you do not have any obvious obligations. It was easy to not do this, since my advisor didn’t set any rules about being in the lab, my work didn’t revolve around keeping lab animals happy, and I only taught a few days a week. Plus, I just moved to Florida and was living in a small city with 50,000 other young adults…
Grad school is a lot of work. Before you know it there will be a bunch of obligations to tend to, many of which are completely new. Teaching, grading, your own classes and homework and exams, and, hopefully, your own batch of new research. Not to mention the little things nobody talks about, like spending an entire week trying to figure out how to use a program to make one figure that you never even use.
All I’m saying is that you will thank yourself later if you build work habits and discipline early, even if you do not have any established research yet. (Thanks for the advice, April!)
That all being said, make sure you figure out when it is appropriate to close your email, turn off your phone, unplug from the internet, and take care of your mental and physical wellbeing.
- Find where you work best.
The lab wasn’t always the best place to do work. Maybe your labmates are doing intensive noisy work. Maybe people are holding office hours. Maybe the building is old and heavily used and in Florida and it fills up with cockroaches after 4pm. I went through many phases in grad school with ideas about where I worked best. In the beginning, it was the library, in the middle it was a coffee shop, and at the end it was in the lab and at home (and at the VERY end it was everywhere, all the time). And, if you have a mental block, it might be best to get up and go for a long walk and change your environment.
- Comment your code.
I know this is the first thing you learn as a new coder/programmer. I know the (good) code shared on stackexchange is beautifully commented. I know it is SO obvious that this is the best practice. But, it is easy to get lazy. Especially when you don’t think anyone else will ever see that particular batch of code.
I didn’t know how easy it is to completely forget what I just did two weeks ago. Maybe you are meeting with your advisor, and she suggests trying to do X,Y, and Z, and you say “Great idea! I actually did that two weeks ago!” and then you go to pull up your code (if you can find it, that’s another lesson I learned the hard way) and it looks like someone else wrote it.
Trust me, even if you are writing one line of code to do something fairly trivial, add a comment saying what you are doing, why you are doing it, and how it works (in English)… and how it fits in with the rest. Maybe it’ll take an extra minute that feels wasted, but it is better than actually wasting 15 minutes at some later point trying to decipher your mess. You will thank yourself when a reviewer comments on results you generated 8 months ago and you need to rerun everything! On that note, I found using github extremely useful during the latter part of my Ph.D. work. Especially when I had multiple projects going on at the same time and I needed to jump between them and remember exactly where I left off.
- Create figures directly from your code.
Perhaps you have no formal training when it comes to coding. Perhaps you learned everything in a nice GUI and you can save figures by clicking “Save Figure As…” (I learned in RStudio). Perhaps you have gone years coding and generating results and saving them to random folders throughout your computer and it has never been a problem. You finally submit the first chapter of your dissertation for peer-review, and:
“Please resubmit Figure 2 at 600 DPI.” Ok, no problem, you think: where is the code I used to generate the original figure 8 months ago? Where did I even save the original PDF?!
Better way: directly save your figures within your code. This is fairly simple in R, and I do something like this:
>#####
>#Alright, time to make that neat figure from the data generated from the code immediately above (descriptive comments throughout!)
>#Mouse, tumorigenesis incidence, things I can Ctrl+F here
>#####
>plot.count <- 0 #initialize some counter
>plot.count <- plot.count+1 #this counter goes up 1 time every time you run the code to generate a new figure in the same folder. This way, you can try a bunch of dimensions/font sizes/etc. in a row and pick which looks the best
>png(height=12,width=8,unit=”in”,res=300, file=paste(“C:/Users/Vincent/Desktop/aging/evo_tradeoff_figures/”,”mouse_combined_wline_exitseminar”,plot.count,”.png”,sep=””)) #making a png image, and now we know the exact dimensions, resolution, and where it was saved. Note that the counter is within the (descriptive) filename.
> #CODE TO OUTPUT THE PLOTS GOES HERE.
>dev.off() #Turn off the “I’m outputting images to a file now” signal.
There, now you can look back to your code and see how the figure was made, where it was saved, and easily redo it!
- Do not use powerpoint to create (manuscript) figures.
Powerpoint is great. Over the last few years I have become a powerpoint whizkid. I love it. But, I’ve come to realize that it isn’t the ideal choice when making (professional) figures. It IS great for a quick and dirty manipulation of something for a presentation. It is great because it is easy. But, when you are stitching a bunch of images together, over a background, with a specific DPI requirement, and dozens of layers, you might need something a little less easy. That’s where GIMP (GNU Image Manipulation Program) came into play. It took some getting used to, but trust me, it’s worth it. (Just like learning LaTeX over Word.)
- Set up alerts to find new papers.
Whether it is a specific journal’s Table of Contents or something like Google Scholar Alerts, do yourself a favor and set up some automated email service that alerts you to new papers in your field and interests. Even if you just take note of authors and titles and abstracts, it’ll keep you at the edge of your field, and you never know who you will meet at a conference!
- Join listservs
The messages I received through Evoldir alerted me to numerous conferences and postdoc opportunities. Worth deleting a dozen or so messages every morning.
- Join Twitter (maintain a semi-professional social media presence)
I once heard someone describe their persona on twitter akin to if they were at a beer and wine social at a conference. Professional, but also fun and somewhat personal. Through Twitter I have shared my interests, met many researchers in my field, and have had my research (e.g. slides at a conference) sent out to tens of thousands of people. It’s great! Plus, you never know, maybe your university will even pick up on your story and want to share it with the world.
- Give talks!!
My graduate career has been punctuated by the talks I’ve given. Nothing helps you solidify your thoughts and results like having to announce them to a group of colleagues. Invite the meanest, most critical, and intimidating professors you can think of, because they will probably have the best feedback. Invite mathematicians if you describe math. If you have the opportunity to present in an informal setting, then share new half-baked ideas with colleagues. I can’t stress this enough, sharing your work with the field is one of the most challenging and rewarding parts of graduate school.
If you went through this journey and want to share some things you learned the hard way, let me know! I’ll update if I think of anything else.
Vincent Cannataro, Ph.D. 