>What I wish people had told me when I started graduate studies

>I suggested to my friend (who finished his masters degree last year) that he should know everything there is to know about grad school and should write a book on it – and he declined.

So, I spent some time thinking this morning about what advice I’d pass along to grad students who are just starting out, which resulted in this post: 10 things I’d like to tell new grad students. If I do a second post on the topic, it might include advice specifically targeted for bioinformatics students, but that’s a long way off. Either way, please feel free to add comments on this post. I’m sure I have missed things.

At any rate, this advice is for people who are already in grad school or are about to start. None of this will convince you to stay here if you’re doubting yourself (we all did), or if you’re trying to weather the ups and downs. (we all have them too…) There are already excellent resources out there for that, with which I can’t hope to contribute anything. So, for those of you who are ready to stick it out, here’s my advice:

  1. Keep good notes! Believe it or not, just about everything you ever do as a graduate student will some day be useful – you’ll be writing a presentation and realize you just need that one number you collected in your first 8 months in the lab, or you’ll remember that you did some long drawn out set of scripts at one point and running them again would be useful – if only you’d written them down… I guarantee that good and complete notes will knock at least a month or two off of time you spend in school.
  2. Keep yourself motivated. I won’t beat around the bush here. There will be days you don’t want to work. There might even be weeks or months. Sometimes it’ll be burnout, sometimes it’ll just be depression (experiments don’t always work) and sometimes it’ll just be plain laziness. Whatever it is, you’re going to have to find a way to power through it and keep your momentum. One of the best pieces of advice I’ve had is to start each day or week by setting goals and then holding myself to them. You can seriously improve your work ethic this way.
  3. Keep sight of the big picture. Remember that you’re working on something innovative and creative, and the little details like software bugs and optimizing protocols are just stepping stones along the way. It’s easy to get sucked into the mindset that your job is only those details, but if you keep sight of the big picture, you’ll have an easier time evaluating what it is you really need to be doing. (Will that bug help you get a paper? No? Maybe you should spend more time writing out a more efficient algorithm anyway…) Your goal is to graduate with some cool research – and you shouldn’t be working on the details unless they get you there – or accomplish a goal that is clearly useful to you.
  4. Learn everything you can. One of those magic things about grad school is that you’re given free reign to learn. Use it! Learn new software applications, learn new subjects, learn new hobbies. You never know what will be a help to you in the future or will help you get a job down the road. I learned to snowboard while doing my masters degree, and it turned out to be the only way to get sunshine in January in Vancouver, which is probably the only reason I don’t get S.A.D. every year (and spend a month or two without the ability to get things done.) Seriously – Just about every skill you pick up will help you out somehow… one day.
  5. Build your community. Grad school is also one of those few times in your life when everyone is willing to talk to you. You’ve already established you’re not a fool by finishing your undergrad and getting into graduate school, so nearly everyone will be willing to give you the time of day and most of them will even be willing to give you advice on how to make your life easier. You never know who might be able to help you later in life, and you never know who might turn into a great friend. Go forth and meet your peers! They’ll provide support when (not if) you need it, and can help you work through your problems – and remember, your peers aren’t all in the same lab or university as you.
  6. Don’t be afraid to take/ignore advice. Ok, so you asked the Nobel prize winner that hangs out in the cafeteria for some advice on your project. First of all, remember that it’s just advice. If you’re doing science, no one actually knows the answer (unless they beat you to the experiment), so take all the advice you get with a grain of salt. Remember to judge the advice upon it’s merits, rather than upon the status of the person who gives it. Nobel prize winners can give advice that’s every bit as bad as the next person, and even a “lowly undergrad” can point you in the right direction now and then. Even if the Nobel prize winning scientist tells you it’s the dumbest thing they’ve ever heard, don’t be afraid to test it out now and then. Of course, don’t forget to remember that sometimes dumb ideas really are dumb, and sometimes it is worth listening to the advice. A good scientist will eventually figure out the difference and know which leads to test out. In the meantime, be courageous and try to be insightful when evaluating what people tell you.
  7. Don’t fall prey to false economy reasoning. One of those things I’ve gotten used to hearing are comments like “I don’t have time to clean up my code – I need to put in new features!” or ” I can’t learn how to use a new tool, I just need the results.” This is called false economy: when you forget that investments pay dividends in the long term, and only take the short term goals into account. For one good example, I learned how to use professional desktop publishing software, which forced me to spend a whole week making a single poster. Ever since then, I’ve been able to reuse the template and rely on that learned skill set to bang out posters in about 2 days each – and I’ve done 7 or 8 by since. By investing the time, I’ve become much more productive in the long term. (And yes, spending a week on cleaning up your code will save you weeks or months on debugging and ease of future coding.)
  8. Be assertive about what you want. Many beginning grad students are intimidated by the people around them just because everyone else is more senior, and that can be devastating to your own ambitions. You can easily get sucked into other people’s projects, goals or even politics if you’re afraid to strike out on your own. Remember that you are an individual and you have your own tasks to accomplish. Be assertive about what you think will help you achieve those goals and get you through the project. On the other hand, don’t forget to respect your peers – you probably won’t make it through if you piss them all off.
  9. Nothing will be perfect. Several years in, this one still gets me. No publication is ever perfect, your results don’t need to be bulletproof before you publish them and posters will never tell you the whole story. Do the best you can, and try to do as much as you can, and revisions will help you fix everything else up as you go. That is to say, try to balance out your ability to pay attention to details (don’t be sloppy), but don’t expect to have every last detail in place before you start writing it up.
  10. Write lots. As a grad student, your productivity is measured by your ability to publish what you’ve done. However, that’s not the only measure you should take of your time as a grad student. Write as much as you can, and practice your communication skills. The more you write, the more you learn about how to get your point across. Write emails to build up your network, write a blog to practice getting your point across, write publications to build your resume and write notes to cultivate it as a habit. The more you write, and it doesn’t really matter what you write, the better off you’ll be.

