Tag Archives: phd support

time management tips for assistant professors (and everyone)

I recently saw a short list of advice for new assistant professors by Chris Blattman [Link]. Chris is an Assistant Professor of Political Science & International and Public Affairs at Columbia University (soon to be tenured). His list is summarized below. Go to his blog post for the full discussion:

  1. Learn to say no to new projects.
  2. Have a higher bar for projects with big exit costs.
  3. Book chapters and reviews are a waste of time.
  4. Get your dissertation papers or book out.
  5. Seek out mentorship.

This list is not comprehensive. This is not a weakness, but rather an opportunity to add to the list. The above list solely focuses on research and publication for assistant professors at research intensive universities.

I have a few things to add to the list. My tips, however, narrowly focus on time management. Most aren’t just for academics.

I was on a panel at the 2012 INFORMS Annual Meeting about time management for assistant professors hosted by the Junior Faculty Interest Group. Other panelists included Mark Lewis (Cornell), Kathy Stecke (UT-Dallas), and Brian Denton (now at Michigan). The panel discussion was chaired by Shengfan Zhang at the University of Arkansas. I had recently been awarded tenure from my previous university, and Shengfan asked me to talk about how I managed to get tenure with three kids. I only had a few minutes, so I focused on four general principals of time management that I use:

  1. There are two basic rules for time management: Do less or do it faster. There are no real tricks. I recommend learning how to say no to superfluous department, college and university service that will not add value to a tenure case and to be careful with collaborations.
  2. 80% of success is just showing up.  Academics of both genders with kids married to working non-academics tend to be the “flexible” ones, who attend to children’s doctors appointments, sick days, and days off of school. It can add up unless a fair plan is in place.
  3. Be careful with how you work on the weekends and evening. This seemingly contradicts #2, but it really takes a different angle. It’s important to work “enough” but to also put in quality time. Parkinson’s Law: Work expands to fill the time available for completion, so set deadlines and give tasks less time.
  4. Make time for the important but not urgent things. I do this by getting things done before deadlines, staying on top of email (I’m learning this is much harder to do as a tenured professor), getting sleep so that I can focus on important tasks and every day. Yes, sleep is important. If I didn’t follow this advice, I would be constantly putting out fires for looming deadlines rather than working toward my research portfolio. You won’t magically have more time in the future—now is a great time to cross something off your to do list.  This idea is consistent with Stephen Covey’s “Big Rocks First” management strategy
    • Corollary: Never be so busy that you are not a good colleague—it matters for tenure (and for life).

If you want a comprehensive list, the best I have seen is Shane Henderson’s paper “Staying Sane on the Tenure Track” published in the 2008 Winter Simulation Conference [Link]. My favorite part:

Do not work 14 hours a day, assuming life gets calmer after tenure. It doesn’t. It gets busier

What would you add?


do you have a 30 second elevator talk about your research?

I attended an interesting talk at the AAAS Meeting about science cafes (Link) organized by NOVA on PBS. Their science cafes are groups that meet once per month in a cafe or casual setting, where a scientific expert on an interesting topic has a conversation about their research with whomever wants to attend. The science cafes are open to the public and appeal to scientists as well as those who may be intimidated by coming to a research seminar at a university.

Sciencecafes.org has some tips for their speakers (Link), since speaking at a science cafe is not like giving a seminar or lecture. It’s all about creating a science with the public.

Their tips:

1. Introduce yourself and why you got interested in your research. Tell a story and maybe a funny anecdote.

2. Talk about your research using no jargon for a max of 10 minutes. No slides! You can still have visuals, such as pictures on a tablet.

They stressed that visual hooks can be very powerful. Powerful visuals can motivate the problem and be produced by someone other than you. They recommended props, such as microbes that can be passed around. In OR, we could pass around a polytope or a picture of an optimal TSP route.

3. The last 40-50 minutes are for Q&A and dialog.

This advice is really good for some settings, but it’s not something that you should do in a conference talk or seminar, which is why I am putting the advice in a blog post. There is a difference between talking to your colleagues and talking to your dean or an NSF program officer while in an elevator or while waiting in line for coffee. You have to be good at both.

Part of being successful is having a good 30 second “elevator talk” about your work that outlines:

– what you are working on
– why it’s important
– what we will be able to do differently if you are successful

I tell PhD students that they should be able to explain their dissertation contributions to me in a 30 second elevator speech at their defense. It’s really hard to put your dissertation into a 3o second box after you put all your blood, sweat, and tears in it. But this skill will be invaluable on the job search and afterward.

For tips on 30 second elevator speech visit NOVA’s secret life of scientists and engineers.

