Skip to main content

Learning to write

The Chronicle of Higher Education has a great article on the importance of writing skills for graduate students. (Thanks to Jitu Padhye for the pointer.) Though nothing in the article surprises me, the article highlights a widespread concern about the lack of formal writing training for grad students. Learning to write effectively is one of the most important skills you need as a grad student, and, of course, as a researcher or faculty member later in life. But we don't actually teach this skill. Most faculty (myself included) seem to expect students know how to write, or will somehow pick it up in the course of their research -- and, presumably, having enough conference papers rejected. Even worse, most students don't realize how bad their writing is. This becomes a real problem if you're a new faculty member trying to get funding, and people can't follow your papers or are unconvinced by your grant proposals. Good writing is everything.

I'm not sure how to solve this problem. Putting my grad students through dry technical writing classes doesn't seem to be the answer. Good scientific writing involves a great deal of subtlety. It is not just about being grammatically correct, but conveying ideas in a convincing manner. This is especially true in computer science, where the goal of most conference papers is to persuade -- to seduce the reader with a Big New Idea, not just to report on the results of a study or new finding. Many courses on scientific writing fail to meet the needs of CS, focusing instead on the dry presentation of methods and data. That is important in CS, of course, but if you compare the structure of your typical Nature or Science article to, say, an SOSP paper, the differences are stark. (On the flip side, I often find CS papers tend to fluff up a fairly simple idea with a lot of marketing to make the ideas seem more earth-shattering than they really are. Seriously, how is a minor tweak to the 802.11 MAC protocol going to change the way we think about the nature of human communication?)

Any suggestions on better ways to teach our grad students how to become great writers?


  1. How are Nature or Science papers better or worse than SOSP papers?

  2. Not better or worse - just different. Science/Nature articles tend to be extremely terse and quite dense technically. They tend to be "just the facts" and have little in the way of background and almost no editorializing. CS conference papers do a lot of "sell" and tend to put the work in a broader context.

  3. I definitely notice the differences in prose between the physical sciences and CS. I prefer the less dense prose in CS, but the "fluffing up"/marketing is very off-putting to me. Framing work in a broader context is fine, but I don't appreciate feeling like I'm being hustled by a smarmy salesman. Similarly, I feel really sleazy doing it in my papers -- even if I think my work is good, I hate to oversell. Usually the creators of something are acutely aware of the greater context as well as the deficiencies and limitations, so gussying it up with thick marketing just feels dishonest. It's an insult to the readers' intelligence.

  4. Great link! I struggle with writing too! I am very good at preparing and giving conference talks and posters, and at writing 2-page conference-length abstracts. However, I still struggle with writing longer papers.

    My step-father is even an expert on writing! His advice has helped me make some progress on my writing. Check out his book for good advice about the process of writing (and also advice for new faculty members):

    Learning to write is certainly a life-long process, but I completely agree that graduate students need more concrete support and advice. One of the problems is that graduate advisors might not be good writers themselves. It might be possible to get graduate writing support from university writing centers or in conjunction with technical writing programs.

  5. You might want to check what Mary Shaw at Carnegie Mellon does with her course on "WordWright: The Right Rite of Writing" (aka "How to Write a Research Paper"). The URL is .

  6. Good pointers. Will check them out.

    With regards to David's comment about "gussying up" a paper, much of this has to do with convincing a reviewer that the ideas in the paper are deep and and have broad implications. Conference submissions rarely stand on technical content alone - a paper on an otherwise mundane topic can be a great read (and much more likely to be accepted) if it's given the right spin.

    Of course, it's possible to overdo it. My litmus test is whether the paper actually backs up all the fantastic claims made in the intro. Sometimes by the end of reading 14 pages you forget that on the first page they promised the system would have some property (say, long lifetime or robustness to failure) but it's not actually demonstrated in the paper. Always watch for false advertising.

  7. Carolyn - I didn't realize you were related to Robert Boice! I read that book when I started at Harvard, though I have to say the writing in that book is, itself, extremely hard to follow. The first two rules he lays out are "1. Wait" and "2. Begin Early". This kind of thing makes my brain hurt :-)

  8. Try using a little taoism or buddhism when reading Bob's book. :) He uses elements of both in his advice: Moderation and slow, steady work. It's hard to rectify "wait" and "begin early" without some philosophical basis! :)

    I think a lot of us are "Just Do It" kind of people, but a little reflection beforehand ("active waiting") might help clarify and define the primary theme and context for a paper, and thus the progression of arguments necessary to make the case.

    I have the fatal problem that I am a great procrastinator which results in binge-writing that produces lower quality results than a moderated, 10-minute/day, long-term writing project. I also have the tendency to skip useful steps, like writing outlines, because I think it will save me time later. I know, this is a very basic error, but it's a BAD habit of mine! One of these days, I'll learn.

    I also think that many people don't realize that writing can be a good research tool. If you start writing your papers early, it can help define and refine the experiments or directions you take with your research.

  9. Thanks for posting this. (I found out about it from my old friend Owen Astrachan.) Am planning a follow-up column with more advice and less carping.

  10. I have few comments on how science grad schools should be structured to teach writing, but on an individual level you could give your students Write Right!, which is the most useful short primer on writing that I've ever read, and William Zissner's On Writing Well. If a student approaches both honestly, they should yield quite a bit even without a class.

    The writing problem is hardly limited to just the sciences too; I actually wrote an entire post called One of the Open Secrets of Grant Writing and Grant Writers: Reading. You might imagine that people whose jobs revolve around writing would be trying to learn to write, but often that doesn't seem to be the case.

  11. Science paper for me is hard to write. There are many things to consider in writing it.

  12. This article is very informative. Thanks!

  13. Amazing info, I like the site!


