LEHRSCHIENEN

Die Berechnungen

In den nächsten vier Monaten trafen wir uns alle zwei Wochen und entdeckten Schritt für Schritt die wunderbare Welt von Ruby und Co. Der Kurs umfasste die Sprache Ruby, Ruby on Rails, Javascript und einige beliebte Tools für RoR-Anwendungen wie Devise, Pundit, Sidekiq oder Carriewave.

Jeder Student hatte auch einen Mentor, der für die Motivation der Studenten und die Kontrolle ihrer Arbeit zwischen den Treffen verantwortlich war.

Der Angriffsplan

Als Lehrer kam ich vorbereitet mit 3 Jahren Erfahrung mit Ruby on Rails, 10 Jahren Erfahrung mit Programmierung im Allgemeinen und einigen Präsentationen mit Themen und Übungen.

Abgesehen von einem kurzen Kurs in Linux-Verwaltung, den ich vorher gemacht hatte, hatte ich keine Erfahrung mit dem Unterrichten. Was die Studenten betrifft, so wusste ich nur, dass es zehn von ihnen sein würden und dass sie aus sehr unterschiedlichen Verhältnissen kommen - für einige von ihnen ist es die erste Berührung mit dem Programmieren, während andere versucht haben, C oder Ruby auf eigene Faust zu lernen, bevor sie sich für den Kurs angemeldet haben.

Ich beschloss, zwei Vorsätze zu fassen - ich werde geduldig sein und alles erklären, wenn es nötig ist (kein "das haben wir schon behandelt"). Der erste Vorsatz hat sich im Laufe der Zeit bewährt, der zweite - ganz offensichtlich - nicht. Ich beschloss, mich nicht speziell auf die Dinge vorzubereiten, die ich unterrichten wollte - ich arbeite jeden Tag mit Ruby/Rails und bin ziemlich zuversichtlich, was meine Fähigkeiten auf diesem Gebiet angeht. Ich habe allenfalls die Präsentationen gelesen, die ich hatte.

Die Herausforderung

Eines der ersten Dinge, die mir gleich nach Beginn des Kurses klar wurden, war, dass man nicht alles erklären kann. Das ist eine sehr traurige Erkenntnis für jemanden wie mich, der gerne in die Tiefe geht und herausfindet, wie die Dinge funktionieren, aber in der begrenzten Zeit eines Treffens kann man nur so viel lehren, dass die Teilnehmer es sich merken können. Es stellt sich heraus, dass man ein sehr guter Ruby-Programmierer sein kann, ohne genau zu wissen, wie Arrays im Speicher dargestellt werden oder wie Devise genau funktioniert.

Der Unterricht fand samstags und sonntags von 9 Uhr bis 17 Uhr statt. Man muss sich darüber im Klaren sein, dass Unterrichten eine ziemlich anstrengende Arbeit ist - neben dem Erklären des Stoffes muss man auch immer bereit sein, damit zusammenhängende (oder nicht so zusammenhängende) Fragen zu beantworten und verschiedene Probleme der Schüler zu lösen.

Kaffee ist Ihr Freund, aber das Wichtigste ist die bereits erwähnte Geduld. Für Menschen, die noch nie programmiert haben, müssen Konzepte, die für Programmierer selbstverständlich sind - wie Schleifen, Typen oder sogar Variablen - erst erlernt werden, und das geht nicht von heute auf morgen. Wenn Sie seit XX Jahren programmieren, Mathe für einfach halten und alle bekannten Programmierparadigmen mitten in der Nacht aufzählen können, fällt es Ihnen vielleicht schwer, sich in die Lage einer Person zu versetzen, die nicht genau weiß, auf welche Seite des Gleichheitszeichens der Name der Variablen gehört. Aber es ist unerlässlich, dass Sie es tun. Grundlegende Konzepte wie Variablen, Schleifen oder Arrays werden so selbstverständlich, dass es schwer zu verstehen ist, wie jemand sie nicht auf Anhieb verstehen kann, aber sie sind schwieriger als sie für "uns Programmierer" erscheinen.

