communicating engineers

Last weekend was the L.C. Smith College of Engineering and Computer Science open house. My WRT 407 students presented and demonstrated their year-long projects to visitors, guests, and an IEEE review team. Once again I came away from the event amazed by the creativity, talent, and genius of these pre-professional engineers. It is both a humbling and energizing event.

I spend much of the afternoon reviewing the project teams' documentation suites. While the format is not required, they typically take the shape of tabbed three-ringed binders. The suite consists of the following documents, which the teams have developed and revised over the course of the two semesters:

• Formal Project Proposal
• Individual Technical Descriptions
• Technical or Demo Presentation
• System Requirement Specification
• Test Plan/Test Scripts
• User or Implementation Guide
• Status Report
• Draft Research Paper/Article 

When I look at the range and quality (yes, quality) of the documents, I inevitably wind up questioning the outcomes of the course. I focus my instruction on genre and the communicative and rhetorical requirements of different types of documents in different contexts. Filtered down, that really mean that I'm teaching production. I don't really see that as a bad thing, but I do wonder how the production of technical engineering texts s in alignment with the course outcomes.

I have some improvements to make, particularly in regard to managing 40+ students in a class that meeting only once per week. Aligning activities and products to goals and outcomes will drive those improvements.