Informatiklehrertag Bayern 2016, Erlangen (und Sonstiges)

Ich habe mir wieder Anregungen geholt bei einer Fortbildung. Kaffee gab es schon vor dem Eröffnungsvotrag, eine ganz wichtige Sache, finde ich. Nach dem Vortrag war dann eine kurze Schlange sowohl beim Kaffee als auch bei den Toiletten. Jedenfalls bei den Herren – Informatikveranstaltungen dürften einige der wenigen Gelegenheiten sein, bei denen man tatsächlich bei den Damentoiletten weniger lang warten muss als bei den Herren.

Michael Koelling ist der Kopf hinter BlueJ und Greenfoot, zwei sehr verbreiteten und miteinander verwandten Java-Entwicklungsumgebungen für Anfänger, die in Bayern am Gymnasium äußerst verbreitet sind. Er stellte im Eröffnungsvortrag ein tolles neues Feature von Greenfoot (und bald auch BlueJ) vor und plädierte dafür, erst mal machen zu lassen, statt alles bis ins Detail zu erklären. Das heiße auch, dass das in Deutschland gering geschätzte „nur programmieren“ positiver gesehen weren solle. Die Informatikdidaktik in Deutschland betont nämlich sehr (letztlich wohl auch, um den Allgemeinbildungsanspruch des Fachs zu verteidigen), dass es in der Informatik eben keinesfalls ums Programmieren geht, sondern um anderes, etwa das Modellieren. Und das stimmt ja auch. Aber wenn man etwas früher mit dem Programmieren anfinge, finde ich, würde das Modellieren später mehr Sinn machen.

Selber war ich in einem Workshop zum Arduino, scherzhaft informatishes Töpfern genannt: weil es da darum ging, mit Drähten zu arbeiten und Sensoren und Motörchen und so. Das liegt mir selber überhaupt nicht, mir reicht Text zur Ein- und Ausgabe völlig. Aber für die Schüler möchte ich die physikalischere Informatik ja auch anbieten können, also muss ich das auch mal selber ausprobieren. (Drähte. Dioden. Masse. Das ist doch Physik.)

Eine Lehrerin erzählte von ihrem bilingualen Unterricht. War dann aber doch nicht das, was ich dachte, sondern Java und Scratch parallel, also zwei Programmiersprachen.

Überstundenstand der letzten zehn Tage: 5, kommende Woche noch 4 dazu.

Tagged: Tags

