Gas station without pumps

2016 June 11

Teaching writing lab reports

Filed under: Circuits course — gasstationwithoutpumps @ 09:24
Tags: , , ,

Greg Jacobs, in his post Jacobs Physics: Report from the AP reading: Teach your class to write concise laboratory procedures. Please., asks high-school physics teachers to teach students how to write concisely:

Part (a) of our question asks for a description of a laboratory procedure. It could be answered in 20 words: “Use a meterstick to measure the height of a dropped ball before and after it bounces. Repeat for multiple heights.

“But oh, no … when America’s physics students are asked to describe a procedure, they go all Better Homes and Gardens Cookery Manual on us. Folks, it’s not necessary to tell me to gather the materials, nor to remind me to first obtain a ball and a wall to throw it against. Nor do you have to tell me that I’m going to record all data in a lab notebook, nor that I’m going to do anything carefully or exactly. Just get to the point—what should I measure, and how should I measure it.

Please don’t underestimate the emotional impact on the exam reader of being confronted with a wall of text. We have to grade over a hundred thousand exams. When we turn the page and see dense writing through which we have to wade to find the important bits that earn points, we figuratively—sometimes literally, especially near 5:00 PM—hit ourselves in the forehead. Now, we’re professionals, and I know that we all take pride in grading each exam appropriately to the rubric. Nevertheless, don’t you think it’s worth making things easy for us, when we be nearing brain fatigue? Just as good businesspeople make it easy for customers to give them money, a good physics student makes it easy for the grader to award points. 

Don’t think I’m making fun of or whining about students here. Writing a wall of text where a couple of sentences would suffice is a learned behavior. The students taking the AP exam are merely writing the same kinds of procedures that they’ve been writing in their own physics classes. It is thus our collective responsibility as physics teachers to teach conciseness.

As I’ve been spending far too much time this week grading an 11-cm-thick stack of design reports from my applied electronics course, I have considerable sympathy with Greg Jacobs’s view.

Technical writing is all about the 4 Cs: clear, correct, concise, and complete. Although there is always some tension between clarity and correctness, and between completeness and being concise, I generally find pretty high correlations between the four properties. Often, the very long reports are muddled, incomprehensible bundles of improperly applied factoids, while the essential information is missing entirely.

Part of the reason I have such a huge stack of papers to grade at the end of the quarter is that I have been giving “redo” grades for any errors in non-redundant representations (like schematic diagrams), putting a very high premium on correctness. For the class-D amplifier lab, 80% of the class had to redo the reports, mostly because they had not gotten the orientation of the FET transistors right in the schematics (a serious error that could lead to fires in the amplifier). I must have done a worse job at explaining the FET symbols—several times—than I thought, or maybe it is one of those things that people don’t learn unless they make a mistake and have it pointed out to them, repeatedly. I’ll be trying to fix the book and the lectures next year to reduce this problem.

I’ve also been down-grading students for lack of clarity (especially when the writing seems to indicate a lack of understanding, and not just inability to communicate) and for leaving out essential material (like not providing the schematics for their preamplifier as part of their amplifier lab report, not providing the parameters of the models they fit, or not providing the models they used at all). So clarity and completeness have had a fairly big impact on grades.

But I have not been giving bonus points for being concise, which I probably should start doing, as some students have started using a kitchen-sink approach, throwing in anything that might be tangentially related to the subject. Unfortunately, these are the students most likely to have unclear and incorrect reports, and they leave out the essential material in an attempt to throw in useless background, so their attempts at completeness generally backfire. I need to discourage this behavior, undoubtedly learned in middle school and high school, and get them to focus on the stuff that is unique to their design, rather than telling me Ohm’s Law or the voltage-divider formula over and over.

2014 March 12

Seventeenth and Eighteenth day of freshman design seminar

Filed under: freshman design seminar — gasstationwithoutpumps @ 21:05
Tags: , ,

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.

%d bloggers like this: