First thoughts on teaching

I submitted my first set of grades for a class I'm teaching at Pitt. Part of my foray into academics. Which means I write my standard Lessons Observed (titled following the British tradition). I'm sure that those who have much more experience then I in teaching can have much to say.

Background:
I am teaching Database Design within the Department of Industrial Engineering at the University of Pittsburgh (Pitt). It is a service class, not part of the core curriculum of IE. But it is something that is very useful for engineers to know because of the large amounts of interaction with data. I have some background, because I use databases regularly, including some rather advanced uses for one of my research projects. The class is split between upperclassmen and graduate students, with most of the graduate students being professionals going for a master's degree. For most of them, this will be their only database course. There are two other places in a university where such a course would be offered. An information science (or possibly computer science) department would likely have a concentration in this field that examines data storage and retrieval. Business schools would sometimes have information management as a field, but more likely will have a course that teaches use of MS Access.

Goal:
The course objectives where to teach database design, with the understanding that the audience are engineers, i.e. people who would design applications that use a database, not database administrators or builders of database management systems. Similarly, I decided to make it a design class, not a course in driving a software package (MS Access), although using MS Access (or other database) would be assumed. I think that defining where the course fit in with other similar courses what the right idea, because it let me do the is-is not analysis when deciding what to include. I've done that with a course proposal I've submitted for fall, as well as the course I'm teaching in summer.

Software:
I did not specify software for the course. For the database, everyone ended up using one version of MS Access or another (three different versions were in use). While it probably would have been possible to do table design and queries in any database, teaching reports and user interfaces would have been too much of a stretch unless you use this. There were some problems because I don't use MS Access myself (I generally use PostGIS and BIRT for database and reporting) so I was probably light on the examples. For the next time, it would probably be safe to state use of MS Access. For diagramming, I gave them the choice of Visio or Dia. MS Visio was installed on the university computer labs (but not the department lab) and Dia could be freely downloaded. People ran into trouble navigating Visio (it was designed for programmers, not database designers) and most switched to Dia (databases is a base use case for Dia). While this is not software course, I probably should make a standard.

Projects:
For the project, not enough people had access to a real world project, so I had them create projects, and I had teams assigned to review each other (to include adding goals to the project). This was a heavier administrative burden then I realized it would be, and I was not able to keep track of all the communications. I should have had fewer mandated interactions, and let them do informal interaction. I was not sure about the quality of the peer-review, but most of the project reports specifically mentioned that having peer-review of the project at various stages gave the projects more clarity then they would have had otherwise.

Lectures:
This was a somewhat different subject then most in an engineering curriculum, since it is very soft. And not a subject I know deeply. I was walking the line between too much information to absorb on a weekly basis, but there was not enough content on a class session basis. Probably what it meant was I should have been doing more examples, especially working the software. Another thing I should do is organizational prep work. In particular, for the next course I will be preparing a lesson plan in addition to a lecture, to give each lecture more context.

One thing that did work was spend some time on motivating the day's topic at the beginning of every class. I suspect some of them thought I was only rambling, but others were able to make it work for them in putting things together.

Value at Risk Case Study:
I have in the back of my mind a capstone lectures that declares that mathematical models are a form of communication, and I expect every class I teach will have a way to talk about this. In this case there is a module on reporting, meaning how you present summary information from the database. And I used the Value at Risk statistic that factored into some of the riskier instruments used by various financial institutions. There was a clear division in how well this was understood. By the final, all the grad students made the connection between that and the related question on the final. Only a few of the undergrads did. Probably because the grad students were intimately familiar with the problems that financial institutions were having and it held their attention better.

Research and teaching:
I am now a firm believer that research helps teaching. One of the things that made this course interesting was the fact that I had actual database projects I worked with. While the actual projects could not be done in the course, I could extract parts. And I could use actual datasets and data collection tools as examples in the course. A couple of the students complained about the vagueness of the data specifications, which would be echoed by the people who actually deal with the data in question, so that was actually good.

Use of examples:
I had three datasets that I used for examples throughout. The US Department of Agriculture Standard Nutrient dataset (used in the preparation of nutrient labels on food), Pennsylvania Emergency Management Agency damage assessment collection forms, and the MS Northwind Traders example database. In particular, I used the USDA data from the very beginning of the course. It provided a rich set of understandable data so that it was clear what happened. I will probably do that again, using Pennsylvania as a dataset in my location class this summer.