Vor einiger Zeit stellte mein Kollege Olav Maassen auf der Mailingliste unseres Unternehmens die Frage nach dem besten Buch, das man lesen sollte, um die OSx-Entwicklung zu lernen. Seine Frage brachte mich dazu, nicht über das beste Buch nachzudenken, sondern darüber, wie ich in der Vergangenheit neue Programmiersprachen gelernt habe.
Meine erste Programmiersprache war 6810-Assembler (OK, das war die zweite, die erste war Commodore 64 Basic, aber ich bestreite, dass ich das jemals gelernt habe). Alles, was ich hatte, war ein Referenzhandbuch, einen Nadeldrucker (30 Zeichen/Sekunde), ein weitaus besseres Gedächtnis (das ist wichtig, weil IDEs erst vor kurzem den Kampf gegen meine nachlassenden Gehirnzellen gewonnen haben) und ein binäres Feedback einer Zeitschrift auf meinen Vorschlag für einen Artikel ('Nein danke'). Und jede Menge Zeit im Alter von 13 Jahren. Also musste ich ohne wirklich feinkörniges Feedback durch Versuch und Irrtum lernen.
Weiter zur Universität und Pascal als meine Hauptprogrammiersprache, um kleine Probleme in einer Gruppe von Studenten zu lösen. Das Feedback war minimal ('ja, es kompiliert') und in Form einer ganzen Zahl zwischen 0 und 10 einschließlich ('Ihre Note ist eine 6'). In diesem Fall lernten wir vor allem voneinander, denn die Bücher waren voll von Theorie über die Programmierung für akademische Probleme (was haben Sie von einer Universität erwartet...), aber nicht (zumindest hatte ich das Gefühl) über die Erstellung von etwas, das tatsächlich funktioniert.
Mein erster richtiger Job war die Entwicklung von Software in Oracle Forms and Reports in kleinen Teams. Wir hatten eine Kombination aus Ad-hoc-Peer-Reviews ('Jan, dieser Code ist wirklich mies, geh und verbessere ihn') und strukturierten Code-Walks mit einem Auditor, der für die Qualitätsabteilung arbeitete. SQL war ein großer, aber leicht zu bewältigender Paradigmenwechsel vom prozeduralen Pascal. Ich erinnere mich an wochenlange Schulungen in der Oracle-Zentrale in den Niederlanden, die von begeisterten Trainern durchgeführt wurden. Hier gab es keine Theorie, nur Tricks.
Das Ende der neunziger Jahre bedeutete für mich Java und Webtechnologien. Wir begannen mit knappen Fristen und kaum Rückmeldungen ('Ja, es lässt sich kompilieren'), und es gab keine andere Tool-Unterstützung als eine klobige Version dessen, was später zu Eclipse mutierte. Wir lernten das Handwerk von einem britischen Unternehmen, das uns auf der Lernkurve ein paar Wochen voraus war.
Erst vor kurzem habe ich mich an Pair Programming, Test-First-Development und rigorose Qualitätssicherung in Form von Peer Reviews gewöhnt ('Jan, dieser Code ist wirklich scheiße, geh ihn korrigieren'). Die Komplexität von OO-Systemen und der Plattform, auf der sie eingesetzt wurden und werden, ist weitaus größer als die Komplexität eines terminal- und datenbankbasierten Systems. Das erfordert bessere Qualitätsmaßnahmen und verlangsamt die Lernkurve.
Mein letzter Versuch, sekundäre Gehirnzellen in den aktiven Dienst zu zwingen (um die zu kompensieren, die den Kampf gegen Alkohol und altersbedingte Abnutzung verloren haben), ist das Erlernen von Scala und funktionaler Programmierung. Ohne die Strenge eines Projektteams müssen Sie etwas tun, um sicherzustellen, dass Sie lernen, die Werkzeuge so zu verwenden, wie sie verwendet werden sollen. Xebia bietet eine hervorragende Umgebung, um Faulheit und zweifelhafte Qualitätsstandards zu vermeiden. Ich nutze Peer-Reviews (um über das Design zu diskutieren) und Pair Programming (um über die Codequalität zu diskutieren, 'Oh, aber es gibt einen viel besseren Weg, dieses Problem zu lösen'), um wieder zu lernen.
Ich lese zwar Bücher (z.B. Martin Oderskys frühes Buch über Scala), aber ich lasse mich leicht ablenken oder bin einfach zu neugierig, so dass ich anfangen muss zu experimentieren. Learning by doing funktioniert bei mir besser als ein Buch zu lesen, aber wenn ich meine alten Gewohnheiten ablegen will, brauche ich Kollegen, die wissen, wie man Feedback gibt. Code-Reviews und Pair Programming helfen mir am besten, schnell zu lernen.
Verfasst von

Jan Vermeir
Developing software and infrastructure in teams, doing whatever it takes to get stable, safe and efficient systems in production.
Contact
Let’s discuss how we can support your journey.