7 Thoughts to “Informatiklehrertag Bayern 2016, Erlangen (und Sonstiges)

  1. „Das heiße auch, dass das in Deutschland gering geschätzte „nur programmieren“ positiver gesehen werden solle.“
    Ich denke das es kein Widerspruch sein muss, „erst mal machen zu lassen, statt alles bis ins Detail zu erklären“ und „nur programmieren“ nicht in den Fokus zu nehmen. Auch beim Modellieren muss ich ja eine gewisse Idee davon haben, was möglich ist und was nicht. Entdeckendes Lernen zum Beispiel ist mit einer Programmierumgebung durchaus möglich, ohne beim Programmieren stehen zu bleiben. Aber Bayern ist ja auch bekannt dafür, relativ akademisch im Unterricht vorzugehen und weniger problemorientiert. In Hamburg ist es schon anders, zumindest von den Rahmenvorgaben her ist weniger Inhalt und mehr Kompetenz im Fokus. Ich denke einfach „nur Programmieren“ trifft nicht den Kern der Informatik und sollte gerade auch um das Bild in der Öffentlichkeit zu öffnen, nicht zu sehr im Fokus sein, auch wenn sehr wohl experimentell und ohne theoretische Vorüberlegungen und Modellierungen mit einer Umgebung „gespielt“ werden kann, das ist ja auch schlüssig, wenn induktiv statt deduktiv gelehrt wird.

  2. „relativ akademisch im Unterricht vorzugehen und weniger problemorientiert“
    Das muss kein Widerspruch sein.
    Als in der Hauptschule noch programmiert wurde (bis Mitte des letzten Jahrzehnts) hatten wir immer ein Problem, das es zu lösen gab und dann wurde aber wild drauf los programmiert.

  3. „Informatikveranstaltungen dürften einige der wenigen Gelegenheiten sein, bei denen man tatsächlich bei den Damentoiletten weniger lang warten muss als bei den Herren.“

    IT generell würde ich sagen. Und ich gebe es ein bisserl ungern zu: das erfreut mich jedes Mal ein wenig.

    „(Drähte. Dioden. Masse. Das ist doch Physik.)“
    Nee, Hardware. Je näher es daran geht, umso noch gerniger wird die Frauenquote. Und auch die kommt ohne Software nicht aus, allerdings ist Java da dann noch sehr weit weg …

  4. >„relativ akademisch im Unterricht vorzugehen und weniger problemorientiert“
    >Das muss kein Widerspruch sein.

    Das sehe ich auch so. Und ich hätte gerne wieder mehr Programmieren an Hauptschule und Realschule. (Auch an der Realschule gab es früher mehr.) Mehr Problemorientierung kann aber nicht schaden.

    >„(Drähte. Dioden. Masse. Das ist doch Physik.)“
    >Nee, Hardware.
    Stimmt schon. Und muss ja auch sein. Ein bisschen.

    Es ist so, dass meinen Schülerinnen und Schülern das Modellieren einfacher Dinge leicht fällt, das Implementieren dagegen gar nicht. Also hätte ich gerne mehr Zeit fürs Implementieren.

  5. Ich nehme an, Kölling hat die Stride-Erweiterung vorgestellt, oder? Ich bin auch sehr fürs „erstmal Machen lassen“. Das ist allerdings meiner Erfahrung nach in Java aufgrund der Syntaxbarriere fast unmöglich. Deshalb ist Stride sicher eine gute Idee. Ich mache immer zum Einstieg ins Programmieren vier Wochen Snap. Wunderbar, wie viel da geht – und wie frustrierend für die Schüler jedesmal, wenn man dann in Java wieder zurück auf Null muss und plötzlich nichts mehr intuitiv klappt. Vielleicht ist Stride da eine gute Alternative. Ich warte da noch ein bisschen ab.

    [Achtung: ab jetzt Mini-Rant] Die Dichotomie „Modellieren vs. Programmieren“ (oder oft sogar: das behauptete Primat der Modellierung) ist für mich zu einem roten Tuch geworden. Beim Modellieren fällt m. E. erstmal alles weg, was Spaß macht: Der Feedback-Loop zwischen Mensch und Computer, das Ausprobieren von Lösungswegen und Lernen aus Fehlern, das „Reframing“ von Bugs zu Features („Oh, der fällt nicht, sondern steigt hoch… egal, wird’s statt Jump&Run eben ein FlappyBird-Klon!“), usw. Nun ist natürlich nicht Spaß das Ziel. Aber Motivation ist eben schon wichtig.

    Und Problemorientierung: Geht’s denn noch problemorientierter als „Löse diese Aufgabe. Aber nicht selbst, sondern bringe den Computer dazu, es für dich zu tun“? Übrigens muss das nicht per Programmiersprache sein: Ich mache inzwischen auch erstmal eine ganze Weile Abfragen mit SQL, bevor ich über ER-Modellierung oder Normalisierung spreche. Modellierung ist abstrakt, die Arbeit am Computer konkret.

    Abgesehen von Motivation und Problemorientierung, also der pädagogischen Sichtweise, halte ich einen zu starken Fokus auf Modellierung auch sachlich für falsch. Modellieren ohne Programmieren, das ist für mich so eine Wirtschaftsinformatikersichtweise: Wir entwickeln das Modell und die Programmierer setzen das dann bitteschön um (für weniger Geld, weil wir ja die konzeptuelle Arbeit machen). Aus diesem Denken ist das Wasserfallmodell entstanden – von dem ich hoffe, dass es niemand mehr unterrichtet, geschweige denn anwendet. Heutzutage sind das eng ineinander greifende, iterative Prozesse. S. z.B. https://en.wikipedia.org/wiki/Agile_software_development

    @Hauke: Die Aussage „Programieren ist nicht der Kern der Informatik“ hört man ja in Deutschland oft (viel häufiger als anderswo). Solche negativen Aussagen sind ja schnell gemacht (und meistens auch irgendwie, aber auf triviale Weise richtig. „Kunst ist nicht nur Malen.“ Klar.) Trotzdem fehlt mir da oft ein bisschen ein konstruktive Alternativdefinition. Deshalb die Frage an dich als gerade anwesender Vertreter dieser Ansicht: Was ist dann der Kern?

    Gerne auch schon mal meine Meinung in Kurzfassung: Der Kern ist der Begriff des Algorithmus. Oder etwas theoretischer: die gesamte Informatik basiert auf der Church-Turing-These, nämlich der Idee, dass Berechenbarkeit gleichbedeutend ist mit der Existenz eines Algorithmus, einer Turing- oder sonstigen Maschine.

    Für mich ist dieser algorithmische Kern auch die wesentliche Existenzbegründung für Informatik als Schulfach: Wenn ich ein Problem lösen kann, dann gibt es auch ein Rezept dafür, das ich formulieren kann und (je nach Problem) selbst ausführen oder von einem Computer ausführen lassen kann. Das sollen Schüler lernen: Probleme so zu durchdringen und Lösungen so präzise zu formulieren, dass eine dumme Maschine die Lösung umsetzen kann. Wie gesagt, nicht unbedingt durch Programmieren; aber Programme sind nun mal fleischgewordene Algorithmen (äh, ja, nee, die Metapher…), d.h. ich glaube tatsächlich, dass Programmieren näher am Kern der Informatik ist als viele andere Themen (die deshalb aber natürlich nicht unwichtig sind.)

    Fazit: Schülern dabei helfen algorithmische Problemlösungskompetenz zu erwerben ist mein vornehmliches Ziel als Informatiklehrer. Was ist deines?

    @Herr Rau: Sorry, das hatte jetzt irgendwie nichts mit dem Informatiklehrertag zu tun. Deshalb, um die Kurve zu kriegen, noch schnell: Ich finde das eine ganz großartige Veranstaltung und habe meinen Besuch bei euch von eine paar Jahren noch in toller Erinnerung. So eine Arduino-Fortbildung täte mir auch mal gut – ich mache, wie du, wenn möglich einen großen Bogen um die Hardware. Nicht ideal.

  6. Hallo :-)
    persönlich diskutieren fällt mir immer leichter, als „knackig“ auf einem Blog zu formulieren, was mir durch den Kopf geht…

    „@Hauke: Die Aussage „Programieren ist nicht der Kern der Informatik“ hört man ja in Deutschland oft (viel häufiger als anderswo). Solche negativen Aussagen sind ja schnell gemacht (und meistens auch irgendwie, aber auf triviale Weise richtig. „Kunst ist nicht nur Malen.“ Klar.) Trotzdem fehlt mir da oft ein bisschen ein konstruktive Alternativdefinition. Deshalb die Frage an dich als gerade anwesender Vertreter dieser Ansicht: Was ist dann der Kern?“

    Also für mich ist der Kern ähnlich wie du es anschliessend formulierst die (maschinelle) Informationsverarbeitung. Das heisst natürlich praktische Auseinandersetzung mit Maschinen, weil es motiviert, aber auch weil es handlungsorientiert ist und Konzepte lebendig werden lässt. Aber eben nicht notwendigerweise, wenn es auch mit anderem Material geht. Gerade um zu entmystifizieren, was Maschinen so verarbeiten finde ich wichtig deutlich zu machen, das die Maschine eben dumm ist, wie du treffend formulierst und eine wesentliche Arbeit eben ist, sich erstmal den Kontext anzuschauen, warum welche maschinell verarbeitbare Lösung besonders günstig ist. Teddybären oder Kartenspiele sortieren, kurze Wege suchen, … (ein paar Beispiele, die bestimmt auch Spaß machen, hab ich leider überwiegend noch nicht ausprobieren können aber klingen durchdacht: http://www.abenteuer-informatik.de/)

    „Gerne auch schon mal meine Meinung in Kurzfassung: Der Kern ist der Begriff des Algorithmus. Oder etwas theoretischer: die gesamte Informatik basiert auf der Church-Turing-These, nämlich der Idee, dass Berechenbarkeit gleichbedeutend ist mit der Existenz eines Algorithmus, einer Turing- oder sonstigen Maschine.“

    cool :-) ich bin da auch flexibel auf dem Weg, immerhin ist meine Schul-Informatik-Erfahrung bisher auch relativ begrenzt auf wenige Jahre. Das wesentliche Argument mit dem „Programmieren“ ist für mich auch, das Bild der Informatik in der nichtinformatischen Öffentlichkeit zu erweitern/anzureichern, und das scheint mir ein sehr schwerfälliger Prozess zu sein, immerhin stellen sich viele Menschen immer noch den „natürlich begabten Magier der krasse unleserliche Sachen schreibt“ vor und blocken dementsprechend ab.

    „Fazit: Schülern dabei helfen algorithmische Problemlösungskompetenz zu erwerben ist mein vornehmliches Ziel als Informatiklehrer. Was ist deines?“

    Ja, das klingt schlüssig als Zielformulierung, solange der Algorithmenbegriff nicht zu eng gefasst wird (also eben eher auch „Rezeptformulierung“ und strukturiertes Vorgehen im Umgang mit Maschinen im weiteren Sinne einbezieht)
    Ich hab ja eine Betriebsausbildung als Mechatroniker gemacht, das wurde ich auch mit typischen Problemen konfrontiert, deren Lösung ich im Informatik-Unterricht fördern möchte:
    Wo fange ich überhaupt an, begründet einen Fehler zu suchen? (bei Windows: Neustarten, bei offener Software: eingrenzen, abwägen, testen, …)
    Wie könnte mir eine Maschine bei einem realen Problem in welcher Form die Arbeit erleichtern (stumpfe, sich wiederholende Arbeit abnehmen), wo löse ich es lieber ohne Maschine (ich skizziere z.B. gerne mit Bleistift)
    usw.

    Danke für die konstruktive und interessante Diskussion,
    schöne Grüße von Hauke

    P.S.: Das mit den Damentoiletten ist Ausdruck einer gesellschaftlichen Situation, die ich traurig finde – ich hoffe, dass in Zukunft mehr Mädchen und Frauen einen Weg in informatische und technische Berufe finden und darin gerade in Schule bestärkt werden.

  7. Ja, Michael, er hat ein bisschen was zur Entstehungsgeschichte von BlueJ und Greenfoot gesagt und Stride vorgestellt. Ich bin schon gespannt, und kann mir sehr gut vorstellen, dass ich das in BlueJ erfolgreich mit Schülerinnen und Schülern nutzen werde.

    Entmystifizieren dessen, wie Maschinen so arbeiten: Das finde ich auch wichtig. Allerdings ist es immer noch ein großer Sprung vom Sortieren mit Balkenwaage und Filmdöschen zu „Schaut her, und im Prinzip genau so macht es der Computer auch, nur schneller“. Das entmystifiziert sicher, sagen wir mal, ein bisschen, aber mehr noch erst dann, wenn man selber in der Lage ist, einem Computer so etwas anzuweisen.

    In Q.E.D. versucht Richard Feynman die Quantenelektrodynamik zu entmystifizieren, indem er ebenfalls mit einer schönen handlungsorientierten Analogie arbeitet, und dann sagt: sehr ihr, im Prinzip machen das die Physiker mit ihren Berechnungen genau so, nur anders. Ein bisschen Mysterium ist für mich aber immer geblieben.

    Für die Öffentlichkeitsarbeit ist es wichtig, das Programmieren nicht so zentral zu sehen. Und es wurde früher, zu meiner Schulzeit, viel zu zentral gesehen, selbst wenn es da eh kaum Informatik gab. Aber ein bisschen mehr dürfte es schon sein. Programmieren ist für mich etwas Kreatives, das mir Spaß macht, das mir Möglichkeiten gibt, mich auszudrücken – beim Modellieren ist das nicht so.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.