Post a Comment

Popular posts from this blog

Why I'm leaving Harvard

The word is out that I have decided to resign my tenured faculty job at Harvard to remain at Google. Obviously this will be a big change in my career, and one that I have spent a tremendous amount of time mulling over the last few months.

Rather than let rumors spread about the reasons for my move, I think I should be pretty direct in explaining my thinking here.

I should say first of all that I'm not leaving because of any problems with Harvard. On the contrary, I love Harvard, and will miss it a lot. The computer science faculty are absolutely top-notch, and the students are the best a professor could ever hope to work with. It is a fantastic environment, very supportive, and full of great people. They were crazy enough to give me tenure, and I feel no small pang of guilt for leaving now. I joined Harvard because it offered the opportunity to make a big impact on a great department at an important school, and I have no regrets about my decision to go there eight years ago. But m…

Rewriting a large production system in Go

My team at Google is wrapping up an effort to rewrite a large production system (almost) entirely in Go. I say "almost" because one component of the system -- a library for transcoding between image formats -- works perfectly well in C++, so we decided to leave it as-is. But the rest of the system is 100% Go, not just wrappers to existing modules in C++ or another language. It's been a fun experience and I thought I'd share some lessons learned.

Why rewrite?

The first question we must answer is why we considered a rewrite in the first place. When we started this project, we adopted an existing C++ based system, which had been developed over the course of a couple of years by two of our sister teams at Google. It's a good system and does its job remarkably well. However, it has been used in several different projects with vastly different goals, leading to a nontrivial accretion of cruft. Over time, it became apparent that for us to continue to innovate rapidly wo…

Running a software team at Google

I'm often asked what my job is like at Google since I left academia. I guess going from tenured professor to software engineer sounds like a big step down. Job titles aside, I'm much happier and more productive in my new role than I was in the 8 years at Harvard, though there are actually a lot of similarities between being a professor and running a software team.

I lead a team at Google's Seattle office which is responsible for a range of projects in the mobile web performance area (for more background on my team's work see my earlier blog post on the topic). One of our projects is the recently-announced data compression proxy support in Chrome Mobile. We also work on the PageSpeed suite of technologies, specifically focusing on mobile web optimization, as well as a bunch of other cool stuff that I can't talk about just yet.

My official job title is just "software engineer," which is the most common (and coveted) role at Google. (I say "coveted&quo…