- Walter Holland
- Email me through OpenWetWare
I am a writing tutor/consultant/resource in MIT's Biological Engineering Department. I'm available to all BE majors throughout the semester, and can offer services ranging from line-editing, complete with actual red pen, to broader conceptual/structural consultation -- e.g. talking through how to approach writing an abstract, how to frame a lab report's Results section, how to write useful headings and captions, etc.
- 2003, MS (Comparative Media Studies), MIT
- 2001, BS (joint: CMS + Computer Science), MIT
Tips and reminders re: your intermediate draft assignment.
Here's the drafting/revision talk I gave during the first week.
Here's a side-by-side reading of the Szostak and Tuerk SELEX papers Jacquin talked about in his 14-16 February lectures. It's pretty elementary as 'literary' analysis, but hopefully it demonstrates a specific, useful way of reading papers in a science-professional context -- and shows how you can reverse-engineer writing principles and practices from multiple readings.
And here's Szostak's coauthor Andy Ellington on aptamers. Excellent read -- very useful historical/commercial context for the work you're doing right now! -- and the first couple of paragraphs bear directly on the above-linked paper.
A simple sample technique
Next time you outline a paper, don't just outline the pieces of information it's supposed to contain -- the 'content.' Instead, build your outline from two elements: information payload (the info 'objects' you're delivering) and transitions between ideas. This could take the form of literally writing a transition sentence linking every pair of facts. This helps integrate the logic of presentation -- narrative comprehension -- right into your understanding of the scientific material.
This also serves as a useful self-check: if you can't link two ideas in your outline (don't cheat), then either you don't fully grasp those ideas, or they really don't belong together. It's possible that the transition you're trying to write is actually a whole different content area in itself. Hey, look at that: you're into the 'writing process' but you're still learning the material. Of course that's always how it works. Writing is a mode of learning too.
My job is to help students develop sound, reusable writing processes. To that end I'd like to encourage our students to consult with me early and often on writing projects.
For instance, I'm happy to work through five or six drafts of the same piece of writing with any student, whether it's a single paragraph or a 10-page paper, with the dual aim of (1) improving that particular piece of work, and more importantly (2) helping the student get a firmer grasp on the practical work of writing. I'm confident that BE students will benefit enormously, in their development as technical writers, from tighter feedback loops and an informal collaborative atmosphere.
One of my big emphases this term will be skill portability -- leveraging students' existing communication skills in order to demystify technical writing. (This should have the nice side effect of helping the teaching staff separate communication errors from conceptual errors!). There are plenty of ways to go about this: peer teaching, informal communications, sustained back-and-forth dialogue throughout the life of each project, etc.
I'll also emphasize repeatable, generalizable writing processes rather than any specific format (e.g. lab reports), though obviously I'll focus on subject-specific student concerns too! I take my cues in this regard from the intro CS class, 6.001 (one of the best I ever took as an MIT undergrad). In that class we learned to program in a syntax-lite language and never spent any(!!) time on language-specific issues. This allowed the instructors to focus on the class's real material: characterizing and solving problems using computational tools. (As they said on the first day of class: 'Computer Science is not a science, and it's not about computers.')
The specific formats and styles students learn right now are less important, I think, than developing skill at responding to written formal requirements in general.. In other words: when you really understand a concept, you're able to express or explore it in many different ways. We'll try to work toward that kind of robust understanding -- of technical writing and subject-specific content -- this semester.
Also!!!! I've got a bike and don't mind meeting off-campus or at odd hours. Perhaps MIT students will find this handy?
- Nontraditional pedagogy (learning in and especially out of the classroom)
- Writing as sustainable discipline (i.e. it's not magic, it's work)
- Cultivating joy as a technical skill ('I hate this f#$%ing place' is actually bad for you)
- Cognitivism and culture (how do cultures form brains, and vice versa?)
- Why Super Mario Bros. is a superb teaching tool (ask me!)
(fixing this later)