Vorläufiger Abschluß-Post meiner Erkundung der Software Craftsmanship Community im Rahmen des Projektes MeinZiel23 der Corporate Learning Community.
Ein erster Kontakt 2019 mit Andy Fischer, dem Gründer der DATEV Software Craftsmanship Community, hat mich neugierig gemacht. Da treffen sich Softwareentwickler aus eigenem Antrieb um sich weiterzuentwickeln – ohne Zertifikate, und ohne Registrierung der Teilnahme. Ein Gespräch mit Jürgen Latteyer beim Corporate Learning Camp CLC22 Herbst hat mich dann dazu gebracht, mir die Software Craftsmanship Bewegung im Rahmen des #MeinZiel23 Projektes näher anzuschauen. Hier mein Ergebnis.
Ursprung der Software Craftsmanship Bewegung
Das Agile Manifest wurde 2001 veröffentlicht. Den Softwareentwicklern fehlten darin Aussagen zur Qualität: Auch schlecht gemachte Software kann agil entstehen. Die “Clean Code” Idee zu gut erstelltem Code wurde 2008 durch ein gleichnamiges Buch bekannt. Ein Jahr später entstand das Software Craftsmanship Manifest, dass im Einleitungssatz den Inhalt schön zusammenfasst:
“Als engagierte Software-Handwerker heben wir die Messlatte für professionelle Softwareentwicklung an, indem wir üben und anderen dabei helfen, das Handwerk zu erlernen.”
2009 folgte gleich die erste Software Craftsmanship Konferenz. Im gleichen Jahr wurden erste Software Craftsmanship Communities außerhalb der USA gegründet. Die Bewegung entwickelt sich weltweit. 2011 läuft in Deutschland die erste SoCraTes-Un-Konferenz. Dort wurde auch die Softwerkskammer gegründet, die heute von vielen regionalen Software Craftsmanship Communities im DACH-Raum getragen wird.
Die ganze Historie der Software Craftsmanship Bewegung in diesem Blogpost.
Idee der Software Craftsmanship Bewegung
Leitgedanke ist die gute, stolz machende Arbeit, der gut gemachte Code. Dabei orientiert man sich an den alten Handwerks-Zünften, die ihre Gesellen 2 bis 5 Jahre auf Wanderschaft schickten, damit sie bei verschiedenen Meistern neues Können erlernen – und dabei ihr Wissen und Können an den anderen Stationen weitergeben. Das Lernen von- und miteinander ist die zentrale Idee. Einerseits um damit individuell immer besser zu werden, und andererseits um die Softwareentwicklungs-Branche weiterzuentwickeln.
Besonders ist hier die absolute Freiwilligkeit: Nur wer aus eigenem Antrieb mitmachen will, ist dabei. Es gibt nicht einmal irgenwelche Teilnahme-Bestätigungen und auch keine Zertifikate. Dabei treffen sich die Software Crafter – oft außerhalb der Arbeitszeit – bei verschiedenen Übungsformaten. “Gebt den Leuten Zeit zum Üben, sonst üben sie im echten Projekt!” ist ein häufiges Zitat. Übungsformate werden bewusst mit unterschiedlich erfahrenen Software Craftern durchgeführt. Die Erfahrenen helfen den Neulingen im jeweiligen Thema ganz selbstverständlich. Es entsteht eine Gemeinschaft von Software Craftern, die alle weiterbringt – und den Beteiligten sogar Spaß macht.
Mehr über Idee der Software Craftsmanship Bewegung in diesem Blogpost und im Blogpost zum Buch „The Software Craftsman“.
Träger der Software Craftsmanship Bewegung
Die höchste Organisationsstufe sind in Deutschland die Softwerkskammern, hier beschrieben. Dahinter steht nicht einmal ein Verein. Das ist ein vollkommen selbstorganisiertes Netzwerk, das von vielen ehrenamtlich getragen wird. Für die vielen Veranstaltungen finden sie immer Sponsoren, die Räume und evt. auch das Catering stellen.
Auch international scheint es ein ehrenamtliches Netzwerk zu sein.
Übungs- und Lernformate der Software Craftsmanship Communities
Code Katas, Coding Dojos, Code Retreats sind drei typische Lern- und Übungsformate für Software Crafter.
Code Katas sind kleine Programmieraufgaben, die wiederholt ausgeführt werden um das Handwerk als Softwareentwickler zu beherrschen. Das kann man allein machen, oder auch in einer Gruppe.
Coding Dojos sind so etwas, wie Übungsräume für Software Crafter. Jemand stellt Aufgaben, die man gemeinsam löst. Oft als “Pair-Programmer”, also jeweils zwei erstellen Code an nur einer Tastatur. Dabei kann man das Lernen voneinander gar nicht vermeiden.
Code Retreats erlauben eine großen Zahl an Teilnehmenden, z.B. wieder in Zweier-Teams für eine gegebene Aufgabe Code zu erstellen. Nach 45 Minuten wird abgebrochen, und es gibt Zeit sich über die Erkenntnisse zu unterhalten. Danach wird der Code gelöscht, und die Zweier-Teams werden neu gemischt. Wieder die gleiche Aufgabe, wieder der Austausch über das Gelernte, wieder wird der Code gelöscht – und das 5 bis 6 mal am Tag. Einerseits übt man damit intensiv, andererseits lernt man von den verschiedenen Arbeitspartnern sehr viel. Und außerdem baut man sein persönliches Netzwerk damit aus. Wo ginge das besser als beim gemeinsamen Arbeiten?
Alle Infos zu den Lernformaten in diesem Blogpost.
Das Software Craftsmanship Manifest
Wie oben beschrieben entstand das Software Craftsmanship Manifest nach dem agilen Manifest. Der Schwerpunkt beim Software Craftsmanship Manifest liegt auf guter Arbeit, also bei gut geschriebenem Code. Das wird gleich verbunden mit stetiger Entwicklung jedes Einzelnen – und damit der ganzen Branche.
“Die Messlatte anheben …” und “üben und anderen dabei helfen das Handwerk zu erlernen” sind die Kernaussagen schon des einleitenden Satzes. Darum geht es im Software Craftsmanship Manifest, das ausführlich in diesem Blogpost beschrieben ist.
Obwohl das Manifest nur 4 Punkte enthält, trifft man immer wieder auf eine treffende und viel kürzere Darstellung der Software Craftsmanship Grundhaltung:
We care, we learn, we practice, we share
Die Reihenfolge variiert zuweilen, dennoch treffen diese Aspekte nicht nur auf Software Crafter zu. Sie wären in jeder Branche eine gute Orientierung!
(Hier die Version von Doug Bradbury, aufgeschrieben von Markus Gärtner.)
Die folgende Reihenfolge und die Erklärungen stammen von Jason Gorman (vom 8.4.2009) (hier frei übersetzt):
We care
„Wir achten auf die Qualität unserer Arbeit. Sie sollte so gut sein, wie es uns möglich ist.“
We learn
„Wir lernen aus unseren Fehlern, wir lernen von den Beispielen anderer. Wir lernen aus Büchern, Blogs, Webinaren und aus allen möglichen Quellen. An guten Beispielen lernen wir besser. Deshalb sind gute Einfüsse wichtig. …“Wir lernen aus unseren Fehlern, wir lernen von den Beispielen anderer. Wir lernen aus Büchern, Blogs, Webinaren und aus allen möglichen Quellen. An guten Beispielen lernen wir besser. Deshalb sind gute Einfüsse wichtig. …“
We share
„Wir teilen, was wir gelernt haben. Das ist die andere Seite der Learning-Medaille. Wer schreibt die Blogs, erstellt die Screen-Shots und das was anderen hilft? Wir tun es, oder?
Wir alle sind gleichzeitig Meister und Lehrlinge, Lehrer und Schüler, Mentoren und Mentees, Coaches und Coachees.“
We practice
„Am wichtigsten ist – und das bestimmt die ganze Bewegung so weit ich es sehe – wir lernen beim Tun. Wir ÜBEN. Kontinuierlich. Wie ein Athlet oder ein Pianist oder ein Zirkus-Clown oder ein Löwen-Bändiger. Wir wissen dass das, was wir Wissen und anwenden müssen, weit mehr ist, als wir bewusst anwenden können. Wir müssen unser Wissen verinnerlichen und wir müssen unsere “Software Development Muskeln” trainieren, und die notwendigen Reflexe und das “Muskel-Gedächtnis”, das wir benötigen als produktive Programmierer.
Deshalb denke ich, wir lagen falsch in den letzten Jahren. Wir haben Sofwareentwicklung als geistige Disziplin verstanden. Man kann nicht Meister werden, durch das Lesen von Büchern oder dem Beobachten, wie Andere es tun. Das ist Quatsch. Man kann auch keine Fähigkeit wie “Refactoring” meistern, durch Lesen eines Buches. So wie man auch nicht Fahrrad fahren lernt durchs Lesen der Bedinungsanleitung. Das braucht Übung. Viel, sehr viel Übung. Gute Übung. Konzentrierte Übung. Übung mit Fortschrittsmessung.“
Fazit
Meine anfängliche Faszination und Hochachtung ist beim Erkunden der Software Craftsmanship Community sogar noch gestiegen. Hier verbinden sich Softwareentwickler vollkommen freiwillig zum gemeinsamen Wachsen. Immer mit dem Ziel wirklich gute Arbeit leisten zu wollen. Das stetige Lernen finden sie selbstverständlich. Das Teilen ihres Wissens auch. Und ein großer Anteil ihres persönlichen Entwicklungsweges besteht aus Üben!
Meine Erkenntnisse daraus:
- Das Üben haben wir aus fast allen Weiterbildungen völlig ausgeklammert. Warum eigentlich? “Gebt den Leuten Zeit zum Üben, sonst üben sie im echten Projekt” – der Spruch passt in allen Branchen.
- Software Crafter nehmen ihre Entwicklung selbst in die Hand. Wenn die Firma das unterstützt, dann ist es schön. Wenn nicht, dann sorgen sie außerhalb der Dienstzeit für ihre Entwicklung. Das ist eine Umkehrung der in Deutschland weit verbreiteten Idee der Bringeschuld des Arbeitgebers für die Mitarbeiterentwicklung.
- Selbstgesteuertes und oft gemeinsames Lernen ist in der Software Craftsmanship Community üblich. Die Übungs- und Lernevents sind ehrenamtlich organisiert. Jeder entscheidet selbst, wo und wie weit er sich einbringt. Es geht ums persönliche Lernen. Nachweise sind da nicht nötig. Zertifikate und Teilnahme-Bescheinigungen gibt es nicht. Gemeinsames Lernen ist üblich.
- Diversität wird gelebt. Jeder darf zu den Veranstaltungen kommen – egal welchen Kenntnis-Level man hat. Unterschiedliche Kenntnisse sind sogar erwünscht. Jeder ist mal Lehrender und mal Lernender.
- Pragmatismus herrscht. Von niemandem wird Perfektion verlangt. Jeder soll im Job das anwenden, was er gut kann. Und nebenbei permanent weiterlernen. Den perfekten Software Crafter gibt es nicht.
- Software Craftsmanship Community stärkt. Die eigene Entwicklung gestaltet man eher mit der Community, als allein oder mit dem Arbeitgeber.
- Lern- und Arbeitsformate: “Pair-Programming” (zwei coden an einer Tastatur) ist eines der Beispiele für die Wieder-Verbindung von Arbeiten und Lernen. Wenn zwei ihre Ideen für die gleiche Aufgabe einbringen, ist Lernen gar nicht zu vermeiden. Und in Übungsevents, z.B. Code Retreats, wird gemeinsam “gearbeitet”. Auch deshalb sind die Lern- und Übungsevents der Software Craftsmanschip-Community gute Vorbilder.
Test Driven Development (TDD): Bevor eine Zeile Code geschrieben wird, schreibt man den Test für diese Funktion. Damit schafft man sich einerseits kleinteilige Ziele, und andererseits Prüfkriterien fürs Erreichen dieser Ziele. So ein Vorgehen ermöglicht schnelle Learnings.
Meine nächste Frage
Wie können wir diese „Lern- und Arbeitskultur“ auf uns Learning Professionals übertragen? Wir reden immer von selbstgesteuerterm Lernen. Hier hat es ein ganze Berufsgruppe aus sich heraus entwickelt und vorbildich gestaltet.
