The students have ten written assignments plus an oral presentation in the 10-week quarter.
We start the quarter with a résumé and job application letter. This assignment allows us to introduce the importance of considering the audience, of selecting which material to present, and of formatting the material for ease of reading. We also talk about the cultural context in which the material is read, since many of the students come from cultures with very different standards about how one presents one's accomplishments. The students find this assignment extremely useful.
Our second assignment is a short in-class assignment, to read another student's job application and résumé and write a short memo recommending that the student be interviewed (or not be interviewed) for the job. This assignment give the students a chance to look at the writing they have just done in the role of the audience, rather than the author, and gives us a chance to see how the students do under time pressure, when they don't have time to get help with their writing.
We then start a sequence of three assignments that are directly tied to the sort of writing the students are most likely to do after they graduate: in-program documentation, description of an algorithm in the form of a consultant's report, and user documentation for beginning computer users. Originally we started with the user documentation (the least technical assignment) and ended with the in-program documentation, but this year we tried reversing the order, since the in-program documentation, although the most technical, is probably also the most familiar format for the students.
The in-program documentation involves adding comments to a backtracking search procedure (usually to solve the knight's tour, but occasionally to solve the eight-queens problem) taken from Niklaus Wirth's book Algorithms + Data Structures = Programs [Wir76]. Wirth's external documentation is given to them to explain the procedure, so that they do not have to decipher Wirth's extremely poor choice of variable and procedure names.
The main goals of this assignment are to get the students to recognize the importance of documenting data structures (rather than just code) and to document the intent and effect of procedures, rather than just translating the code into English.
Although I cannot claim that students automatically transfer what they learn in this course to their programming in other courses, I believe that some gentle reminders that they will be evaluated on the quality of their in-program documentation in upper-division project courses would help a lot in getting the students used to considering the documentation as a normal part of the job.
The algorithm-description assignment asks the students to play the role of a computer consultant who has to recommend a change in algorithm to a client. This exercise is the first one in which they have to write to multiple audiences: the executive who is paying for the report and the entry-level programmers who have to implement the recommended changes. Because the course has only minor programming prerequisites, we use the simplest problem we could think of that offers multiple solutions: sorting a database by zip code. The students are free to choose any reasonable sorting algorithm, but most choose heapsort or quicksort, both of which are fairly difficult to describe to an entry-level programmer. The students often come away from this assignment with a greater appreciation for the writing in their textbooks, having discovered how difficult it is to explain data structure invariants (the heap property) or recursion.
The naive-user documentation assignment is to write a manual explaining e-mail (the Berkeley Unix mail program) to an audience of executives and clerical workers. The emphasis in this assignment is on organizing a document by task, rather than be program feature, and on selecting the appropriate subset of the features to describe. The students are often embarrassed to discover that they do not know how to do many of the tasks routinely expected of clerical workers (like maintaining a mailing list, forwarded incorrectly addressed mail, and mailing previously entered memos). This is perhaps the most difficult assignment of the quarter, since it involves writing for an audience very different from the students themselves.
The library puzzle and the survey article are an attempt to get students to use the bibliographic resources of the University to find things on their own, rather than relying on textbooks and professors for all their information. One of the big weaknesses of an accredited engineering curriculum is that it relies heavily on spoon-feeding the students information, and does not require much independent research. Most of the students have little idea how to find journal articles or conference papers in the library before taking this course. Luckily, UC has the INSPEC database (which includes Computer and Control Abstracts) available free to the students, so they get exposed to modern bibliographic search, rather than archaic printed indices.
In earlier years, we put the survey article much earlier in the course, and used it as a writing sample to determine which students would need extra help from writing tutors. Students resented the assignment, finding it too much like high-school papers. Pairing the assignment with the library puzzle and emphasizing the library research techniques has made the assignment much more palatable to the students.
The last several weeks of the quarter are all connected to the students final report. They have to write a proposal memo for the project they plan to do, write document specifications for the project, submit a a progress report, present the material orally, and write the final paper itself.
We do not choose the topic for the students-they have to select one and get us to approve their proposal. Generally about 80%of the proposals are accepted immediately, with most of the remainder being required to narrow their focus substantially. The papers are usually either library research (often an expansion of the survey article) or design documents for projects students have done in other classes or at work. A few of the students choose to write user's manuals, though this is much less popular.
We encourage group writing projects for the final project, and teach the use of the document specification (an outline plus an audience analysis) as a management tool for scheduling the writing and dividing the workload.
The progress report is used to give the students an earlier deadline to keep them working on the final project, to give us feedback on how the students are doing, and to give us a chance to discuss honesty and engineering ethics. We talk about the need for honesty and clarity in progress reports, show a videotape of Roger Boijoly talking about the Challenger disaster, and discuss various strategies that engineers can use to keep their integrity despite the pressures that may be put one them by employers.
The oral reports are short (usually about seven minutes per student), but are generally as good as or better than the presentations one sees at professional conferences. We teach the students to select material and vocabulary based on what their audience knows and needs to know, project their voices, look at the audience, not stand in front of their transparencies, use large enough fonts, not clutter their visual aids, rehearse their talks with a timer, and generally avoid the mistakes that plague engineering presentations.
The final reports themselves are often quite long (though we encourage conciseness, the students often have a lot of material they want to include), and grading them in time for the University grading deadlines is often quite challenging.