Do you have a 30 second elevator talk?


how to choose a good academic family

Professors are not evil

Professors are not evil!

Professors are like ninjas!

Professors are like ninjas. Who knew?

A good advisor will help you learn how to write journal articles

A good advisor will help you learn how to write journal articles.

Professor approved holidays

Professor approved holidays


so you’re thinking about graduate school in operations research

Today I gave a talk about applying to graduate school for the Math Club at VCU. My slides are below.

Here are a few links:

  • Advice on a career in operations research from INFORMS. I wish I had known about this link before–this FAQ answers many questions that students ask me.
  • A list of ORMS departments in the US from INFORMS.
  • By now, you’ve probably realized that you should become a member of INFORMS. It’s frugal ($37 per year) and valuable. Go for it! If you are not into OR, join AMS, ASA, ACM, SIAM, or whatever interests you.
  • Mike Trick made a plea for graduate students to sign up for twitter accounts. It’s a great idea, and I’ll let him explain why.
  • Students from state universities with strong STEM programs tend to be the most recruited in the nation. Those are great choices if you want a job when you graduate.
  • The students at the talk recommended forums, including the Xkcd forums and Grad café forums
  • One of the students at the talk recommended the book Getting what you came for: The Smart Student’s Guide to Earning an M.A. or a Ph.D.
  • I maintain some advice for student researchers. This advice illustrates some of the expectations for you in grad school. If it doesn’t frighten you, then graduate school might be a good option.

I want to thank my tweeps for their excellent advice (@tdhopper, @ksphil, @techstepper, and @dianam).


on sharing data

The National Science Foundation (NSF) started to require a data management plan for each new proposal.  The data management plan will require investigators to make their data (including figures, tables, and code) available to encourage collaboration.  An excellent idea! They specifically mention that investigators are required to document their data–not just make it available–so that others could use it, thus creating new opportunities for scientific research.  NSF’s data management plan is similar to NIH’s public access plan, which requires that publications from NIH-funded research are publicly available through Pubmed Central with twelve months of publication.

The research world is moving toward a place where investigators are required to share data and code.  I once wrote about my insecurities surrounding sharing my code.  While I don’t have insecurities about sharing my data (except trying to find extra time to document data better), I do need to think about creating a system for posting my research materials.  I’m not sure what the solution should look like.

What is the best place online for sharing research materials?  How should code be stored and formatted?  Tables, figures, data, and code have different formats.  It’s best if they are all stored (or accessed) in the same location.

My university does not have the best tools for sharing data (at least not that I know of).  Just updating my web site is a pain.  I use my university’s BlackBoard page for my research group that contains my code, papers, references, slides, and whatever else I get tired of emailing students.  However, my BlackBoard site is a closed system that does not allow guests even at my university to have access, so it cannot be used to share data to the public.

Dropbox may be a good place to store many documents, given that a separate page links to all of the stored data, although I am loathe to use my precious Dropbox space for storing data.  Slideshare and Scribd are good places for sharing slides and technical reports, respectively.  Code can be zipped and uploaded elsewhere.  But having to store each type of file in a different account on a different site would not exactly facilitate sharing information with others (and no fun for me to keep track of all the different logins and passwords), but I could create a Google Sites page to manage the information so that it can be accessed from a single page.

How do you share your data?  How do you find time to document your data?

Related posts:


on sharing code

I was recently asked for some of my code that I used in a paper.  First of all, I should firmly state that people should share code. Sharing and openly sharing ideas is, after all, the hallmark of academic research.

I am not often asked for code, and I had a few reactions to a recent request, which was made by a student.  My first reaction was that of a professor: should I give the student a fish or teach the student how to fish?  When I am usually asked for code, the request is extremely short with no context given, meaning that it is hard for me to gauge how hard the student had tried to get the program to work.  Was there a typo in the paper that is causing a problem? Where are they stuck?  What types of programming errors are they getting?  Are they simply being lazy?  I just don’t know.

This particular request relied on code that was about 20 lines of code.   Most of my projects are longer, usually comprising of hundreds or thousands of lines of code (I don’t really count, but they can get hairy).  I found myself wondering if the requester–a graduate student–really had thought about how to run the code or was just emailing me.  I exchanged a few emails with the requester before sending my code to make sure that I wasn’t doing someone’s homework for them.

Another recent request asked for code in a paper that I did the computational work for when I was in graduate school.  I looked at the pseudo-code in the paper draft and wrote the code.  It took me a day or so to get my code working, but it wasn’t particularly painful.  In this case, I was confident that the paper was clear and unambiguous about how to write the code.

