It’s almost the end of the summer, which marks the end of writing season in academia. Here is some advice for writing a scientific paper, as told through a series of tweets. What would you add?
Tag Archives: phd student advice
Legendary engineer George Heilmeier came up with a set of questions to help program managers evaluate proposals while he was director of DARPA (1975-1977):
- What are you trying to do? Articulate your objectives using absolutely no jargon.
- How is it done today, and what are the limits of current practice?
- What’s new in your approach and why do you think it will be successful?
- Who cares? If you’re successful, what difference will it make?
- What are the risks ?
- How much will it cost?
- How long will it take?
- What are the midterm and final “exams” to check for success?
This list is still used today. I most often see this list in presentations by National Science Foundation program officers who are interested in helping researchers write competitive proposals.
I love this list.
This list has stood the test of time because it’s a great list. I find questions #2 and #4 to be particularly helpful. I do so because my first inclination is to talk about why my research is interesting and exciting to me. I wouldn’t start research in a new area unless the topic were interesting and unless my skill set were brought something to the table. Being excited about my interesting research is not sufficient for giving a good answer to #2 and #4. Not all research that is “interesting” is also “important.”
When I write with my students, we talk about how we need to answer #1-#4 in the paper, although we answer slightly different versions of the questions since the research has already been successful if we are publishing the results.
I once summarized how to answer an abridged version of the Heilmeier questions in the first couple minutes of a thesis defense. When a student did so, it made for a memorable defense (in a good way!) and I tweeted about it.
One of my recent blog posts entitled “just write, damn it” got a lot of hits and positive feedback. All the feedback was for just writing and none was in favor of planning first. I was surprised that my methodological and analytical readers preferred to cannonball into writing without a lot of planning.
Someone told me about an approach to writing a dissertation that was somewhere in between just writing willy nilly and planning. It’s called the One Draft PhD Dissertation [pdf] by John Carlis, a professor of Computer Science and Engineering at Minnesota. His approach is to sketch a blueprint of a dissertation by planning what will be in each paragraph and then jump in and write each of those paragraphs. He writes:
What’s my story? While writing my dissertation and, at the same time, working as a professor (yes, it was stressful), several streams of thought happily converged. I read lots about writing, and was particularly struck by the forward to the John McPhee Reader, which described his disciplined, design-before-write way of work. I read Richard Mager’s Preparing Instructional Objectives, which has this message that translates to writing: teaching (writing) is about them, the students (readers), not the teacher (author). I taught software development using Yourdon and Constantine’s “Structured Development” (Addison-Wesley, 1975). Convergence began when the strong parallels in their content struck me. By then I already believed that software should be designed and not hacked, and, coming to the same conclusion about a dissertation, I decided to try to transfer software notions to writing. Since a paragraph is a unit of development, like a software procedure, I, following McPhee, chose to design everything down to the paragraph topic sentence level before writing. And it worked!
The one draft dissertation is a 5 step process:
- Believe you can do it.
- Understand that the purpose of a dissertation is to defend your claimed contributions to your field.
- Write for the right audience. Start by sketching a blueprint by writing for yourself then do the formal writing for your committee.
- Acquire draft writing skills (paragraph topic sentences, story telling, and logic to tie paragraphs together to tell your story)
- Design a dissertation.
What does “draft” mean? Here a draft is a completed unit, something that you give to others for review. I do not consider small scale revising, say editing within a paragraph while leaving the structure alone, the same as re-drafting. Do not misunderstand; “one draft” does not mean that you just start from a blank slate with final words of truth and beauty rolling off your fingertips. No, producing a dissertation is work, but it is merely work, not some mystical thing… You should believe that you can produce a one-draft dissertation, because focusing on contributions allows you to first choose vocabulary, craft figures, and grow a story tree down to paragraph topic sentences, and to then, for an audience of other experts, draft, one at a time, what you have the skill to draft, namely, paragraphs.
This approach has been tested on his students. It’s similar to one of my writer’s block antidotes. When I’ve struggled with writing something new, I often dive in and plan my story paragraph by paragraph by writing topic sentences, much like in the One Draft Dissertation. It’s planning, but it feels like another way to jump in and write. Just write topic sentences, damn it.
Finally, here is the average length of a dissertation by field, courtesy of beckmw.wordpress.com.
Part of my job is to help students figure out if grad school is for them. Over the years, I’ve accumulated a few great resources for students thinking about a PhD. Here are some of my favorites.
Here is a link to the first of a series of ten blog posts by Jean Yang, who decided to leave Google to attend grad school in CS at MIT.
Philip Guo released an e-book on the PhD experience called The PhD Grind and has a 45 minute lecture on why to consider a PhD in CS. He has a bunch of other good posts about academic life as both a student and an assistant professor. He has a post specifically on applying to grad school.
Tim Hopper has a great series about whether one should consider a PhD in a technical field. I like this series because a broad range of people participated and not everyone encourages a PhD.
Chris Chamber’s blog post called “Tough Love: an insensitive guide to thriving in your PhD” has a lot of frank advice for determining whether a PhD is for you.
Below is a slideshare presentation I put together for the VCU math club a few years ago, since several seniors were planning to apply to graduate programs.
This is a woefully incomplete list, but I don’t want to delay posting it any longer. What other useful resources are out there?
I am teaching a 1 credit hour PhD development course for industrial and systems engineering students at the University of Wisconsin Madison. I am teaching the course with librarian Ryan Schryver, who is using the course to replace his office hours that students never came to. He found that students were not asking the questions that they needed to ask. Additionally, the department has a goal of exposing students to research and people across the department, but we have found that our students work in their labs with few interactions with students in operations research, manufacturing, human factors, and/or healthcare (our four department areas).
This course will fill these gaps. Our syllabus includes a variety of topics for students in their first 2-3 years, from understanding department and university policies to choosing a dissertation topic, technical writing, graphics, research organization, good programming habits, and prelims. We have a bunch of guest speakers plus me. I love hearing my colleagues’ take on things.
Student feedback thus far has been fantastic. I have urged the students to take ownership, and they seem interested in getting what they need from this course, not just in attending to get credit.
My favorite day thus far has been the PhD student panel, where PhD students asked questions to other PhD students. The questions came from all over the place, and the panelists were open to being quite honest about the process and the occasional struggles. Ryan and I knew it was successful when we had those unfiltered moments. Here are a few tweets from the panel.
Our guest speaker from the writing center, had some really good advice about the writing process:
Ryan talked about copyright and fair use, and he filled his talk with many pieces of useful information:
I’ll have a recap slide on this course at the end of the semester. In the mean time, please share advice and observations from similar courses you have taken so I can revise and improve the experience.
I recently blogged about a semi-plenary talk I gave at the German OR Society Conference. This post is about the process of preparing for that presentation.
First I thought about the story I wanted to tell. I’ve given a lot of research talks before. I understand the general plot of a research talk, but a semi-plenary was not a regular research talk. I wasn’t initially sure how to tell a story in a new way. I asked a wise colleague for advice, which was excellent:
- Think about your favorite plenary talks. Model your talk after that (including the amount of math to include in the talk).
- Think of the talk as a series of 30 second elevator talks. Let those messages structure your story.
- Your audience will want to feel that they’ve learned something. What are the takeaways?
I found that creating an initial set of slides wasn’t so bad once I decided in the story I wanted to tell. I have given so many talks before that I had a huge set of slides that I could pull from. I had too many slides and could not fit into the time slot, and editing and pruning my slides was pure torture.
A few months ago, I read a post by an academic blogger who had recently given a plenary talk. I can’t find the post now but I remember that it took about 40 hours to create a one hour talk. This reminded me of an earlier post on teaching MOOCs (How college is like choosing between going to the movies and Netflix), where an enormous amount of time goes into a single lecture.
Here is why it took so long. I noticed that every time I removed a slide or combined a few slides into a single slide, it affected the story narrative in a major way. In a regular research talk, I find it easy to pick a few details to leave out. Not the case this time. Rather than condense the story, I eventually left some topics out all together or turned the insights from a paper into a couple of bullet points on a slide. Finding the right balance of detail and insight was a constant challenge.
I ended up having almost no math in my talk. I decided that insights were more important that going through technical details.
I recreated almost all of the visuals from my slides in previous talk. It’s not that my visuals were total crap, it’s just that there was just too much detail and notation in previous figures I made for research talks. I didn’t want confusing visuals getting in the way of the story. Sometimes I added a picture to illustrate an idea or insight that was technical in nature rather than launching into a long narrative to explain a simple point. Here is an example of a new visual explaining the concept of ambulance response times and coverage:
Other times i just needed to make a simpler version of a figure or table that allowed me to look at a single curve or to compare two things, instead of a busier figure that works in a regular research talk. At one point, I changed a figure with four subfigures into a single figure by omitting the other three subfigures. I make nearly all of my figures with Matlab and save my code so that I can easily recreate figures for presentations or paper revisions. Remaking figures wasn’t too taxing, but remaking a lot of figures took some time.
Finally, I learned so much about my research when giving this talk. The end my my talk answered two questions:
- Where is emergency medical service research in OR going?
- Where does emergency medical service research in OR need to go?
I think about high level issues all the time (after all, I frequently write proposals!). But this was different: I was talking about places where this entire line of research is going, not just mine. When I was answering the question “Where does emergency medical service research in OR need to go?” when making my slides, I learned that my research had already made progress in the right direction. Not all of my ideas are in line with the where this line of research needs to go, and it was worthwhile to realign my priorities.
- Do you have a 30 second elevator talk about your research?
- The most important 30 seconds of your dissertation defense
I’m on a lot of dissertation committees. While most of the committees are for students in my department, many are not in my area of operations research. I’m surprised at how hard it can be to follow along to the bigger picture and/or to the technical details. Even when I completely understand the technical details, I usually do not know enough about the specific research niche to characterize the dissertation’s contribution or novelty.
I tell students that the most important part of their thesis or dissertation defenses are the 30 seconds when they summarize the key contributions of their research at the beginning of the dissertation. I’ve been to defenses and proposal defenses where this has been unclear, and confusion follows. A lot of confusion.
The 30 second elevator speech is an important skill, because academics (and non-academics too) spend a lot of time trying to sell their ideas (literally!) to people with technical expertise in another field. The 30 second elevator speech is a necessary but not sufficient first step to communicating with others, and a thesis or dissertation is a great place to get started with this.
Additionally, all committee members want to understand what a student’s research is trying to accomplish and how it will fit into the literature. We need help to get there. Not all committee members seek to understand all the technical ideas, especially if they are outside your area, but we all want the Big Picture. Admittedly, guiding your committee through the Big Picture this will take more than 30 seconds, but doing so will lead to fewer questions later on.