Bearbeiten von „KIF460:Wie lernt man Programmieren (sinnvoll, effizient) ? (Austausch, Brainstorming)“

# Programmieren lernen

## 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

## 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

## 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.

## Welche Sprache?

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


## 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



## 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

## 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

## 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

### 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

## 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

### 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)


## 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)