My second concern about sharing code is–and I’m being honest here–my code is one giant hack.  I am not a software programmer.  I know what good, elegant code looks like, and it’s not mine.  I often have to cobble together multiple programs to solve a problem from beginning to end.  I often write a script to run many copies of the same program with different inputs.  I always write code for analyzing the solutions and creating figures.  Over the years, I have gotten good at making my code readable to me, so that I can come back to it after months or years and figure out what I did.  But that’s not the same thing as being readable to someone else.  This is a long way of saying that I’m a little embarrassed about sharing my code with others.  Maybe I’m just prudent and am being too hard on myself.  But I am married to a software programmer, so I very aware of how high the bar really is for “good” code.

Having someone look at my code is like inviting someone into my house before straightening up first. It’s one thing to show my messy code to a collaborator but it’s another thing to show my messy code to a stranger.  Sharing papers and tech reports is different–they are polished so they are OK to share.  This can be somewhat addressed by commenting code better.  I always start off commenting code well, but during the fog of debugging, my code usually gets a little out of control, and it’s hard to reign in after awhile.  (I’ve seen other people’s code.  I have some good programming habits–my code could be much, much worse).

However, as I am learning in my discrete optimization course this semester, even simple programming assignments such as implementing the Secretary Problem Markov decision process model can be incredibly difficult for PhD students.  They can benefit from looking at my code.  My homework solution code isn’t as wild and unruly as my research code.  I’m getting used to sharing my code for the homework solutions.

On a related note, this post by Panos Ipeirotis reflects on how to make code more robust to changes, since old code often does not run if it relies on old libraries.  Dr. Ipeirotis is a computer scientist, and it sounds like he writes more elegant code than I do.  I’m still in square one, meaning that I try to make my code readable to someone else.

How self-conscious are you about sharing your code?

 


my ode to lab notebooks

Last week, I started a new lab notebook.

My first lab notebook was a gift from my MS advisor.  On our first official meeting together, he seemed a little concerned that I wasn’t taking notes during the meeting.  He promptly gave me a lab notebook.  It was a high-quality notebook that was also given to undergraduates taking a senior design course.  I liked it.

After I filled my first notebook, I replaced it with a composition notebook.  I have continued to use composition notebooks ever since.  They are sturdy, frugal, and small–they are exactly what I need.  The pages are small enough that I am not tempted to write two ideas on the same page.  Early on, I discovered the benefit to keeping a Table of Contents (two pages at the end of the notebook).  It doesn’t take much time to maintain, since I can write an entry into the back of the book in just a few seconds after writing a page in the notebook.

I use my notebook less often these days, but I still find it vital for doing research.  In the past few years, I no longer use my lab notebook to crunch numbers, since it became too hard to find mathematical arguments that were correct given all of the dead ends.  I now write endless pages of math on scrap paper, and then copy the legitimate ideas into the notebook.  I also jot ideas into MS OneNote on my tablet PC.  OneNote is a great program that can certainly double as a lab notebook if backed up frequently, but I stick to a real lab notebook.  I print out my OneNote notes and staple them into my lab notebook.  However, I still frequently write down many of my research ideas directly into my notebook before I forget.  That is, after all, why I have a lab notebook in the first place.

The lab notebook seems to have gone the way of the dinosaur.  Are they still needed today?  I think so.

It is still a great idea to organize research thoughts and to write down research ideas before they are forgotten.  The lab notebook is perfect for that.  Dr. Rod Beavon (who offers advice for maintaining a lab notebook) reminds us that “science does not take place on the pages of textbooks or learned journals, but it is recorded [in the lab notebook]. The quality of any work is only as good as the report that remembers it when the test-tubes have long been washed up.”

Another benefit of lab notebook is that they teach students how to be organized researchers.  I have observed first-hand that grad students are not always naturally bent toward organization, partly because we professors often have low expectations for organization (compared to what students can expect in industry).  Organization builds character, and students need it to learn how to approach research in an organized way.

I have found that one drawback to using a lab notebook is that some ideas do not lend themselves to the lab notebook, since they are too sprawling or complicated or better summarized in a snippet of code.  If an idea cannot fit on a page, it is hard to understand later.  Another drawback is that research ideas for pursuing later can get lost in a notebook.  I try to copy those ideas elsewhere so I don’t forget about some of my more interesting and speculative ideas.

These days, my desk, computer, and schedule are cluttered with various tasks and obligations (teaching, service, research, personal).  But my lab notebook remains a special place just for research ideas.  I appreciate the simplicity of that.

My stack of lab notebooks

My stack of lab notebooks

Links:

Tell me about your lab notebook!