Eine zusätzliche Schwierigkeit, vor allem zu Beginn des Kurses, bestand darin, diese Konzepte so zu erklären, dass sie gut verstanden werden. Meiner Meinung nach ist es nicht möglich, Rails zu lernen, ohne Ruby zu lernen - auch wenn ich weiß, dass einige das Gegenteil behaupten würden. Es stimmt, dass Rails seine eigenen Muster hat und dass man sich viele Dinge eher merken kann, als dass man sie am Anfang lernt. Ich denke jedoch, dass man, um ein gewissenhafter RoR-Entwickler zu werden, ein moderates Verständnis von Ruby, OOP oder SQL haben sollte. Menschen das Programmieren beizubringen ist etwas ganz anderes als Rails zu lehren - während man bei Rails vieles erwarten kann, das einfach akzeptiert oder geglaubt wird (niemand muss am Anfang wissen, wie Callbacks funktionieren - nur was sie können), sollten Programmierkonzepte ausführlicher erklärt werden.

Die Macht einschalten

Und wie macht man das?

Geduldig.

Es kommt mir wahrscheinlich so vor, als würde ich mich ständig wiederholen, aber ich kann nicht genug betonen, wie wichtig Geduld ist. Selbst meine motiviertesten Schülerinnen und Schüler machen hier und da einen Syntaxfehler - das ist Teil des normalen Lernprozesses, und als Lehrer kann man eigentlich nichts anderes tun, als ihnen zu zeigen, worin der Fehler besteht und wie man ihn behebt. Mit der Zeit werden sie lernen, diese Fehler selbst zu beheben, aber dazu braucht es mehr als nur einen oder zwei Fehler.

Ein weiterer Punkt ist, dass Ruby nicht so einfach ist, wie es scheint. Wenn Sie Ruby mit Kenntnissen in C/Java/Python lernen, erscheint Ihnen wahrscheinlich alles so sauber und schön einfach. Versuchen Sie aber, darüber nachzudenken, und Sie werden es merken:

1. Was hat es mit den Klammern auf sich? Soll ich sie verwenden? Sollte ich das nicht?
2. Was ist das? selbst Sache? Manchmal muss ich es verwenden (z. B. attr_writer – self.variable = ...), manchmal auch nicht (attr_reader – variabel) und manchmal kann ich es nicht! (private def some_method – self.some_method wird einen Fehler auslösen)
3. Blöcke. Ich wette, dass sogar einige erfahrene Programmierer (verschiedener Sprachen) einen Moment mehr als erwartet brauchen, um zu verstehen #inject

Abgesehen von der einfachen Fehlerkorrektur geht es auch darum, Ihr Verständnis der Dinge auf Ihre Schüler zu übertragen. Dazu brauchen Sie eine Menge Flexibilität. Einigen Schülern genügte es, wenn Array nur eine geordnete Liste von Elementen war. Andere brauchten eher eine visuelle Analogie, z. B. ein Regal mit nummerierten Plätzen, auf die man Dinge stellen kann. Ich habe die gleichen Dinge mehrmals auf unterschiedliche Weise erklärt - eine ziemlich anspruchsvolle Aufgabe!

Aber, wie ich schon sagte, man kann nicht alles erklären. Als ich die Relationen in Rails erklärte, war es eher ein "so macht man das, und es erlaubt einem, das und das zu tun. Wenn du das willst, ist es super". Glücklicherweise hat mich niemand gefragt, wie das funktioniert - ich denke nicht, dass junge Entwickler etwas über Reflexionen wissen müssen.

Situative Positionierung

Aufgrund des Formats unseres Kurses (Treffen an jedem zweiten Wochenende und lange Pausen) mussten wir sicherstellen, dass die Zeiträume zwischen den Wochenenden für unsere Studenten produktiv sind - ohne dass sie in dieser Zeit üben, würde der Kurs überhaupt nicht funktionieren.

