On the seventeenth day of class, we broke into groups and I went around to each group answering questions (as did the group tutor, so we covered 2 out 3 groups at once). I don’t remember now exactly what the concerns were of each of the groups—some were trying to figure out how to get their materials on short notice (I’ll have to remind people early next year that getting materials requires lead time). I did explain a number of technical things to the groups.
On the eighteenth day, I started by returning the draft design reports and telling them something about how engineering documents are usually structured, with ideas like section headers, paragraphs, topic sentences for paragraphs, and the 4Cs of technical writing. I was going to provide a link to a 4Cs post that I wrote a few years ago, but when I looked for it, I found it was still in draft form, not finished, so I’ll include it here:
I see a lot of bad writing. I present to my students the “4Cs” of technical writing:
The 4 Cs are arranged as a cross, because clarity and correctness are often in opposition to each other, as are conciseness and completeness. Good technical writing requires finding the right balance of these opposing ideals for the audience and purpose of any particular document.
The point I made today was that for design reports, “complete” and “correct” trump the others, though having all four is best.
I also explained to them that writing to the professor (as some had been doing) is a very difficult form of writing, because you are not trying to communicate the content, but some other “meta” information (like that you understand the content). I suggested that instead they should write to people like they were a few weeks ago: bright freshmen interested in engineering, and that their intent should be to provide all the information such students would need to continue the project. I also talked about the need to include the dead-ends and how they worked around problems—as a professor, I’m not as interested in the final product as in their engineering thinking—how they tested and debugged their design.
Somewhere along the way I got into talking about doing search and what to do when you don’t know the right keyword. For example, the centrifuge group had asked me by email to connect their Dremel tool to their rotor. I sent them back the suggestion to use a rotary tool mandrel. What I hadn’t told them is how I chose that—I didn’t know that the part they needed was called a mandrel. So I explained, to the whole class, how I discovered that name by using Amazon and looking up Dremel tool, and finding that they had a “rotary tools accessories” category then looking through there until I found the term “mandrel”. My actual path was not quite how I described in class, and was probably a bit more efficient. I actually started from “rotary tool cutoff”, because I was trying to remember how cutoff wheels were attached. On the first page there were several cutoff wheels and saws with mandrels, and even a mandrel by itself. Redoing the search with “rotary tool mandrel” got me confirmation that I’d found the correct keyword.
After rambling about tech writing for a while, I let them break into groups and went to each group talking about what technical questions they had for their projects. For one group, I talked about hose clamps and angle brackets. For another group, I talked about H-bridges, and suggested they look into them as a possible alternative to using a relay (if they wanted to do PWM). I was thinking of parts like the Infineon 5206, which I used in the HexMotor board, but I did not remember a part number to give them. Another group was wondering where to get parts around Santa Cruz. I suggested that they try Santa Cruz Electronics, Computer Zone, or go over the hill to Frys. Ace Hardware also came up.
They’ve got one more draft due on the last day of class (next Monday), for which I’ve promised feedback by Wednesday, with the final report due Thursday.