The good teacher learns more from the student(s) than vice versa
When I first heard this saying, I thought it is nonsense. When the full bucket pours water into the empty buckets, then there is more growth in the empty buckets. And when the bucket is almost full, how much additional water can be poured into it? There is more free space in empty buckets.
But, finally, knowledge is no material like water. When I pour knowledge into my students, then I do not empty myself. Knowledge, like joy, love, friendship etc. multiplies by sharing. However, it does not multiply by a linear function. Teaching 100 students at a time is not the same as teaching 10. In a small group, each student can learn more than in a large group because in the small group there is less distance between us and I can adapt the training better to each student´s needs. On the other hand, groups can be guided to learn from each other and these synergy effects can scale, using the right exercises. Nevertheless, in a large group, my ability of steering the learning effect diminishes. I do not automatically get feedback about learning progresses and misunderstandings, but must organize such feedback loops intentionally.
I as the trainer do not loose any knowledge by teaching. I just share it. And if done well, I can learn a lot from teaching. While being an expert, I have the head in the skies and philosophise about intellectually fascinating details, my teaching forces me to stay on the earth with my feets. Again and again, I am asked what these methods are good for and how they can/ must be applied in practice. Very trivial practical questions arise like "What material is needed for this method? How many meta plan cards are needed per participant?" Teaching forces me to NOT forget that what I teach is not trivial and not self-explaining. Feedback from exercises and exams teaches me which method is how easy to learn, but also whether my teaching (material) is appropriate. Finally, as I teach the simple bascis, the training MUST allow everyone to learn everything. So, the students teach me to teach. I am only full master of a method when I can teach it, and not only apply it myself. Software engineering is team work, so this is more important in software engineering than in mathematics. One can be a good mathematician without being able to explain one´s work to everyone. But if I can not explain software engineering to all stakeholders from directors to secretaries, then I am no good software engineer. Hard, but true.
The third way how I learn from teaching is that I enter into many exercises with a more or less formal research question in mind. Some exercises are even formally prepared, executed and evaluated as scientific experiments, which not only provide aha experience to me, but also to the scientific world. Most often, the research question is informal. For instance, I was curious to apply Kano requirements prioritization compared to another method, with the same unbiased stakeholders to the same requirements, to experience the difference. For the students, it was just an exercise where we used two different methods for the same task. So, they know them both and can they apply in their job when needed. But for me as an expert, the learning effect was much higher. When prioritizing requirements in categories "low", "average" and "high", we met those difficulties that one always has then. Questions arise like "Whose perspective do we take? The user´s? The manager´s? The developer´s?" And "How high is high? What is our reference?" With Kano prioritization, those questions did not arise at all, because we clearly took the user perspective and the reference is the state of the art/ the market. This made the prioritization extremely fast and the group agreed easily. Differences in opinion could be eliminated by mentioning a competing product that already has a certain feature. It became also clear from our discussion, that when the market advances, the Kano priorities become out-dated, and that a prioritization from other stakeholders´ perspectives must probably be done additionally. This was a clear result, but I am not sure whether the students fully can enjoy this result or whether they think it is trivial. These findings were not unexpected, but as a critical spirit, I had to experience and see it before I fully believe it. In my current software engineering course, we regularly transform one UML model into another (e.g. activity diagram into sequence diagram, state diagram into activity diagram) to experience the difference. I designed these exercises in a way that also I do learn something and this makes my course more interesting for myself. Anyway, I constantly modify my courses in order that they stay interesting and new for myself. I am such a bad comedian. When the course is boring for me, then the participants fall asleep. So, I am in constant search for more exciting stuff, the latest trends, and thrilling exercises. (Well, anyway, as in IT half of the knowledge becomes obsolete within 4 years, the same is true for my training material. Half of the slides become out-dated within 4 years!)
So, yes, the teacher´s strive for learning in his own courses improves the courses.
But, finally, knowledge is no material like water. When I pour knowledge into my students, then I do not empty myself. Knowledge, like joy, love, friendship etc. multiplies by sharing. However, it does not multiply by a linear function. Teaching 100 students at a time is not the same as teaching 10. In a small group, each student can learn more than in a large group because in the small group there is less distance between us and I can adapt the training better to each student´s needs. On the other hand, groups can be guided to learn from each other and these synergy effects can scale, using the right exercises. Nevertheless, in a large group, my ability of steering the learning effect diminishes. I do not automatically get feedback about learning progresses and misunderstandings, but must organize such feedback loops intentionally.
I as the trainer do not loose any knowledge by teaching. I just share it. And if done well, I can learn a lot from teaching. While being an expert, I have the head in the skies and philosophise about intellectually fascinating details, my teaching forces me to stay on the earth with my feets. Again and again, I am asked what these methods are good for and how they can/ must be applied in practice. Very trivial practical questions arise like "What material is needed for this method? How many meta plan cards are needed per participant?" Teaching forces me to NOT forget that what I teach is not trivial and not self-explaining. Feedback from exercises and exams teaches me which method is how easy to learn, but also whether my teaching (material) is appropriate. Finally, as I teach the simple bascis, the training MUST allow everyone to learn everything. So, the students teach me to teach. I am only full master of a method when I can teach it, and not only apply it myself. Software engineering is team work, so this is more important in software engineering than in mathematics. One can be a good mathematician without being able to explain one´s work to everyone. But if I can not explain software engineering to all stakeholders from directors to secretaries, then I am no good software engineer. Hard, but true.
The third way how I learn from teaching is that I enter into many exercises with a more or less formal research question in mind. Some exercises are even formally prepared, executed and evaluated as scientific experiments, which not only provide aha experience to me, but also to the scientific world. Most often, the research question is informal. For instance, I was curious to apply Kano requirements prioritization compared to another method, with the same unbiased stakeholders to the same requirements, to experience the difference. For the students, it was just an exercise where we used two different methods for the same task. So, they know them both and can they apply in their job when needed. But for me as an expert, the learning effect was much higher. When prioritizing requirements in categories "low", "average" and "high", we met those difficulties that one always has then. Questions arise like "Whose perspective do we take? The user´s? The manager´s? The developer´s?" And "How high is high? What is our reference?" With Kano prioritization, those questions did not arise at all, because we clearly took the user perspective and the reference is the state of the art/ the market. This made the prioritization extremely fast and the group agreed easily. Differences in opinion could be eliminated by mentioning a competing product that already has a certain feature. It became also clear from our discussion, that when the market advances, the Kano priorities become out-dated, and that a prioritization from other stakeholders´ perspectives must probably be done additionally. This was a clear result, but I am not sure whether the students fully can enjoy this result or whether they think it is trivial. These findings were not unexpected, but as a critical spirit, I had to experience and see it before I fully believe it. In my current software engineering course, we regularly transform one UML model into another (e.g. activity diagram into sequence diagram, state diagram into activity diagram) to experience the difference. I designed these exercises in a way that also I do learn something and this makes my course more interesting for myself. Anyway, I constantly modify my courses in order that they stay interesting and new for myself. I am such a bad comedian. When the course is boring for me, then the participants fall asleep. So, I am in constant search for more exciting stuff, the latest trends, and thrilling exercises. (Well, anyway, as in IT half of the knowledge becomes obsolete within 4 years, the same is true for my training material. Half of the slides become out-dated within 4 years!)
So, yes, the teacher´s strive for learning in his own courses improves the courses.
AndreaHerrmann - 18. Nov, 11:41
