KIF460:Wie lernt man Programmieren (sinnvoll, effizient) ? (Austausch, Brainstorming)

1. Programmieren lernen

1. 1. Beispiele

• TU Darmstadt:

   * Programmiervorkurs (1 Woche vor Semester)
       * reines Programmieren (Java, da in Vorlesungen verwendet)
       * Computersysteme in der Uni verwenden
       * ohne Vorkenntnisse
       * Schematisches ist ein Wenig enthalten
           * Wird in der Vorlesung ausfürlich genug behandelt
   * Java & Racket im 1. Semester und Java weiterhin im 2.
   * bis ins 3. Semester in Uebungen enthalten
   * 4. Semester Programiersprachen werden 

• TU Dortmund:

   * Programmiervorkurs (1 Monat vor Semester)
       * Auch für Studierende mit Vorkenntnissen geeignet
       * Es wird auf wenigstem Vorwissen aufgebaut
           * schnelles Tempo
           * Fortgeschrittene helfen Anderen
       * Einschraenkung auf basis Befehlssatz, erweiterte Befehle nachbauen
   * Caffeine & Code
       * gegen Ende des Semesters / Anfang der Semesterferien
       * Tutoren von Veranstaltungen bieten privat selbstgestellte Zusatzaufgaben an
       * in großer Runde
       * quasi private Klausurvorbereitung
   * Vorlesungen
   * 1. S: typisch Java einstieg
   * 2. S: Algorithmik realisieren
   * 3. S: Softwaretechnik (UML, ...)
   * 4. S: Softwarepraktikum (Projektgruppen, Selbststaendig, ...)
   * 5. S+: Wahlpflicht Softwareentwicklungs-Vorlesungen
   * 30% nur Programmieren, Algorithmik und Datenstrukturen (Java, C, Haskell)

• Kiel:

   * Aehnlich zu TU Dortmund
   * Sozialproblematik wird mit Bonusaufgaben angegangen
   * Programming challenges kurs von Fachschaft ausgehend
       * Raetselaufgaben mit grossen Eingaben
       * Teamarbeit
       * 1.-5. Fachsemester empfohlen
       * zum Spass, nicht pflicht
   * 1. Semester: OOP (Java + Konzepte)
   * 2. Semester: Betriebs-/Kommunikationssysteme (ein wenig C)
   * 2. Semester: (Algorithmen in Java Umsetzen)
   * 3. Semester: Java Nebenlaeufigkeit + Generics
   * 3. : Prolog
   * 4. : Softwaretechnik
   * weiter nicht bekannt

• HU Berlin:

   * 1 Modul 1. Semester
       * Code wird vorgelesen
       * Begleitend entsprechende Uebungen

• Tuebingen:

   * 1. S: OOP
   * 2. S: Prozedurell (Racket)
   * Nichts weiter bis Projektarbeiten
       * dort *koennen* ca. 1 bis 2 pro 10er gruppe "programmieren"

• Goettingen:

   * 1. S: Java
   * 1.5 S: C-Kurs
   * 2. S: Haskell und Assembler
   * 2. S: Gruppenarbeit Java

• Heidelberg:

   * Vorkurs
       * begrenzt viele Plaetze (50)
       * C++
       * Skript durcharbeiten mit Hilfe vor Ort
       * breit gefaecherte Durcharbeitungsquote
   * 1. S: C++ in 2 Modulen (Vorlesung + Uebung / Kurs mit live-Uebung)
   * 2. S: Algorithmen und Datenstrukturen (Python)
   * allgemein Veranstaltungen mit C++/Python ein Wenig

• HSK:

   * 1. S: Clicky Bunty (Lego Mindstorms)
   * 2. S: Java (langsames tempo)
   * Theorie und Praxis laufen Zeitlich sehr auseinander
       * Thematisch auch, Zeitlich ist groesseres Problem
       * Mit Prof muss darueber gesprochen werden
           * (Gespräche werden aktuel begonnen)

• TU Dresden:

   * 1. S: Lego Mindstorms + Python
   * C, Python, Java wie bei Anderen
   * Diverse Programmierkurse von Fachschaft ausgehend
       * keine Pflichtveranstaltung, wird jedoch so wahrgenomen
       * nicht zwangslaeufig fuer Vorlesung benoetigt

• Emden:

   * 1. S: kein Programmieren
   * 2. S: Verzweiflung

1. 1. Probleme / Loesungen

Ausstehende Fragen:

• Wie geht man mit unterschiedlichen Erfahrungen um?
• Balance Praxis/Theorie?
• Wie stellt man Aufgaben verstaendlich? (Praxis vs Prinzip)
• Welche Sprache eignet sich? Wahlkriterien?
• Best practices / Coding conventions (in welchem Rahmen?)
• Ziel?

   * Spass?
   * Vorbereitung Studium?
   * Freizeit-Motivation?