Einige meiner Mitarbeiter erklärten sich bereit, als Mentoren für die Studenten des Kurses zu fungieren. Die Aufgabe der Mentoren bestand darin, die Übungen zu überprüfen, die während der Wochenendtreffen zugewiesen wurden, und bei Problemen zu helfen, die bei der Bearbeitung auftraten. Die Studenten kommunizierten mit den Mentoren über Slack.

Ich war Mentorin für zwei meiner Studenten. Das war eine ganz andere Form des Unterrichtens - und voller eigener Fallstricke. Eine Sache, die ich ein bisschen zu spät erkannt habe, ist, dass ein guter Programmierer unabhängig sein muss - er sollte zumindest versuchen, Probleme selbst zu lösen, bevor er um Hilfe bittet. Und ständig auf Slack erreichbar zu sein, hat mich nicht nur viel Zeit gekostet, sondern auch nicht gerade zur Unabhängigkeit inspiriert.

Verstehen Sie mich nicht falsch - viele Fragen, die mir als Mentor gestellt wurden, waren berechtigt und die Beantwortung dieser Fragen war eine Erweiterung des Wissens der Schüler. Es ist jedoch sehr einfach, in den "Lehrermodus" zu wechseln und all die Themen aus den Wochenendtreffen erneut zu erklären. Aus heutiger Sicht denke ich, dass die Rolle eines Mentors darin besteht, einen Überblick zu geben, nützliche Links zu liefern und Fragen zu stellen, die bei der Lösungsfindung helfen können. Gelegentliches Erklären kann vorkommen, sollte aber nicht den Großteil ausmachen.

Der Einsatz von Intelligenz

Jeder Schüler ist anders. Eine der größten Schwierigkeiten bestand darin, das Tempo des Kurses so zu gestalten, dass es für alle Schüler optimal ist. Aufgrund der unterschiedlichen Hintergründe und des allgemeinen Niveaus der Akzeptanz neuer Ideen unter den Studenten ist dies eine fast unmögliche Aufgabe.

Unser Zeitplan sah 9 Treffen vor - mal 2 Tage mal 8 Stunden ergab 144 Stunden, um von 0 auf Ruby-hero zu kommen. Es war von größter Wichtigkeit, den gesamten Lehrplan in dieser Zeit zu absolvieren - was an sich schon ein ziemlich schnelles Tempo erzwang. Bei den ersten drei Treffen ging es nur um Ruby - dann ein Treffen für SQL, dann RoR und dazwischen ein Treffen für JS.

Als Lehrer musste ich immer wissen, wer einen Teil des Materials, das ich präsentierte, mehr oder weniger verstanden hatte. Manchmal reichte es, zu fragen, ob das verstanden wurde, manchmal habe ich kleine Tests gemacht. Zum Beispiel habe ich alle meine Schüler gebeten, mir ihre eigenen Definitionen von Ruby-Begriffen zu schicken, wie Klasse, selbst, Methode, variabel etc. auf Slack. Wenn ein Thema besonders unklar war, würde ich zurückgehen und versuchen, es erneut zu erklären.

Illusion und Wirklichkeit

Zusammenfassend lässt sich sagen, dass das Unterrichten ein noch schwierigeres Unterfangen war, als ich es mir vorgestellt hatte. Es kann auch sehr lohnend sein. Nichtsdestotrotz ist es harte Arbeit, und die Auswirkungen hängen nicht allein vom Lehrer ab - die eigenen Anstrengungen der Schüler sind für ihr Lernen noch wichtiger. Das macht das Unterrichten ganz anders als das Programmieren, bei dem man normalerweise alle Erfolge und Misserfolge für sich verbuchen kann. Es ist wichtig, sich diesen Unterschied zu vergegenwärtigen.

Es zwingt einen auch dazu, über Dinge nachzudenken, über die man normalerweise nicht nachdenkt - wenn man Dinge erklärt, versteht man sie auch besser. Auf diese Weise kann man durch Unterrichten auch ein besserer Programmierer werden.