Neues Lernen

Aber wie?

Praktisch täglich stosse ich auf ein Problem, das ich einfacher lösen könnte, wenn ich dazu die entsprechenden Fähigkeiten hätte. Diese Probleme sind teilweise sehr konkret (z.B. die Suche nach einer Library-Funktion mit einer bestimmten Semantik) und teilweise sehr abstrakt (z.B. wie man die Qualität seines Programmcodes verbessern kann, sodass bei Anpassungen keine Fehler miteingebaut werden). Die Probleme haben gemeinsam, dass man sie besser lösen könnte, würde man vorher die entsprechenden Fähigkeiten dazu lernen.

Im Alltag wird das konkrete Problem meistens mithilfe einer kurzen Internetrecherche gelöst, wobei von der Lösung oftmals wenig hängen bleibt, und man das gleiche Problem später erneut lösen muss. Der Lerneffekt bleibt praktisch aus. Das abstrakte Problem wird oftmals gar nicht angegangen, doch regt man sich später wieder darüber auf, dass man in der Zwischenzeit die Chance zur persönlichen Weiterentwicklung nicht wahrgenommen und nichts dazugelernt hat.

Konkrete Probleme erfordern oftmals eine Lösung, die sehr kurzfristig erreichbar ist. Der Lerneffekt steht dabei eher im Hintergrund. Abstrakte Probleme müssen zunächst konkretisiert werden, damit man sich überhaupt an deren Lösung machen kann, was mehr Zeit erfordert. Will man abstrakte Probleme in Zukunft besser lösen können, muss das Lernen systematisch und über eine längere Zeitspanne erfolgen.

Mich beschäftigen derzeit folgende Probleme:

• kurzfristig: Was sind die Vor- und Nachteile von git merge gegenüber von git rebase?
  • Diese Problematik möchte ich gerne für mich selber verstehen, aber auch meinen Schülern im Berufsschulunterricht näherbringen.
• mittelfristig: Wie entwickelt man Web-Frontends mit TypeScript und Angular?
  • Mit diesen Technologien werde ich voraussichtlich in der nächsten Zeit Projekte umsetzen.
• langfristig: Wie kann man produktive Software mit Haskell entwickeln?
  • Ich möchte die Qualität meines Programmcodes erhöhen, sodass gewisse Arten von Fehlern darin nicht mehr auftauchen.

Zu lernen gibt es also genug. Die Motivation für diese Lernprojekte dürfte auch geklärt sein, wobei sie bei kurzfristigen Problemen sicher besser greifbar ist als bei langfristigen. Es fragt sich also, wann der Lernprozess stattfinden soll, aber auch womit.

Kurzfristige Probleme sollte man so früh wie möglich angehen. Diese sind dann auch recht schnell gelöst. Wichtig ist, dass man das Gelernte für später festhält. Hierzu hat sich bei mir ein Repository für Dokumentation bewährt. Da es öffentlich verfügbar und einigermassen aufgeräumt ist, verwende ich dieses immer dann anstelle einer Internetrecherche, wenn ich das Problem schon einmal gelöst habe.

Für mittelfristige Probleme muss man sich Zeit einplanen. Hier ist Timeboxing hilfreich, oder die Arbeit mit einem Accountability Partner bzw. in einer Lerngruppe. Ich bin Teil einer LPIC-1-Lerngruppe, die sich jeden Montag online trifft und eine oder zwei Lektionen gemeinsam durchgeht. Hierbei ist es wichtig, dass man sich auf ein Lehrmittel einigt; in unserem Fall sind es die offiziellen LPIC-Lehrmittel. Für Angular fehlt mir derzeit sowohl das soziale Setting als auch ein Lehrmittel, das mich begeistern würde.

Bei längerfristigen Projekten war ich in meinem Leben bisher nur selten erfolgreich. Zwar habe ich schon einige Ausbildungen abgeschlossen, doch diese decken sich nur selten mit meinen langfristigen persönlichen Zielen. Ein Teilerfolg war das (teilweise) Durcharbeiten von SICP. Zwar habe ich von den fünf Kapiteln nur (knapp) drei durchgearbeitet, ich habe aber während fast neun Monaten ausnahmslos jeden Tag damit gearbeitet, i.d.R. als erste Beschäftigung des Tages (nach der Zubereitung eines Kaffees). Hier war nicht nur meine Motivation hoch ‒ nach mehreren abgebrochenen Versuchen mich mit der funktionalen Programmierung zu befassen ‒ sondern auch das Lehrmittel ausgezeichnet.

Bei Haskell habe ich derzeit weniger Erfolg. Programming Haskell ist mir zu dicht, Effective Haskell zu aufgebläht und Haskell in Depth erfordert mehr Grundlagenwissen, als ich es derzeit mitbringe. Thinking Functionally in Haskell scheint mir jedoch ein guter Zwischenschritt zu sein, bevor ich es erneut an Haskell in Depth versuche.

Aus meinen Teil- und Misserfolgen leite ich folgende Erkenntnisse ab:

• Langfristige Lernprojekte müssen höher getaktet bearbeitet werden als kurz- und mittelfristige.
  • Ein kurzfristiges Problem wird meistens durch einen einmaligen, konzentrierten Effort bewältigt.
  • Ein mittelfristiges Problem hingegen muss in grösseren Zeitblöcken bearbeitet werden, damit man auch in nützlicher Frist sein Ziel erreicht. Da man sich grössere Zeitblöcke nur selten freimachen kann, ist eine wöchentliche halbtagweise Bearbeitung des Themas ein guter Kompromiss.
  • An längerfristigen Problemen sollte man täglich arbeiten, damit man sie nicht aus den Augen verliert. Hat man es nach ungefähr einem Monat geschafft, das tägliche Lernen als Gewohnheit zu etablieren und es zum festen Bestandteil seines Tagesablaufs zu machen, muss keine Willenskraft mehr aufgewendet werden, um sich an die Arbeit zu machen. Diese kann man stattdessen für die Bearbeitung des anspruchsvollen (da abstrakten) Themas aufwänden. (Hierzu empfehle ich als Lektüre das erschöpfte Gehirn von Michael Nehls, welcher das Problem der Willenskraft beim Lernen sehr fundiert aufbereitet hat.)
• Möchte man längerfristig etwas lernen, ist nicht nur eine hohe (intrinsische) Motivation ‒ als abstraktes Problem ‒ erforderlich, sondern auch ein passendes Lehrmittel. Passende Lehrmittel in sehr hoher Qualität zu finden erfordert aber manchmal ein längeres Durchprobieren.

Ob mir diese Erkenntnisse beim Lernen von Angular und Haskell helfen werden, wird sich in den nächsten Wochen und Monaten zeigen.