• Spannende Beispiele?

   * nicht nur langweiliger Pytagoras

1. 1. Meinungen

• Nur Folien statt ausprobieren ist nicht zu empfehlen

   * => Live-Coding
       * grosse Probleme bei Anderen, da Prof zu schnell und Anfaenger*innen kommen nicht mit ("keine Chance")

• Abstraktes Prinzip lernen ist schwierig

   * Algorithmen + Datenstrukturen Modul ist sehr hilfreich
       * Problemstellung
       * Algorithmus vorstellen
       * Loesung selbsstaendig
           * Problem wird erkannt
           * Algorithmen zusammensetzen erforderlich
           * "Baukasten" von Algorithmen
   * Darmstadt Vorkurs
       * Anfang: Was ist programmieren Einfuehrung
       * Beispiel: Kochrezept
           * Anweisungsschreibweise
               * 1. Kartoffeln schneiden
               * 2. Kartoffeln anbraten
               * 3. ...
       * Fuer Schulklassen:
           * 2 Personen teams
               * Aufgabe: "Druecke den Lichtschalter"
               * 2. Person muss in Teilanweisungen exakt unterteilen
                   * "Hebe den Arm"
                   * ...
   * Meinungsbild "Ist Unterteilung in Einzelanweisungen hilfreich?"
       * Hilft nicht jedem
           * eher labyrinth algorithmisch loesen (java-kara like)
       * Anderen hilft es
           * gerade bei niedrigem Wissensstand mit computern
       * Neukombination von elementaren Bestandteilen ist essentiell zu Lernen
   * Java-Kara als Beispiel
       * "Zum Kleeblatt laufen" mit Kochrezeptsystem erklaeren
   * 2 geschachtelte Schleifen als Einstiegsaufgabe schon schwierig
       * klein anfangen "wie gebe ich x aus"

• Praxis / Theorie

   * 3 Mal snake implementieren
       * mit Array
       * mit Liste
       * mit OOP
       * positive Erfahrung
           * Es gibt nicht nur einen Weg zur Lösung
           * Bausteine kennengelernt
               * koennen verschieden zusammengefuegt die gleiche Aufgabe loesen

• Beispiel Kiel Haskell Vorlesung

   * grossteil Sprachelemente kennenlernen
   * es werden nur Methoden benutzen, welche auch selber implementiert werden können
   * aufteilung auf
       * Vorlesung
       * Uebung
       * Testat

• Meinung: Von Hand auf Papier programmieren ist nicht effektiv zum Lernen

   * Grund: Leute, die nur am Rechner programmieren greifen auf IDE funktionen zurueck
       * => fallen in (nicht E-) Klausur durch
   * Goettingen
       * in bis zu 5 Kohorten, genuegend Computer vorhanden fuer E-Klausur
       * paar Ersties installieren IDE trotz Abraten
       * Vorteil von Start am PC: Als Anfaenger*innen schnell Erfolgserlebnisse

• Meinung: Mit IDE beschaeftigen ist Sinnvoll

   * hirzu giebt es gemischte meinungen.

1. 1. Welche Sprache?

• Wurde in vielen AKs bereits ausgiebig besprochen
• ist sehr abhaengig von Situation vor Ort

1. 1. Coding conventions

• Meinung:

   * Anfangen mit schlecht Formatierten und Kommentierten Code
   * Spaeter verbessern

• Gegenmeinung:

   * Am Anfang immerhin erwahnen, nicht durchzwingen, aber erwaehnen
       * "So macht man einen Kommentar"
       * Kommentare sind Sinnvoll
       * Variablennamen sind wichtig
       * ...

• Aufgabenstellung enthalten "Alle funktionen muessen kommentiert werden"

   * Bei nicht dokumentierten funktionen gibt es 0 Punkte
   * Es wird als Sinnvoller erachtet, conventions von vornhinein zu lernen

• Nutzt guidelines nach eigener Auswahl, aber einheitlich
• Vorlesung beinhaltet haeufig code quality Bemerkungen

   * ab 2. Vorlesung wird code quality in Uebungspunkte einbezogen

• Meinung: Selbsterkenntnis schwierig fuer Korrektur

   * 1. S Helfen ist schwieriger bei geringer code quality
       * Unnoetige Arbeit
       * => Am Anfang richtige Grundzuege beibringen ist Sinnvoller

