Learning (and teaching) about technical writing

Over at Adventures and Ethics and Science, there's been a discussion going on (over several excellent posts, and another one here) about how scientists learned to write as scientists, and subsequently how we teach our students to "write science". Definitely worth a read, and very thoughtful.

The posts got me thinking about how I learned to write as a computer scientist, for other computer scientists (i.e., in an academic sense). It also got me thinking about how I approach teaching these skills, particularly to my undergraduate research students, and how this has evolved over time. So I thought I'd share some of my own thoughts on the subject, inspired by those posts.

Like most scientists, my first exposure to scientific/technical writing was the ubiquitous lab report. In fact, this was my only real "formal" exposure to technical writing; I don't even think there were any courses available when I was in college. The lab report introduced me to the general format of technical papers: objective, procedure, results, analysis, conclusion. But it lacked the key component of any writing: revision. And so like most people, my goal in writing any lab report was to get it done as quickly as possible, style be damned.

My first real experience with technical writing came my senior year of undergrad. My research advisor asked me to write up what I had done so far. Not having read many academic papers at that point, I used the only format with which I was familiar: the lab report. I can still remember the day I got back my first draft. My advisor had crossed out the entire first two pages of my writing, and there were liberal red marks throughout the rest of the paper. That was my first clue that academic technical writing was much different from what I was used to. That was also my first clue to what would become my greatest struggle in becoming a technical writer: boiling down my work into something that could be clearly and succinctly stated in an introduction/motivation section.

Like most other scientists and techies, my writing "education" in grad school consisted solely of reading academic writing (and trying to mimic that voice) and feedback from my advisor. I found that I was fairly adept at writing up the results and analysis of my work, but still struggled with the whole motivation section. I found it hard to articulate why my work was compelling/important/a new contribution to the field. I had a lot of experiences like that first experience with my undergraduate advisor: first drafts coming back with the entire "Introduction" section crossed out. It was humbling, and slow learning for me. But over time, by listening carefully to my advisor's feedback and paying attention to how he wrote about his own work, I improved in this area substantially. (Although I still do struggle with that part of my writing more than any other.)

I think the experience that taught me the most was preparing (and then substantially revising after the first round of reviews) my first journal paper. Trying to figure out how to respond to reviewer comments, especially, forced me to really think about how I present my work and contributions. And the extensive rounds of revisions taught me that writing anything good and technically sound requires lots of work, lots of reading and re-reading, and lots of ripping things out and starting over.

Now, as a professor who works quite a bit with undergrad researchers, I feel like it's my responsibility to expose them to technical writing, both as consumers and producers. I do this because I know that they aren't getting this exposure elsewhere, and I think it's important that technical people know how to communicate technical things, to both technical and non-technical audiences. I also do this because I think writing about the research they're doing helps the students to understand it and synthesize it on a deeper level. The more I do research with students, the more strongly I feel about this. But teaching them how to write technically, as others have pointed out, is hard, particularly when doing so may come at the expense of, say, having them run another set of experiments or analyses.

I used to have a laissez-faire attitude about writing ("just summarize your results and experiments in a page or two"), but quickly found that, except for a few truly exceptional students, what I got back was crap. (and usually entailed me re-doing whatever the students had done, because I couldn't figure it out for the life of me.) Now, I try to set aside time for the students to write at least two drafts on their work for me.

I also give them a strict format to follow when writing for me. The format is basically the structure of a common paper in my field---abstract, intro/motivation, related work, algorithm, etc. But I also give them guidelines as to what sort of material to include in each section, what voice to use, etc. I tell them to spend more time on the sections most closely related to their work---the algorithm, experimental setup, results/analysis---but I don't give them a complete pass on the other sections. For instance, I'll tell them that for the related work section, they should summarize the papers that I've had them read at the start of the project. This saves them some work, but still exposes them to the process of synthesizing, incorporating, and critiquing prior work in the field.

I've found that by being more specific with students about my expectations for their writing, and by emphasizing multiple revisions, I get a much more thoughtful, thorough, and polished product. I also have found that students take the writing-up portion of their work much more seriously. (I think I also emphasize this by talking about what I'm currently writing up, during research meetings and such. I try to model "write as you work" for them, both to show them that this is a good strategy to use and that writing is just as valuable to research as the actual construction of algorithms and carrying out of experiments.)

So that's how I've evolved as a technical writer, and how I try to help my students evolve as technical writers. No doubt, my approaches to both my own writing and my students' writing will continue to evolve, but this is a snapshot of where I am at this point in my career.