From March to June 2018, I have been giving th-e lecture “Software Engineering” at the university of Ostfalia. Doing so, I temporarily replaced Prof. Dr. Bernd Müller, who was busy doing research. It’s common practice to search a fellow scientist or a volunteer from the industry to allow students to visit the course. In this article, I reflect on some aspects of this activity and what I learned from it.

Course facts

The course is mandatory for 3rd semester Bachelor students with fields of study computer science, for example plain IT, IT management and also UX-designers.

Deciding to do this or not

Four years ago, Jens Schauder gave the exact same lecture. However, he didn’t want to repeat his course this year, so I was asked if I wanted to step in. Before making the decision, I had a long talk with Jens about the reasons of him declining the offer. Boiled down, Jens had different expectations in the students, their willingness to learn and also the level of performance. That made me think about my own expectations and priorities.

This course was the biggest series of talks I ever prepared. Never before have I had multiple three-hour talks, each week. The thought of pulling this off excited me right from the start. The sheer volume of material I had to gather, the duration of the lectures and also the unknown variables of working in an academic context lead me way out of my comfort zone. That is as it should be, I thought. Additionally, I expected to reach some (= very, very few) students and teach them what I learned over the course of years. Maybe some of them would be willing to really listen what I had to offer.

So, my expectations where very different from Jens’. I focused more on the experience itself and had less expectations on the students.

Because of that, there was never a moment in which I really thought about not doing this job. ;)

My Approach

In my role as technical team lead, I facilitated multiple onboardings of younger software craftsman, including teaching specific technology, methods and processes. I learned what to expect and, more important, what not to expect from junior developers. Hence, my goal for the teaching assignment at Ostfalia was defined very early: Teach the basic skill set I wish every new junior developer would bring when entering one of my teams.

In my experience, shallow knowledge of a broad spectrum of topics is more important for a young developer than deep knowledge in just a few topics. I want to hear “Yeah, I heard that once. It has to do with x and solves problem y. But I don’t know specifics yet.” more often than “I don’t know anything about x, but I’m a specialist in y.” It’s important to first get a broad overview of the most important concepts and deepen them one after the other when needed. Hence, I build a very broad curriculum for the course that included methods like Scrum, key skills like communication, coding-topics like Spring as well as basic software engineering like refactoring techniques. I intentionally avoided deep-dives in any specific technology. Instead, I tried to transfer some of my passion for the awesomely active community of software craftsman by continuously reporting community events and telling the students the importance of visiting those meetings. Additionally, I spiced up my talks with a lot of “war stories” that put the theoretical knowledge in perspective. My expectations in this specific topic were especially low. It’s clear that students in the 3rd semester will not appreciate my stories from the trenches of harsh project situations as much as seasoned developers who know how easily a project can turn into mayhem and what the risks can be. My audience would mainly just pass the exam at the end of the course, not thinking about their future in 10 years.

Organization

Organizing so many talks was specifically interesting. Luckily, I had more than enough time available for preparation because I was asked months in advance. I used the time available as best as I could by beginning the preparation of the course very early and filling in gaps over a period of many months.

However, I needed much more time for preparing the course material, despite the fact that I’ve prepared many workshops and talks in the past. But these were mainly more advanced topics, focused on few specific problems. Also, my existing workshops were not entirely useable for students and had to be adapted.

I also thought about having exercises with coding and deep-diving into specific methods of software engineering. However, this would have added an additional unknown layer of complexity that would be hard to estimate. It would have been great, but I don’t regret the decision to leave this out as part of my risk management of my first attempt of giving lectures.

Overall, I invested 330 hours into the course, consisting of 300h for preparation and giving the lectures, 20 hours for correcting the test and 10 hours for feedback talks and oral exams

A huge part of the success of this course came from my employer, msg DAVID, who encouraged me to give this lecture and supported me in the organization. Once again: Thanks for the freedom to do awesome things and the ongoing support!

Teaching Experience

During the years, I got some experience in preparing and giving talks due to my activities in the community. However, in the lectures, I was always pretty exhausted after speaking for 3 hours straight. Those consisted of two 90 minutes’ lectures with a 15-minute break in between. This break however was mostly used for questions or small talk, denying me the chance to reboot mentally (which was OK because I helped the students).

Another difference to community-events was the shown interest by the audience. In professional community talks there are very few participants that obviously are not interested in what the speaker has to say. That’s pretty logically because every participant of a such a meeting invested personal time to come to the event or paid money to visit a conference. Students in a lecture however have very different motivations in being there. Some of them are not interested in the lecture at all. Quick callout to some “specialists” in my course: Every speaker immediately notices uninterested participants. Yes, it’s pretty obvious that some of you only fiddle around with their phones. Writing that I notice that these students will definitely not read this post. Well, I said it anyway. ;) I’m glad that I prepared myself for those situations of disinterest in me, so it’s absolutely OK for me.

Thinking about the whole course with all its exhausting lectures, it has been a lot of fun. Of course I do realize that my students were mainly really nice people that gave me a lot of slack. Thanks, guys! :)

Final Test

I decided to create a very “one-dimensional” test that can be passed with a good grade by simply visiting all of the lectures and listening to me. Memorizing key concepts resulted in a very good mark. That is, in my opinion, exactly what I promised my students in the very first lecture.

A very irritating experience has been the contrast between the amount of question on how to prepare best for the final test and the attendance to my very last lecture. There have been a lot of questions, but relatively few students in the last lecture. In my experience, this is the time when the docent has already created the test and often tells a lot of very useful spoilers on the topics that will be in the test. That has been the case for my last lecture. Not only did I repeat the most important parts of the code-heavy lessons, I also told the answers of some of the original test questions! Just by learning what I said in those 30 minutes, approximately 30% of the questions should have been a piece of cake.

Retrospective

After having prepared the final exam, I did some thinking about the whole experience on giving the lecture. Already when preparing the lectures, it became clear that it is very, very expensive and inefficient to do this course only one time. The preparation is not usable for other projects or workshops because it’s way too low-level. It would be best to do this whole thing again in the next year, which is not possible. Then, I would also have the mentioned exercises.

Among my students, there have been very great differences in knowledge-level and willingness to perform. Not surprisingly, most of the students only want to learn for the test. That’s slightly disappointing because I see the course as way more than just “getting a good mark”. I hope some of them will see the real benefit sometime in the future.

At the end of the semester, there has been a feedback from students which was conducted using a standardized template. My overall grade was a 2.3 on a scale from 1 (best) to 5 (worst). First, I was a little bit disappointed because I’m used to a much better rating of my events. A talk with former students and Jens (guy who did the lectures a couple of years ago) put that into perspective. Two main factors for the “not perfect” feedback are the missing exercises, which would have brought more diversity to the lectures. Also, students are not used to the broad scope of the topics I presented. It’s hard to prepare for a test when there are so many different topics.

However, compared to the average rating of courses at Ostfalia, my course is not that bad.

Would I do it again?

Yes!

Because I chose my metric of success wisely, I had great fun, learned a lot and fulfilled a dream I had since my time at the university. Thanks to Bernd Müller for the chance to do this!

The whole material of the course can be found at Github.