• Viel manuelle Auswertung bei anwesenden Hochschulen, bei einigen automatisch, auch mischungen existieren

   * Wenn Tutor bei Korrektur nicht durchsteigt gibt es 0 Punkte
   * Testate
       * => Tutor muss nicht selbst den code verstehen
       * Kandidat*inn muss Code selbst erklären
       * Hat Kandidat*inn seinen Code "selbst geschrieben"/verstanden

• Prof: "Bestanden."

   * ohne feedback, ohne nachfragen, einfach draufschauen

1. 1. Unit Tests automatisch

• Fall A: sehr gut, da instant feedback und gute Rueckmeldung
• Fall B: schlecht, falls nur einmalige Abgabe und intransparente tests
• Fall C: 3 Versuche

   * mit Rueckmeldung
   * bei 3 Fehlfaellen manuelle ueberpruefung mit Teilpunkten
   * Zeitbeschraenkt
   * Vorgehende uebungen unbegrenzt

• Fall D: Oeffentliche und private tests

• Fall C wird allgemein nicht gut angesehen

   * zu hoher Druck fuer Studierende
   * mehrfaches Hochladen besser, als automatische Sperre
   * Schafft aber wohl eine geringere Durchfallquote (da als Klausurzulasung nötig)

• Compileprobleme bei Abgabe sind problematisch

   * imports
   * Systemabhaengige Fehler
   * ab 2. Semester 0 Punkte bei fehlschlagender Kompilation

1. 1. Fehlermeldungen - Wie gehte ich damit um?

• 1. Live-coding im Vorkurs:

   * befehl absichtlich Falsch schreiben
   * "was denkt ihr passiert?"
   * ausfuehren => Fehlermeldung
   * Aufbau von Fehlermeldung erklaeren
   * Exkurs Fehlermeldungstypen
       * Ausfuehren macht nichts kaputt, keine Angst!

• Testen von Abgaben, bei Fehlern darauf eingehen

   * wie gibt man Rueckmeldung?
       * strittig

• Musterloesungen Sinnvoll?
• An HS mit IDE (Eclipse) wird funktion von IDE verwendet, um Fehler zu beheben
• 1. + 2. Vorlesung: Helpdesk

   * Tutor fuer Problemfragen bzgl. Fehler (Stacktraces, ...)
   * Tutoren bieten bereitwillig Hilfe an (Sprechstunden)

• Programmierkurse

   * Probleme mit Fehlermeldungen wegen anderen Begrifflichkeiten in Vorlesung
   * Fachbegriffe unterscheiden sich von Professor*in zu Professor*in

• Viele Begriffe aus der Informatik sind nicht allen bekannt

   * aufpassen
   * ermutigen zu Nachfragen

• Prof hat Schwierigkeiten, Programmierkompetenzen einzuschaetzen

   * zu schnell ueber LinkedList, ...
   * auch wenn leicht erscheint kann Aufgabe sehr schwierig sein

1. 1. Fehlgeleitete Professoren

• Fall A: 1., 2. S (Jena):

   * 1. S: C
   * 2. S: Java
   * Vorlesung mit Folien
       * formale Anschauung, sehr abstrakt
       * keine Beispiele
       * kein live coding
   * Pro Woche mind. 4 Uebungsserien
       * Pflichtabgaben
       * Pruefungszulassung durch Uebungen
       * ~8% Klausur pro Woche durch Uebungspunkte
   * Problematisch fuer Programmieranfaenger*innen, da schon erste Uebung zur Klausur gehoert
       * ca. 10h Aufwand pro Uebungsserie fuer Anfaenger*innen
       * Testate und Kurzklausren zusaetzlich
       * zu wenig Zeit am Tag
   * mit Prof geredet
       * Problem besteht seit Jahren
       * Studierende merken, dass Vorlesung ihnen nichts bringt
           * gehen ggf. nichtmehr zu Vorlesung und lernen sebststaendig
       * Professor merkt, dass Vorlesung sich leert
           * interpretiert als Erfolg seiner im Vorraus hochgeladenen Folien
       * Meinung: Es sollte immer einen Mehrwert haben in der Vorlesung zu sein

• Fall B: Professor*in bringt getrennt Aufgaben fuer Studierende mit Vorkenntnissen

   * gaben Zusatzpunkte fuer Klausur
   * dadurch bevorzugung von Studierenden mit Vorkentnissen
   * direkt geblockt vom Dekan

• Fall C: Mindstorm

   * Vorlesung: Hier habt ihr das Programm, hier die Blaetter, macht mal.
   * Profesor*in musste mild korrigieren, um das Problem zu umgehen

• Fall D: Darmstadt:

   * neuer Professor hat im "rechtlichen Rahmen" ein programm aufgebaut
       * hat Fachschaft und Studierende abgeblockt "nur weil ich es anders mache"
       * Gespräche haben geholfen

