Dirk Riehle's Industry and Research Publications

Ten years of university teaching

My research and teaching group just celebrated its tenth anniversary, and I wanted to take some time to reflect on our teaching: What worked and what didn’t.

Principles

When I started as a university professor ten years ago, I drew on my experience as a student, as a teacher, as a practitioner, and as an entrepreneur, to define the basic principles of how I wanted to teach:

  1. Theory and practice should be joined at the hip; there should only be minimal delay, if any, between hearing some concept and applying it in practice
  2. Learning requires repetition and practice, so the theory and practice of something to learn needs to be drawn out over several iterations to become effective
  3. Learning is a marathon, not a sprint; therefore, learning and using the stick (grading) to direct learning should be continuous and not a fire-and-forget exercise
  4. Feedback needs to be immediate and connected to a student’s actual doing, and not come at the end of a semester or later
  5. Learning is holistic; while some concepts can be isolated, more often than not, concepts interact and require a realistic setting to be learned

I teach at a traditional university, where common constraints apply: It is easiest to teach during lecture time of a semester (about three months), with a weekly work rhythm for a course. With multiple courses to teach each semester, I have to cram them into the same three months like everyone else. Otherwise, the non-lecture time of the semester won’t be available for research and travel.

Practices

With this in mind, I decided to implement the principles above using the following practices, which I applied across all my courses. Please note that this applies only to elective courses, where I’m free to teach as I see fit.

  1. Projects are much better than a string of isolated homework exercises, so initially we had no homework but only semester-long projects (principles 1, 5)
  2. Even with a project, we require continuous delivery, at least every two weeks, of work and don’t wait for a single final deliverable (principles 2, 3, 4)
  3. We use a multi-week pattern of first reading up on a concept, than learning about it in class, than applying it, and then giving others feedback on their application of the concept (principles 2, 3, 4)
  4. We take measurements every week for grading, keeping students motivated and focused; as a consequence, we don’t have final oral or written exams (principles 3, 4)
  5. To be fair in grading, we triangulate: We take different measurements each week, for example, quiz results, class participation, and written homework (principle 4)

Adjustments

My approach quickly hit reality and needed adjustment, some of it good, some of it not. This included:

  • Some students simply lack the skills to effectively work in a project team; thus we complemented the project work with a basic individual homework track
  • Student numbers in our electives quickly escalated, and so we decided to use peer feedback to provide both immediate and targeted feedback on student work
  • Student representatives insist that there must not be a requirement that students show up to class; they must be able to pass the course without this, so we recorded all lectures as videos

This had some consequences:

  • For peer feedback, we used Luca de Alfaro’s Crowdgrader. Students upload their work and randomly selected other students provide feedback for the work. We grade both the original work and the feedback given. Despite our assurances that student feedback would not inform our grading, students kept complaining about peer feedback. As a consequence, we eventually dropped it and are now providing much more generic feedback than students would give each other.
  • With videos readily available, student participation in class fell starkly, and learning (and grades) dropped strongly as well. As far as I can tell, students believe they can learn from a video, but my experience is that most do not: I suspect a significant number doesn’t even watch the video, and they are certainly missing out on the in-class interaction and discussions.

I regret giving students the option to avoid project work, but it also restored some sanity with my teaching assistants and me. Having students cry in your office about the other students is not a pleasant experience.

I truly regret having to let go of peer feedback, as it was a strong enabler of principles 2, 3, and 4. I find it hard to stay true to these principles just by the power of my teaching assistants and myself: The workload is just too high.

Evaluation

Near the end of a semester’s lecture-time, the university asks students to evaluate a course. This is also the main anonymous form of gathering feedback to improve a course. However, the university does not ask the students directly but rather gives the lecturer access codes, on paper, to hand out to students to participate in the evaluation. As a consequence, a lecturer can direct who of the students who started a course gets to have a say in its evaluation, and it will mostly likely only be those who are still around at the end and who are still coming to class. This way, a lecturer can influence their course’s evaluation.

For the longest time, I thought this was silly, because we would not get honest comprehensive feedback. So each semester, I provided the email addresses of all students who had signed up for the course, to the evaluation program, and added questions like “why did you drop out?” We got slain a couple of times with bad evaluations, presumably by students who had decided to drop out because we were not giving them the grades they expected. After the university’s evaluation coordinator told me that such evaluations might be a problem for my group and me, I grudgingly let go of using the evaluations for feedback: I’ll use our own survey tool to gather feedback if we want it.

So the learning is to avoid conflating student evaluations with feedback.

Projects

I think the biggest win for our teaching are projects. This may be more pronounced than elsewhere, because I mostly teach electives in an engineering discipline. It also adds extra work: Every semester, I have to find new projects, and I usually acquire those from industry. Making industry projects fit to learning objectives requires effort. In addition, I have to be a coach of my teaching assistants, who are coaches to student teams, while at the same time grading them. 

Projects work for almost all my courses: 

  • In our flagship agile methods course, students form a project team to develop some open source software for an industry partner, 
  • in our software architecture course, a project team documents the architecture of a software, analyses it for a purpose, and makes suggestions for improvement,
  • in our advanced programming course, students work individually, but still work on and extend an existing realistic piece of software,
  • in our product management course, a project team develops a business plan and specification for a software product, and
  • in our performing research course, a project team performs a qualitative or quantitative data analysis.

Regular project deliverables and our feedback close the learning loop. Learning is more holistic than if split into disjoint homework exercises. The many data points we gather make grades more fair and keep students on a continuous learning path rather than making them cram for a fire-and-forget exam. 

I believe that student projects are a true enabler for good teaching. If you would like to learn more, you may find my teaching project concept interesting, laid out here in English and here in German (the original). 

Subscribe!

Comments

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  1. Dirk Riehle Avatar

    Thanks, Michael!

  2. Michael Richmond Avatar
    Michael Richmond

    Thank you for posting this and being transparent about what worked and what didn’t work. This level of rigor is inspiring.

Navigation

Share the content

Share on LinkedIn

Share by email

Share on X (Twitter)

Share on WhatsApp

Featured startups

QDAcity makes collaborative qualitative data analysis fun and easy.

Featured projects

Open data, easy and social
Engineering intelligence unleashed
Open source in products, easy and safe