So, there you have it. 10 things you can do that will enhance your grad student experience. If you need more advice, try this site, which has more collected advice than any other place I’ve ever seen.

Good luck and good publishing!


>This week has been a tremendous confluence of concepts and ideas around community. Not that I’d expect anyone else to notice, but it really kept building towards a common theme.

The first was just a community of co-workers. Last week, my lab went out to celebrate a lab-mate’s successful defense of her thesis (Congrats, Dr. Sleumer!). During the second round of drinks (Undrinkable dirty martinis), several of us had a half hour conversation on the best way to desalinate an over-salty martini. As weird as it sounds, it was an interesting and fun conversation, which I just can’t imagine having with too many people. (By the way, I think Obi’s suggestion wins: distillation.) This is not a group of people you want to take for granted!

The second community related event was an invitation to move my blog over to a larger community of bloggers. While I’ve temporarily declined, it raised the question of what kind of community I have while I keep my blog on my own server. In some ways, it leaves me isolated, although it does provide a “distinct” source of information, easily distinguishable from other people’s blogs. (One of the reasons for not moving the larger community is the lack of distinguishing marks – I don’t want to sink into a “borg” experience with other bloggers and just become assimilated entirely.) Is it worth moving over to reduce the isolation and become part of a bigger community, even if it means losing some of my identity?

The third event was a talk I gave this morning. I spent a lot of time trying to put together a coherent presentation – and ended talking about my experiences without discussing the actual focus of my research. Instead, it was on the topic of “successes and failures in developing an open source community” as applied to the Vancouver Short Read Analysis Package. Yes, I’m happy there is a (small) community around it, but there is definitely room for improvement.

Anyhow, at the risk of babbling on too much, what I really wanted to say is that communities are all around us, and we have to seriously consider our impact on them, and the impact they have on us – not to mention how we integrate into them, both in our work and outside. If you can’t maximize your ability to motivate them (or their ability to motivate you), then you’re at a serious disadvantage. How we balance all of that is an open question, and one I’m still working hard at answering.

I’ve attached my presentation from this morning, just in case anyone is interested. (I’ve decorated it with pictures from the South Pacific, in case all of the plain text is too boring to keep you awake.)

Here it is (it’s about 7Mb.)

>New Tool: KeepNote

>Obviously I haven’t updated much here lately – I’ve been pretty busy and inspiration hasn’t struck me much in the last few days to get anything written. However, I started using some new software this morning, and I’m enjoying it so much I figured I have to share.

One of the big problems I have, as a bioinformatician, is keeping track of all the notes and one off scripts I write. I don’t want to use an SVN, because it’s just a repository with no organization. I don’t want to use a wiki, because it’s a huge hassle to maintain for small projects, and I hate using text files.

The compromise, it seems, is to use standards compliant files with a hell of a wrapper around them that does the organization for you, and the one I found is called KeepNote. The project page and downloads can be found at http://rasm.ods.org/keepnote/. The software is available for all major OS (Linux, Mac and even Windows), and can be installed relatively quickly and (for the most part) painlessly. (Linux builds are missing a library in the dependencies, but that can be figured out pretty quickly – just apt-get the missing lib and re-install if you hit this problem.)

While it may not fit everyone’s workflow, my few hours of using it have already helped me get my tools organized and assembled in a logical manner, and it’s allowed me to remove a load of files from my desktop. There are still bugs with it: I had to manually do some configuration of the the web browser, text editor and such before I could get started, but so far I haven’t hit any of the bugs.

It also claims to help you organize notes – which I can clearly see. next time I go to a conference, I’ll be using this for recording and organizing the usual 30-40 pages of notes I take.

For me, this falls under the heading of required tools for bioinformaticians and students alike and I look forward to seeing the project evolve and grow.