1. 1. 1. Herangehensweisen an Professor*innen

• Fall C

   * Email mit details und klagen
   * Prof hat sich schliesslich entschuldigt

• Als Fachschaft an Prof herangehen

   * nicht als Studierende, sondern als Repraesentant
       * Vertreter*innen statt Individuen
       * => braucht Fachschaft, die sich fuer Studierende einsetzt und "nicht nur am Saufen interessiert ist"

• Fall B

   * Klausur musste stark runtergesetzt werden
   * Es haette proaktiver gehandelt werden muessen

• Fall D

   * ein Student ist nun Hilfskraft und schreibt das Skript

• Mehrfach aufgetreten, dass Studierende selbst Skript schreiben und in Vorlesungen mitwirken
• Abblocken von Professor*innen ist von Fall zu Fall extrem

   * Auch andere Organisationen (Hilfsgruppen, etc.) moeglich von Fachschaft ausgehend
   * Fallstudie: Angebot zum Bessern
       * Protokolliertes Gespraech
       * Regelmaessige Ruecksprachen
       * => Auf Dauer hat sich die Situation gebessert
       * Evaluation der Vorlesung mit Ampel system zur Verstaendlichkeit
           * explizit am Ende eines Kapitels
           * Ampel gruen => melden
           * Ampel gelb => melden
           * Ampel rot => melden
           * Alternativ mit Link (anonymisiert)
               * ggf. geringere Motivation?
                   * mueste getestet werden

1. 1. Ziele der Programmierkurse

• Viele Professor*innen

   * moeglichst schnell, moeglichst viel halbwegs laufender code
   * z.B. 10 minuten Sprint fuer Aufgaben ("3-Zeiler", aber enormer Stress mit Aufgabe lesen)

• einfachen Klartext in Algorithmen uebersetzen -> nicht immer Sinnvoll

   * existierende Loesung implementieren wird selten in Praxis verlangt

• Softwareengineering

   * Klartext Aufgaben (bis zu 2xA4)
       * Pseudo-real
       * Sinnvoller, als "pseudo-code-text"

• Motivation zu Programmieren

   * Wofuer ist es gut?
   * kann Spass machen!
   * Warum will ich programmieren koennen?
   * Keine schwierigen Probleme am Anfang
       * besser kleine Probleme für schnelleres Erfolgserlebnis

• Anregen das eigene Probleme oder Ideen in Programmen umgesetzt werden können

   * Neue Sachen lernen durch eigenen Ansporn

• Wie kann ich mir selbst Informationen beschaffen?

   * Negativbeispiel: Hier ist die C Referenz, lern das
   * Bekannte Websites
       * stack overflow
           * Anekdote: Es gibt Programm das automatisch bei Fehlern stack overflow befragt und ersten fix testet
   * Selber erforschen von Websites ist wichtig

1. 1. 1. Erfolgreiche Freizeitanregungen?

• Bsp: Links zu online-Raetseln fuer Freizeit

   * Vorschlag für Professor*innen: Pflichtabgaben erweitern
       * Normaler Teil
       * + Zusatzfunktionen ohne Vorgabe koennen implementiert werden
           * "Bauen Sie noch 2 Zusatzfeatures fuer 2 Bonuspunkte"
           * Zusatzfeatures koennen selbst ausgedacht werden
           * Kreativitaet wird gefoerder
       * Im Bereich Spielentwicklung
           * Bsp. Worms
               * Mögliche Zusatzimplementierungen:
                   * andere Projectiele
                   * Huepfen
                   * ...
       * Erfolgsmodell mit sehr kreativen zusatzfeatures

• Code wars AK

   * Spass, foerdert motivation

• Professor*innen live-coding

   * nicht einfach, da verschiedene Lerngeschwindigkeiten
   * nach und nach an ein Problem herangehen ist vorteilhaft

• Lego Mindstorm als Motivation gemeint

   * hier gescheitert, haette ggf. funktionieren koennen

• ACM Library fuer grafische objekte

   * Graphisches Resultat sichtbar
   * sehr einfache Programme waren am "coolsten"
   * grafische Herangehensweise fuehrt zu kreativem Umgang
       * ueber Aufgabe hinaus
       * library weiter erforschen
       * Motivationsfoerdernd
       * kann aber auch einschuechternd wirken (depends on library)

1. 1. Cheat sheet fuer Programmierkurse?

• TU Darmstadt ist dabei, so etwas zu entwickeln

   * Link folgt [hier]
   * (Wenn ich das bis zur naechsten KIF nicht gemacht haben sollte erinnert mich dran, Viele Grueße Kevin)