• Teaser Home

    Clean Code Developer School

    Saubere Softwareentwicklung üben – regelmäßig, fokussiert, individuell, angeleitet

Frühjahrsputz 2016 – Gemeinsam ran an den Schmutz

Der Frühjahrsputz für Wohnung und Körper (Fasten) ist Tradition. Warum nicht diese schöne Tradition auch auf Ihre Codebasis ausdehnen? Dort gibt es sicher auch einige Ecken, die mal entrümpelt werden könnten, oder?

Wenn Sie jetzt denken „Ja, müsste ich mal machen…“, sich aber nicht aufraffen können, dann verstehen wir das allerdings sehr gut. Aufräumen macht irgendwie keine Freude. Oder wenn doch, dann fällt es Ihnen trotzdem wahrscheinlich schwer, dafür einen Termin im Tagesgeschäft zu finden.

Deshalb bieten wir Ihnen an: Wir helfen Ihnen beim Frühjahrsputz!

Gehen Sie Staub, Schmutz, Gerümpel in Ihrem Code nicht allein an. Lassen Sie uns das zusammen machen: „Pair Putzen“ :-) Gemeinsam macht es mehr Freude; zu zweit sieht man auch mehr Schmutzstellen und ein Termin mit jemand anderem wird leichter eingehalten.

Die CCD School Putzhilfeaktion

Ja, Sie haben richtig gelesen: Wir würden Ihnen gern beim Säubern Ihres Codes zur Hand gehen. Sauberer Code, also Clean Code, ist immerhin unser Job ;-)

Und weil die Sonne so schön lacht, die Vöglein so munter zwitschern und die Kirsche schon so hübsch blüht, haben wir uns ein Angebot überlegt, dem kein Schmutz widerstehen kann. Wie bieten…

  • 6 Teams
  • jeweils 3 Termine
  • à 90 Minuten

unsere Hilfe an – und das lediglich zum Preis eines Amazon-Gutscheins, dessen höhe sie selbst am Ende der Putzaktion bestimmen.

So funktioniert’s:

Bewerben Sie sich mit Ihrem Team über das unten stehende Formular, wenn Ihre Codebasis in Java oder C# entwickelt ist. Aus allen Bewerbungen wählen wir 6 aus, denen wir beim Frühjahrsputz jeweils insgesamt 4,5 Stunden beistehen. Diese Zeit verteilen wir allerdings auf 3 online Sitzungen à 90 Minuten. In den Sitzungen arbeiten wir im remote pair via Teamviewer und anderen Werkzeugen zusammen an der realen Codebasis.

Die Sitzungen liegen 1-2 Wochen auseinander, so dass die ausgewählten Teams zwischendurch Zeit haben, mit den Impulsen aus dem „Pair Putzen“ selbstständig weitere Erfahrungen zu sammeln.

Um Ihnen die Bewerbung leicht zu machen, verzichten wir in diesem schönen Frühling auf ein Honorar. Wenn ein Team unsere Unterstützung jedoch als wertvoll empfunden hat, dann freuen wir uns über eine Anerkennung in Form eines Amazon-Gutscheins. Dessen Höhe bestimmt das Team selbst nach Budget und Wertempfinden.

Unsere Motivation

In Zeiten so vieler scheinbar kostenloser Angebote mögen Sie sich fragen, warum wir Ihnen dieses Angebot machen. Der Grund ist einfach: Wir wollen mehr Erfahrung beim Säubern von realem schmutzigem Code machen. In unseren Trainings konzentrieren wir uns bisher auf Clean Code, wollen also Schmutz von vornherein vermeiden. Und Beratungseinsätze bringen uns zwar ans Brownfield, an den Legacy Code, in den Big Ball of Mud – doch da solche Begleitungen länger dauern, gibt es davon nicht so viele verschiedene.

Um in der Vermittlung von Clean Code Prinzipien und Praktiken noch besser zu werden, glauben wir, müssen wir jedoch mehr, viel mehr unsauberen Code sehen. Diese Putzaktion ist ein Versuch, dieses Ziel zu erreichen.

Wir helfen Ihnen beim Reinemachen, Sie helfen uns mit Zugang zu realem Legacy Code. So einfach ist der Deal.

Los geht’s

Wenn Sie Lust auf unsere Unterstützung beim Code-Frühjahrsputz haben, dann füllen Sie das folgende Formular aus. Bewerbungen sind bis zum 20.4.2016 möglich. Selbstverständlich behandeln wir alle Bewerbungen vertraulich und begraben Sie anschließend nicht unter Spam-Emails ;-)

Lernstoff in den Alltag überführen

Wie schaffen Sie es eigentlich, Clean Code Development Praktiken (und damit auch Prinzipien) in Ihren Alltag zu einzubauen? Diese Frage tauchte anlässlich einer Vorstellungsrunde in einem TDD 2.0 Training auf. Ein Teilnehmer sprach nämlich ausdrücklich davon, das sei sein Vorsatz.

Über solchen Vorsatz habe ich mich natürlich sehr gefreut. Doch auf die Frage, wie hoch die Wahrscheinlichkeit sei, dass der Vorsatz auch in die Tat umgesetzt würde angesichts all der Umsetzungs(miss)erfolge mit früheren Vorsätzen… da kam dann leider nur eine Wahrscheinlichkeit von weniger als 50% heraus.

Das wäre aber doch schade, oder? Allemal angesichts der Anfangsinvestition an Zeit und Geld in das Training. Ganz zu schweigen von den nicht realisierten Vorteilen, wenn die Entwicklung anschließend nicht sauberer testgetrieben verläuft.

Aber das ist sicher nicht nur ein Problem dieses Teilnehmers. Im Grunde kämpfen ja alle damit, Lernstoff nach Ende des Trainings im Alltag lebendig zu halten oder gar zu vertiefen und anzuwenden. Wie kann das funktionieren?

Ich denke, es ist für unsere Motivation und unser Selbstvertrauen wichtig, in der Lage zu sein, solch einen Vorsatz verlässlich in die Tat umzusetzen. Er stellt ja ein Versprechen dar, das wir uns (oder gar dem Unternehmen, das ein Training bezahlt) geben. Und versprechen soll(t)en eingehalten werden. Das erhält und schafft Vertrauen mit all seinen guten Effekten.

Deshalb hier zwei Tipps, um es Ihnen leichter zu machen, den Vorsatz umzusetzen, Lernstoff in den Alltag zu überführen.

Nach dem Behavior Grid von BJ Fogg, einem Experten in Sachen Verhaltensveränderung, geht es um ein Green Path Verhalten, d.h. ein neues Verhalten, das Sie von nun an auf unbestimmte Zeit annehmen wollen. Er schreibt dazu:

Green Path Behaviors are the result of three elements: Motivation, Ability, and Triggers. As the Fogg Behavior Model describes, you must Trigger the behavior when the person is both Motivated and Able to perform it. The specific steps: 1. Boost motivation (if needed), 2. Enhance ability by making the commitment act simple, 3. Issue the trigger when #1 and #2 are in optimal states.

BJ Fogg Behavior Grid

Nicht zu viel vornehmen

An Motivation wird es Ihnen nicht fehlen. Sie haben sich ja gerade freiwillig mit einem spannenden Lernstoff auseinandergesetzt und suchen nach einem Weg, Ihre hohe Motivation möglichst verlustfrei in eine bleibende Veränderung zu transformieren.

Deshalb ist die erste Frage nach BJ Fogg, wie Sie Ihre „ability“ erhöhen, eine neue Verhaltensweise an den Tag zu legen. Beispiel: Im TDD 2.0 Training haben Sie die Methoden „TDD as if you meant it“ und „Informed TDD“ kennengelernt – und dennoch fehlt Ihnen noch etwas. Das ist die Fähigkeit (ability), das Gelernte jeden Tag einzusetzen.

BJ Fogg schreibt dazu:

Increase the perceived ability (self-efficacy) by making the behavior easier to do

Sie müssen also einen Weg finden, um den Lernstoff einfach in den Tag zu integrieren.

Das kann auf zwei Wegen geschehen:

  • Sie nehmen sich vor, (zunächst) nicht alles, sondern nur einen Teil anzuwenden. Sie reduzieren also den Umfang. Konzentrieren Sie sich z.B. auf nur eine der beiden erlernten obigen Methoden.
  • Sie nehmen sich vor, (zunächst) nur eine sehr kurze Zeit pro Tag oder Woche mit dem Lernstoff zu verbringen. Dieser Zeitraum sollte so kurz sein, dass es Ihnen keine Schmerzen bereitet, ihn wirklich regelmäßig im Tag bzw. in der Woche freizuräumen für den Lernstoff.

Damit erreichen Sie, dass Sie sich nicht zu viel vornehmen, sich nicht überfordern. Gehen Sie lieber in kleinen, dafür verlässlich Schritten vor – statt dass Sie mit großen Sprüngen anfangen, die Sie schnell ermüden oder mit einer organisatorischen Wand kollidieren lassen.

Wenn Sie sich für jeden Tag etwas vornehmen, scheinen mir 15 Minuten (ca. 3% Ihrer Zeit/Tag) die maximale Zeitspanne, die Sie dem Neuen widmen sollten. Natürlich wären 30 Minuten oder gar 45 oder 60 noch besser, doch bleiben Sie realistisch. Freuen Sie sich lieber auf garantierte, einfach einzuplanende 15 Minuten, als dass Sie immer wieder um größere Zeitspannen ringen müssen. (Sie können die Zeitspanne ja auch jederzeit verlängern, wenn Sie merken, dass die Regelmäßigkeit kein Problem darstellt.)

Falls Sie sich aber nicht jeden Tag, sondern nur wöchentlich mit dem Neuen beschäftigen können/wollen, dann empfehle ich max. 120 Minuten pro Woche (5% Ihrer Zeit/Woche) einzuplanen. Längere Zeit können Sie sich kaum am Stück zurückziehen.

Wie gesagt, am wichtigsten ist, dass Sie sich verlässlich Ihrem Lernstoff widmen. Das tun Sie aber nur, wenn die Organisation der dafür notwendigen Zeit, ein no brainer für Sie ist. Sich die Zeit zu nehmen, muss schmerzfrei bis schmerzarm sein. Darauf dürfen Sie keine Energie verwenden müssen, sonst laugen Sie sich aus – und andere Dinge, die weniger Energie erfordern, nehmen diesen Raum wieder ein.

Was Sie übrigens mit dem (reduzierten) Lernstoff in der (kurzen) Zeitspanne tun, ist Ihnen überlassen. Sie können ihn einfach lernend vertiefen und üben. Oder Sie können ihn schon im Projekt anwenden. Vermeiden Sie in beidem Überforderung.

An ein bestehendes Verhalten knüpfen

Der Raum, den das Neue einnimmt, sollte also (zunächst) nur klein sein. Aber wo sollte dieser Raum liegen?

Im Kalender verankern

Wenn Sie schon ein funktionierendes Zeitmanagement haben, dann platzieren Sie den Zeitraum für die Beschäftigung mit dem Lernstoff einfach im Kalender. So gewährleisten Sie, dass Sie das Thema im Tagesstress nicht vergessen. Sie behandeln es dann wie jeden anderen „offiziellen Termin“. Und so sollte es auch sein. Lernen ist nicht weniger wichtig als ein Meeting oder die Abgabe eines Berichtes, die ebenfalls im Kalender stehen.

Allemal mit einer wöchentlichen Lernphase lohnt sich der Eintrag im Kalender. Das muss ja nicht sklavisch immer am selben Tag und zur selben Zeit sein. Diese Woche Mittwoch vormittag, nächste Woche Donnerstag nachmittag usw. ist völlig ok.

Blocken Sie Lernzeiten! Sie sollten first class citizens in Ihrem Kalender sein.

An eine Gewohnheit knüpfen

Für kurze tägliche Lerneinheiten hingegen mag ein Kalendereintrag zu umständlich/schwergewichtig sein. 15-20 Minuten können Sie auch ohne einschieben. Aber wie erinnern Sie sich daran? Indem Sie den Raum fürs Lernen an einen schon bestehenden Raum anschließen.

Ihre Tageszeit ist aufgeteilt in größere und kleinere Räume. Insbesondere wenn Sie die verlassen besteht eine gute Chance, dass Sie einen anderen als üblichen Weg einschlagen. Schließen Sie das Lernen als bereichernden kleinen Umweg an etwas an, was Sie ohnehin jeden Tag garantiert tun. Beispiel:

  • Sobald Sie morgens den Rechner hochgefahren haben, widmen Sie sich als erstes für 15 Minuten dem Lernstoff. Wäre das nicht ein guter Start in den Tag?
  • Wenn Sie mittags vom Essen kommen, überwinden Sie das „Suppenkoma“ mit 20 Minuten Lernzeit. Das macht mehr Spaß als gleich wieder ans Bug Fixing zu gehen.
  • Jeden Tag nach dem Daily Standup konzentrieren Sie sich zuerst 15 Minuten auf den Lernstoff, bevor Sie mit der Projektarbeit loslegen.

Sie haben sicher noch mehr und andere Gewohnheiten, an die Sie das Lernen binden können. Nehmen Sie sie als automatische Erinnerungen während des Tages, den Lernstoff nicht aus den Augen zu verlieren.

Je kürzer der Zeitraum für das Lernen ist, desto besser muss natürlich die Vorbereitung sein, den Lernstoff wieder aufnehmen zu können. Machen Sie Lesestoff griffbereit (als Buch mit Lesezeichen oder als Link in einer Leseliste), legen Sie ein eigenes Repository mit passenden Projekten an, legen Sie sich eine klare Aufgabe zurecht (z.B. als Link zu einer Kata im Coding Dojo).

Nicht alleine lernen

Abschließend noch die Empfehlung: Lernen Sie nicht allein. Es ist so viel leichter, mit anderen zusammen zu lernen. Damit meine ich nicht, dass Sie ständig diskutieren müssen. Nein, es geht nur darum, die Absicht und auch die Zeit mit anderen zu teilen. Dadurch überwinden Sie eher den inneren Schweinehund. Außerdem ist es leichter, gegen äußere Widerstände den Vorsatz durchzusetzen.

Das wöchentliche Lernen bietet sich für ein Lernen in der Gruppe an. Alle ziehen sich dann – wie im Kalender verabredet – zusammen in einen Raum zurück. Das schafft eine konzentrierte Atmosphäre.

Aber auch tägliches Lernen lässt sich mit anderen organisieren. Wenn das nicht die Kollegen sind, dann vielleicht „Freunde in der Cloud“? Mit Apps wie coach.me ist das sehr einfach möglich – und Ihnen wird auch noch digital geholfen, bei der Stange zu bleiben.

Sollte das nicht funktionieren, hilft ein Accountability Partner, mit dem Sie in 1-2 Wochen Abstand Ihre Erfolge, Strategien, Ziele besprechen können. Sie glauben gar nicht, wie hilfreich solche Gespräche sein können, um Vorsätze systematisch umzusetzen. Ein „Gewissen auf zwei Beinen“ wirkt Wunder, wenn Sie meinen, es aus eigener Kraft nicht zu schaffen.

 

Sie sehen: Vorsätze in die Tat umsetzen ist möglich. Je kleiner zunächst der Aufwand, desto höher die langfristige Erfolgswahrscheinlichkeit. Nehmen Sie sich also nicht zu viel vor. Aber nehmen Sie sich ein bisschen vor – und fangen Sie einfach an und machen dann weiter und weiter und weiter… ;-)

Kommunikation zwischendurch mit Slack

Im Präsenztraining, wenn also Trainer und Teilnehmer co-located sind, findet die Kommunikation natürlich vor allem mündlich statt. So sind Geschwindigkeit und Bandbreite maximal. (Zusätzlich kommen auch Code und Tafelbild zum Einsatz.)

Darüber hinaus gibt es dann noch Kommunikation per Email, um einmalig Unterrichtsmaterialien zu verteilen oder mehrfach Hausaufgaben „einzusammeln“.

Das passt erstmal so und ist ganz natürlich. Doch immer wieder haben wir festgestellt, dass es eine Lücke gibt. Mündliche synchrone Kommunikation ist wunderbar in vielen Fällen, schriftliche asynchrone „langlaufende“ Kommunikation per Email ist auch wunderbar in anderen Fällen.

Dazwischen gibt es jedoch noch Fälle, die nach einer „kleinen schriftlichen Kommunikation zwischendurch“ rufen. Beispiele:

  • Der Trainer zeigt eine Aufgabe aus dem Coding Dojo und will den Link allen Teilnehmern zur Verfügung stellen, damit sie auf ihren Rechnern den Text selbst durchblättern können.
  • Ein Teilnehmer recherchiert für die anderen zu einem Thema und will das Ergebnis kurz allen mitteilen.
  • Zu einer Aufgabe soll ad hoc eine Beispieldatei allen Teilnehmern zur Verfügung gestellt werden.
  • Nach dem Training hat ein Teilnehmer eine Frage.

Natürlich lassen sich diese Fälle mit Email bestreiten. Doch das ist irgendwie umständlich. Alle Teilnehmer in die Adressliste eintragen ist nervt, dann fehlt womöglich eine Email-Adresse, die Email landet bei einem Teilnehmer im Spam oder wird von einer wohlmeinenden Server-Policy wegen eines Anhangs blockiert usw. usf.

Email ist schlicht für manche Kommunikationsfälle zu schwergewichtig und zu wenig „dokumentenorientiert“.

Slack to the rescue

Deshalb führen wir bei der CCD School nun den Teamchat mit Slack ein. Slack hat sich seit Jahren für die interne Kommunikation in vielen Projekten bewährt. Nun wollen wir davon auch bei Trainings profitieren.

Jeder Trainingsteilnehmer wird zu einem Slack-Team für alle Trainings der CCD School eingeladen.

In diesem Team gibt es für jedes Training einen privaten Channel. Der ist für die broadcast Kommunikation zwischen den Teilnehmern. Darin können Links und andere Ressourcen gepostet werden; er ist das Medium für Diskussionen – bis es günstig ist, sie in einem anderen Medium weiterzuführen.

Zusätzlich gibt es direkte „Drähte“ zu jedem Teilnehmer (private chat) und es können Chats für Kleingruppen angelegt werden.

Einen Moment haben wir darüber nachgedacht, wie es ankommen mag, dass in diesem Team alle Trainings zusammenlaufen, also sowohl offene wie inhouse. Könnte sich da nicht ein Kunde in seiner „Privatsphäre“ verletzt fühlen?

Theoretisch könnte das sein. Doch wir halten den Fall für sehr selten, so dass wir nicht vorzeitig für ihn optimieren wollen. Sollte er eintreten, schauen wir, wie wir dann damit umgehen. Einstweilen wollen wir jedoch alle Teilnehmer und Kunden motivieren, das einheitliche Team als Chance zu sehen.

Dass ein Unternehmen ein Training durchführt, ist ja auch nicht unmittelbar sichtbar. Jeder Teilnehmer sieht nur die Channels, denen er zugeordnet wird. Lediglich über die Liste aller Mitglieder im Slack-Team ist mit einigen Klicks feststellbar, wer insgesamt dabei ist. Je mehr das dann allerdings sind, desto weniger ist klar, ob sie an einem inhouse oder offenen Training teilnehmen/teilgenommen haben und wann das war. Dass daraus Spam entsteht, ist kaum zu erwarten.

Also sind die Chancen durch eine wachsende Community an Trainingsteilnehmern einstweilen größer als sehr unwahrscheinliche nachteilige Effekte.

Mit jedem Teilnehmer mehr in dem Slack-Team vergrößert sich nämlich die Community derer, die sich mit dem Thema Clean Code Development im Allgemeinen und unserem Lehrstoff im Konkreten beschäftigen. Wer eine Frage hat, hat hier über den Channel #general also eine wachsende Zahl Ansprechpartner jenseits des Kreises seiner Trainingskollegen.

Andererseits können alle von Antworten auf Fragen von einzelnen profitieren, selbst wenn die in einem privaten Channel gestellt worden sein sollten. Denn wenn wir finden, dass eine Antwort von allgemeinem Interesse ist, dann können wir sie (zusammen mit der Frage) in #general posten.

Slack ist unserer Erfahrung nach ein sehr unkompliziertes Werkzeug für die „kleine asynchrone Kommunikation zwischendurch“. Hier lassen sich kurze Mitteilungen verschicken, aber genauso Dokumente „für die Ewigkeit“ hinterlegen.

Slack wird unsere Kommunikation im Training und außerhalb flüssiger gestalten. Darauf freuen wir uns.

 

P.S. Achja, da ist natürlich noch die zu erwartende Klage „Muss denn ein weiteres Tool sein? Haben wir nicht schon genügend am Start?“

Darauf eine Antwort in zwei Teilen:

  • Nein, wir haben noch nicht genügend Tools am Start, wenn diese Kommunikationsfälle noch nicht durch sie abgedeckt sind. Ob man dann Slack oder HipChat oder etwas anderes benutzt, ist natürlich egal. Wir haben uns für Slack entschieden, weil… weil es irgendwie bisher das kleinste Übel war ;-)
  • Slack-Clients gibt es für den Desktop und den Browser. Man kann installieren, muss aber nicht. In jedem Fall ist das in einer Minute getan, sollte also für gestandene Entwickler kein Drama sein. Wer Slack außerhalb des Trainings nicht nutzen will, muss den Client nicht offen haben. Über Email-Benachrichtigungen kann man auf dem Laufenden bleiben, ob sich etwas in den Kanälen getan hat, so dass man nur bei Bedarf das Tool wieder anwerfen muss.

Angesichts der Einfachheit und Nützlichkeit von Slack glauben wir, dass der kleine Mehraufwand sich mehr als lohnt.

Und vielleicht lernt der eine oder die andere es ja auch genauso schätzen wie wir ;-) Etwas Neues muss ja nicht gleich nachteilig sein, oder?

Die Flexibilität, sich leicht auf Slack einzulassen, könnte sogar ein Zeichen dafür sein, bereit für echtes Clean Code Development zu sein. Denn dabei geht es auch um flüssige Reaktion auf Neues und Weiterentwicklung. Clean Code Development beginnt im Kopf!

Lernen mit Tagebuch

Regelmäßig lernen ist wichtig. Dabei hilft Begleitung bzw. Feedback von außen. Dafür sind wir als Trainer der CCD School gerne da. Allerdings können wir ja nicht bei jedem Lernschritt neben Ihnen sitzen. Das skaliert nicht, wäre zu teuer und muss auch nicht sein.

Lernen für sich oder in kleiner Gruppe ohne Betreuung hat nämlich auch seinen Vorteil. Sie können dann mehr in Ihrem Tempo fortschreiten. Und Sie lernen durchaus auch tiefer, weil Sie eben mehr auf sich allein gestellt sind. Es geht dann vielleicht langsamer voran, weil Ihre Fragen nicht jederzeit von einem Trainer beantwortet werden können. Doch durch die mühsamere Erarbeitung von Antworten durch Sie selbst sitzt das Gelernte dann fester.

Lernen sollte also aus einer guten Mischung von Begleitung und Autodidaktik stattfinden. Deshalb bieten wir Termine der CCD School auch nur im Abstand von 4–6 Wochen an.[1] Zwischendurch soll selbstständig gelernt werden.

Das hört sich sinnig und einfach an, oder?

Leider hat dieses Vorgehen einen Haken. Wieder und wieder müssen wir feststellen, dass das Selbstlernen den CCD School Teilnehmern schwer fällt. Das hat auch ein kleines Experiment gezeigt, welches Trainer Ralf Westphal Anfang 2015 durchgeführt hat. Er hatte einen “Selbstlern-Challenge” ausgerufen: 10 Teilnehmer sollten sich 10 Wochen lang regelmäßig und selbstständig in Flow Design[2] einarbeiten. Das Ergebnis war ernüchternd. Trotz einer losen Begleitung und “finanziellem Anreiz” haben 50% der Teilnehmer nicht durchgehalten.

Nach dieser Erfahrung wollen wir das Thema selbstständiges Lernen in der CCD School noch bewusster angehen. Als erste Hilfestellung unser Tip:

Dokumentieren Sie Ihren Lernfortschritt in einem Lerntagebuch.

Ein Lerntagebuch soll das Lernen greifbarer machen und fokussieren.

Greifbarer wird es, weil Sie beim Lernen damit eine Spur hinterlassen. Ob das Lernen darin besteht, dass Sie etwas lesen oder mit Kollegen eine Aufgabe diskutieren oder einen Entwurf machen oder etwas codieren… Egal, wie flüchtig Ihre Lernprodukte sind, im Lerntagebuch findet all das Niederschlag.

Ein Lerntagebuch ist für Sie ein – womöglich papierernes – Dokument, das Ihnen oder auch anderen zeigt, dass und wie sie beim Lernen vorankommen.

Fokussierter wird das Lernen, weil Sie im Lerntagebuch ein Destillat des Lernens festhalten. Egal was und wie Sie lernen, mindestens für den Eintrag im Lerntagebuch müssen Sie sich konzentrieren. Für einen Moment gehen Sie in die Reflexion und lassen das Lernen Revue passieren. Ihnen wird das Lernen als eigenständige Tätigkeit nochmal bewusst.

Medium

Das Medium für Ihr Lerntagebuch ist fast egal. Sie können es in Word oder Evernote führen oder in einem physischen Notizbuch. Früher hat Trainer Ralf Westphal zur Dokumentation seiner Gedanken und seines Lernens Notizbücher benutzt:

Notizbücher als Lerntagebuch

Heute machter Einträge in Evernote-Notizen. Für jedes Lernthema gibt es eine, die er pro Lerneinheit fortschreibt. Hier ein Eintrag aus seinem Lerntagebuch zur Programmiersprache Groovy:

Evernote als Lerntagebuch Organisieren Sie sich Ihr Tagebuchmedium, wie Sie möchten. Nehmen Sie einen Ordner oder eine spezielle Tagebuch-App, schreiben Sie auf Papier oder auf dem iPad. Vielleicht hilft es Ihnen, sich an die Wichtigkeit des Lernens zu erinnern und es zu tun, wenn Sie ein Notizbuch am Arbeitsplatz liegen haben. Vielleicht macht es Ihnen so ein Papierbuch auch leichter, gegenüber Kollegen das Lernen zu vertreten. Oder Ihnen fällt es leichter, über das Lernen zu reflektieren, wenn Sie auf einer Tastatur flink Ihre Gedanken in ein Softwarewerkzeug fließen lassen können.

Inhalt

Ein Lerntagebuch soll Ihnen beim Lernen natürlich keine Last sein. Eher im Gegenteil! Es soll Ihnen Spaß machen, darin am Ende kurz zusammenzufassen, was Sie geschafft haben. Es ist doch schön, sich seiner Fortschritte bewusst zu sein.

Was Sie in Ihrem Lerntagebuch festhalten, steht Ihnen also frei. Ein kleiner Rahmen ist trotzdem hilfreich:

  • Versehen Sie jeden Eintrag mit einem Datum und womöglich sogar Uhrzeit bzw. Dauer der Lerneinheit, z.B. 26.6.2015, 10:00 bis 11:30
  • Wenn möglich, finden Sie eine Titel für den Eintrag. Pro Lerneinheit sollten Sie sich auf ein Thema konzentrieren. (Auch hier gilt das SRP ;-) Dieses Thema dokumentieren Sie mit einer Überschrift zum Eintrag, z.B. Flow Design Entwurf in Code übersetzen
  • Schreiben Sie zumindest in Stichpunkten auf, was Sie während der Lerneinheit getan haben, z.B.
    • Funktionseinheit mit einem Input/Output in Funktion übersetzt
    • Mehrere Funktionseinheiten/Funktionen zu einer Klasse zusammengefasst
    • Funktionseinheit mit mehreren Outputs in Funktion mit Continuations übersetzt
  • Notieren Sie Hürden, über die Sie gestolpert sind, oder Fehler, die Sie gemacht haben. Wenn möglich, sollte darauf natürlich auch eine Verbesserung/Lösung folgen, z.B. Der Aufruf von Funktionen mit Continuations ist schlecht zu lesen gewesen. Aber mit ein wenig Disziplin bei der Einrückung ging es besser.
  • Notieren Sie Ergebnisse und Erkenntnisse. Die ergeben sich natürlich oft aus Hürden/Fehlern, können aber auch Zusammenfassungen/Abstraktionen allgemeinerer Art sein, z.B. Streams im Flow Design wenn möglich mit IEnumerable übersetzen statt mit Continuations.

So könnte dann ein Eintrag in einem Notizbuch aussehen:

Handschriftlicher Eintrag

Oder so könnte er aussehen, wenn Sie Evernote bevorzugen:

Digitaler Eintrag

In einem elektronischen Lerntagebuch können Sie leichter konkrete Ergebnisse Ihres Lernens dokumentieren durch Codeausschnitte oder Screenshots oder Anhänge und Links. Nutzen Sie die Chance, um sich das Lernen plastisch zu machen.

Zusammenfassung

Physische und digitale Lerntagebücher haben ihre je eigenen Vor- und Nachteile. Probieren Sie aus, was Ihnen am besten dient.

In jedem Fall sollten Sie jedoch ein Lerntagebuch führen, egal, ob und wann Sie allein lernen, in der Gruppe oder sogar begleitet. Lassen Sie sich durch ein Lerntagebuch ans Lernen erinnern. Erfreuen Sie sich beim Durchblättern des Lerntagebuchs daran, was Sie alles schon geschafft haben.


  1. Das gilt zumindest für Präsenztermine von 1–2 Tagen. Kürzere online Termine machen auch in kürzeren Abständen Sinn.  ↩
  2. Flow Design ist eine der Methoden, die die CCD School unterrichtet. Softwareentwicklung mit Flow Design führt zu Code, der quasi automatisch wesentliche Prinzipien des Clean Code Development einhält. Beim Flow Design wird Verhalten von Software in Form von Datenflüssen entworfen und codiert.  ↩

Die CCD School geht online

CCDS onlineNach einigem Experimentieren ist es nun soweit: Clean Code Development können Sie nun im Internet lernen. Interaktiv, persönlich, individuell.

Das ist aber nicht nur zeitgemäß, sondern gleichermaßen praktisch wie ökologisch.

Der ökologische Vorteil liegt auf der Hand. Niemand muss mehr für CCD Unterricht reisen, nicht mit dem Auto, nicht mit Bahn oder Flugzeug. Clean Code Development kann man lernen „from the comfort of your home“. Nicht mehr als Webcam und Headset sind nötig. Naja, eine vernünftige Internetanbindung sollte auch noch vorhanden sein. Außer in wenigen Breitband-Diaspora-Gebieten, sollte das jedoch kein Problem sein.

Praktisch ist der online Unterricht aber auch. Er spart Transaktionsaufwand (Reisezeit und Reisekosten). Damit ist er in kleineren Happen und kurzfristiger möglich. Wenn das nicht eine gute Nachricht für jeden kostenbewussten Chef ist… ;-)

Außerdem findet er in kleineren Gruppen statt. Das kann dem Lernen nur zuträglich sein.

Mit dem Tool GotoMeeting ist flüssige Videokommunikation möglich. Screensharing und Chat gibt es auch. Andere Angebote wie TeamViewer, Google Hangouts oder Skype haben sich als qualitativ genügend erwiesen für längere Sitzungen mit mehreren Teilnehmern.

Dazu kommt dann noch ConceptBoard als gemeinsames online Whiteboard, um Gedanken grafisch spontan festzuhalten. Dafür lohnt sich allerdings noch ein Grafik-Tablet wie Wacom Bamboo mit Stift. Ist ja aber auch für kleines Geld zu haben.

Online Treffen beginnen dann gewöhnlich mit 5-10 Minuten technischer „Kalibrierung“ bis alles bei allen läuft. Aber anschließend flutscht es. Das Gespräch auch mit 5-6 Teilnehmern funktioniert erstaunlich gut. Der Wechsel zwischen Whiteboard und Bildschirmpräsentation ist womöglich sogar einfacher als offline. Kein Kabel muss mehr umgesteckt werden für den Beamer. Und wer sich mal ausklinken will, der stört auch weniger.

Sich vorher persönlich zu kennen, mag das online Treffen noch ein bisschen leichter machen. Doch am Ende bringt die Videokommunikation in jede Runde schnell Vertrauen.

Und so sind wir zuversichtlich, dass der online Unterricht eine große Zukunft hat. Er kann kostengünstiger und flexibler angeboten werden, so dass die geringen Nachteile schnell aufgewogen werden.

Clean Code Development Training geht jetzt also online – wer geht mit?

Die CCD School schwenkt um

Ein zentraler Begriff bei Lean Startups ist das „Pivoting“. Es bedeutet Umschwenken, Kursänderung, wenn man feststellt, dass eine Strategie nicht so funktioniert, wie gedacht. Lean Startups sind ja Forschungsstätten, die Geschäftsmodell-Hypothesen überprüfen. Erfolg verifiziert sie, Misserfolg falsifiziert sie.

So tun wir es nun auch bei der CCD School. Wie schon im April gesagt, sehen wir sie als Startup. Wir hatten eine Hypothese, wie regelmäßiges Lernen für Lernende und Lehrer funktionieren könnte… und lagen damit nicht 100% richtig. Macht nichts. Ganz im Sinne des Elastischen Manifests sagen wir: Fortschritt vor Ankommen, Reaktion vor Planerfüllung. Als schwenken wir um.

Wir behalten natürlich das Bewährte bei. Immer noch geht es ja um eine bestimmte Idee. Die darf durch ein Umschwenken nicht kompromittiert werden. Die CCD School steht weiterhin für angeleitetes und fokussiertes Lernen. Fokussiert sein soll das Lernen durch Konzentration auf einen Themenkomplex (Clean Code Development) sowie ausdrücklich geplante Zeit fürs Lernen. Angeleitet soll das Lernen sein, um Hilfestellung im Thema zu geben, aber auch, um beim Lernen des Lernen zu unterstützen. Wenn niemand am Lernenden „zieht“, verliert der leicht die Konzentration oder verliert sich in einem „Tal der Tränen“.

Änderungen nehme wir in zwei Aspekten vor. Bei der Regelmäßigkeit und der Individualität.

Die Regelmäßigkeit muss natürlich grundsätzlich bleiben, sondern würde sich die CCD School nicht von anderen Trainings unterscheiden; sie steht im Kern der Idee. Doch gerade da hat sich unsere Hypothese als teilweise unzutreffend erwiesen. Nicht, dass das regelmäßige Lernen nicht besser wäre als das sporadische. Aber die terminliche Belastung und die „Transaktionskosten“ sind bei wöchentlichem Unterricht sowohl für Lernende wie für Lehrer hoch, gar zu hoch.

Deshalb schwenken wir vom wöchentlichen Unterricht um auf monatlichen. In Zukunft bietet die Schule Unterricht im Abstand von 3-5 Wochen an. Das ist seltener als bisher, aber immer noch häufig genug, um als regelmäßig empfunden zu werden. Der nächste Unterrichtstermin ist in absehbarer Entfernung, so dass Gelerntes nicht vergessen wird und noch nicht Geschafftes vertagt werden kann.

Unterrichtsblöcke dauern nun auch nicht mehr 4 Stunden, sondern 1 Tag. Dadurch muss zwar mehr Arbeitszeit eingesetzt werden… doch das halten wir beim vergrößerten zeitlichen Abstand für vertretbar.

Erste Erfahrungen mit diesem neuen Rhythmus sind ermutigend.

Ganz grundsätzlich soll individuelles Lernen natürlich weiterhin in der CCD School möglich sein. Wir freuen uns über jeden Lernenden, der sich aus eigenem Antrieb etwas vornimmt, woran er/sie arbeiten möchte. Die Erfahrung zeigt jedoch, dass gerade am Anfang ein großer Wunsch nach mehr Anregung und Anleitung vorhanden ist. Daher geben wir das Format Impuls+Individuallernen auf. Der Unterricht verliert damit den letzten Rest von Plan :-) Stattdessen fließt er einfach, wie es sich ergibt durch das Gebiet des Clean Code Development und besucht nach Bedarf die dortigen „Sehenswürdigkeiten“.

Als Anleiter sehen wir zu, dass es dabei stetigen Fortschritt gibt. Doch auch wer später einsteigt, kann mitreisen. Unsere Hypothese: In dieser Weise wird erstens mehr „Guidance“ gegeben und es ergeben sich natürlichere Anlässe für individuelles Arbeiten. Da besteht nämlich weniger in eigenen Projekten, als vielmehr im Voranschreiten in unterschiedlicher Geschwindigkeit bestimmt durch Auffassungsgabe/Vorbildung und Zeitpunkt des Einstiegs.

Soweit unsere Idee zum „Pivoting“ der Clean Code Developer School. Dieser Hypothese geben wir jetzt mal wieder einige Monate Zeit und reflektieren dann wieder.

Retrospektive zur Sommerpause

Nach knapp drei Monaten CCD School (CCDS) in München, sind wir jetzt in die Sommerpause gegangen. Zeit für eine kurze Reflexion. Die CCDS ist ja ein Experiment bzw. ein kleines Start-up. Da lohnt die Frage, ob die These bestätigt ist bzw. es Zeit für ein Pivoting ist oder alles weitergehen kann wie bisher.

Die Grundthese halten wir für bestätigt. Das Lernen in kleinen, regelmäßigen Happen ist eine sehr gute Sache. Fortschritt ist individuell möglich. Und die Anleitung beim Lernen ist wichtig. Dazu hat es nur positive Rückmeldung gegeben.

Den Unterrichtsplan haben wir allerdings nicht genau eingehalten. Am Anfang jedes Unterrichtsblocks gab es zwar eine Zeit gemeinsamer Arbeit, doch das Thema hat sich meist spontan ergeben. Mal war da mehr Vortrag durch Stefan oder mich, mal mehr allgemeine Diskussion. Das fühlte sich recht organisch an. Dennoch ist es gut, den Themenkomplex in kleinere Einheiten aufgeteilt im Hinterkopf zu haben. Die Vorarbeit für den Unterrichtsplan war also nicht vergebens.

Die plattformspezifischen Anteile werden wir aber streichen. Nicht, dass wir dazu nichts mehr sagen wollen, nur sollen die nicht mehr Bestandteil eines offiziellen Curriculums sein. Es hat sich gezeigt, dass der Unterricht sehr gut plattformübergreifend funktioniert. C# oder Java oder JavaScript? Das ist nicht wirklich wichtig. Als Trainer kommen wir mit allen zurecht – im Zweifelsfall müssen halt die Teilnehmer etwas in ihre Plattform einsteigen, um das eine oder andere Implementationsdetail mal zu erforschen. Aber auch das ist ja eine Sache, die kann man lernen und die gehört auch zum (selbstständigen) Lernen.

Der Knackpunkt bei der CCDS ist – das war nicht anders zu erwarten – der Aufwand. Oder genauer: Das Verhältnis von Aufwand und Effekt. München hat sich leider nicht als so offen für die CCDS herausgestellt, wie wir es gedacht hatten. Die Münchener .NET User Group hatte kein Interesse. Aus den 219 angeschriebenen Mitgliedern der CCD Gruppe bei XING gab es nur 2-3 Rückmeldungen. Sehr schade.

Andere Communities jedoch waren, als sie davon gehört haben, viel interessierter. Allen voran in Berlin und im Rhein/Main Gebiet hat man gefragt, ob wir nicht auch dort die CCDS öffnen könnten. Und dann gab es noch ein paar Anfragen nach inhouse Schools.

Diesen Widerspruch zu unserer These „Im Süden ist die Entwicklerdichte am höchsten, da finden wir am ehesten Teilnehmer“ werden wir jetzt mal in der Sommerpause diskutieren.

Angesichts des Aufwands stellt sich auch die Frage nach der Frequenz. Knapp 3 Monate jede Woche in der Ferne vor Ort sein, belastet den Reisemuskel sehr stark. Auch der eng getaktete regelmäßige Einsatz ist schwer mit unseren sonstigen Trainings- und Beratungsaktivitäten schwer zu vereinbaren. Was für die Teilnehmer gut ist, belastet uns als Trainer. Da müssen wir die Balance auch noch besser einstellen.

Ich denke, zweierlei könnte sich ändern: Die CCDS könnte in Semestern stattfinden. Die wären 2-3 Monate lang; es könnte Spring, Summer, Autumn, Winter Schools geben.

Oder mit der Frequenz könnten wir spielen. Ist Unterricht jede Woche wichtig oder reicht es alle 2 oder 4 Wochen? Ich denke, das wichtigste ist, den Abstand nicht zu groß zu machen. Unterrichtsblöcke im Monatsabstand scheinen mir da das Äußerste.

Wenn die Frequenz sinkt, müsste aber wohl auch etwas an der Dauer gedreht werden, sonst kommt nicht genug Stoff zusammen für eine größere Pause zwischen den Blöcken. Alle 3-4 Wochen 1 ganzer Tag oder 2 halbe Tage (Nachmittag + Vormittag) könnten ausreichen.

Soweit der Präsenzunterricht. Dazu könnte eine Betreuung aus der Ferne kommen. Im Jahr 2013 sollte es doch machbar sein, in kleinen Gruppen online zu arbeiten: Screensharing, Video… das ist doch kein Hexenwerk. Angebote gibt es viele. Was ist aber wirklich verlässlich für 1-2 Stunden online Treff? In dieser Hinsicht werden wir auch experimentieren müssen, um besser zu skalieren. Ausschließlich online lernen, halte ich für keine gute Sache. Regelmäßig ausschließlich lernen in offline Präsenz ist schwierig. Der Mix wird es machen.

In jedem Fall hat es uns bei aller Reiseanstrengung Spaß gemacht. Und den Teilnehmern auch. Wir bleiben also dran, dieses Lernangebot aufrecht zu erhalten.

 

Lernen zum eigenen Vorteil

Warum sollte man als Entwickler eigentlich kontinuierlich lernen – und dann auch noch Clean Code Development?

Und warum sollte eine Organisation daran interessiert sein, dass ihre Entwickler kontinuierlich lernen – und dann auch noch Clean Code Development?

Wir denken, dass ist eine simple Frage der Ökonomie.

Jede Organisation, deren Zweck es ist, Software herzustellen, muss daran interessiert sein, diese Leistung attraktiv zu erbringen. Attraktiv bedeutet, dass man sie einer anderen Organisation vorzieht. Das ist der Fall, wenn die Software stets „mit der Zeit geht“. Das bedeutet erstens, sie nutzt äußerlich und für den Kunden sichtbar technologische Optionen, um nicht funktionale Anforderungen zu erfüllen. Das reicht von GUI über Persistenz und Cloud bis Mobile. Zweitens bedeutet das, sie ist in einem Zustand, dass solche Neuerungen überhaupt ohne wachsenden Aufwand angebracht werden können. Und drittens bedeutet es, dass die Entwickler in einem „geistigen Zustand sind“, der sie Anderes und Neues, gar Innovatives denken lässt.

Wie soll solche Attraktivität aber entstehen und erhalten werden, wenn nicht beständig die wechselnden technologischen Optionen gesichtet und „draufgeschafft“ werden? Wie soll Neues effizient eingearbeitet werden, wenn der Code nicht Clean ist? Woher soll der „geistige Zustand“ herkommen, wenn Entwickler sich nicht in einer Lern- und Experimentalkultur bewegen?

Sicher, irgendwie geht es auch ohne. Es geht genauso ohne, wie man von 20 bis 65 leben und arbeiten kann, ohne auf seine Ernährung zu achten, nichts für die Fitness zu tun und zu rauchen und zu trinken. Das geht – nur ob man dann etwas von der Rente hat, ist fraglich.

Jeder Entwickler muss andererseits auch daran interessiert sein, dass erstens er und zweitens seine Organisation attraktiv bleibt.

Eine im obigen Sinne attraktive Organisation bietet dem Entwickler nämlich die Möglichkeit, coole Sachen mit Software zu tun. Kein Entwickler möchte 30 Jahre am selben Java-Code rumschrauben – oder höchstens, wenn er sich innerlich aufgegeben hat. Das ist schlicht langweilig. Also suchen Entwickler ein Umfeld, in dem sie die Chance haben, immer wieder Neues anzubringen. Dafür ist Clean Code Development essenziell.

Für den Fall jedoch, dass eine Organisation ihre Attraktivität verliert, muss jeder Entwickler daran interessiert sein, selbst attraktiv für andere Organisationen zu sein. Das bleibt er aber nur, wenn er sich nicht auf seinem Ausbildungswissen ausruht. 3 Jahre Ausbildung + 8 Jahre Erfahrung sammeln in 1 Domäne an 1 Produkt ist nett… aber macht nicht wirklich attraktiv.

Attraktivität entsteht und wird erhalten, wenn ein Entwickler zeigt, dass er versteht, wie er Schritt hält mit der Entwicklung seines Metiers. Und darüber hinaus muss er demonstrieren, dass er Code produziert, der ebenfalls Schritt halten kann. Das ist Clean Code.

So ist kontinuierliches Lernen aus unserer Sicht die Voraussetzung für nachhaltige Attraktivität sowohl von Organisationen wie Entwicklern. Alles andere ist Arbeit auf Kosten von Puffern, seien das Wissenspuffer oder Motivationspuffer. Das kann man eine Zeit lang tun, so wie man auch mal einige Tage ohne Nahrung auskommen kann – doch letztlich ist das kein gesundes Leben/Arbeiten.

Deshalb empfehlen wir: jede Woche ein bisschen Lernen. Dran bleiben, in einem Rhythmus kommen. Mit 4 Stunden ist das so lang wie 1 x Tatort + 1 x Sprachkurs oder 1 x Yoga + 1 x Kino oder 1 x Fußball + 1 x Theater. Und mindestens die Hälfte davon sollte in der Arbeitszeit stattfinden. Das ist doch nicht zuviel, oder? Wenn man Attraktivität heute und in Zukunft als Ziel hat.

Der erste Unterrichtsblock in München

Konzentration beim ersten UnterrichtsblockSpaß hat er gemacht der erste Unterrichtsblock der Clean Code Developer School (CCDS). In München waren drei Teilnehmer angemeldet – leider sind aber nur zwei gekommen. Da waren zwei Trainer natürlich Overkill, doch Stefan und ich wollten beide am ersten Tag dort sein. In Zukunft wechseln wir uns ab.

Angefangen haben wir mit knapp 50 Minuten Impuls zum Thema TDD. Wir haben versucht, uns auf die Demonstration des red+green+refactor Rhythmus zu beschränken – auch wenn uns das schwer fiel. Es gibt ja soviel drumherum zu zeigen.

Ein bisschen gebangt habe ich dabei, weil eine Teilnehmerin C/Java Hintergrund hatte, wir aber in C# vorgeführt haben. Doch das war am Ende kein Problem. Sie war aufgeschlossen und zusammen haben wir das Gezeigte nach Java/Eclipse übertragen.

Nach dem TDD-Impuls stand den Teilnehmern frei, etwas zu üben, das sie interessierte. Sie entschieden sich beide für TDD und unseren Aufgabenvorschlag „Kata Roman Numerals„. Und das hat sie dann die verbleibenden 3 Stunden beschäftigt. Oberflächlich sieht die Aufgabe leicht aus – doch der Teufel steckt im Detail.

So sind wir dann doch über das Thema TDD 1.0 hinausgeschossen und haben an TDD 2.0 gekratzt: vor dem munteren Codieren nach TDD 1.0 sollte ein wenig Nachdenken über Problem und Lösungsansatz stehen.

Aber in der CCDS wollen wir es mit dem Lehrplan nicht so genau nehmen. Jenseits des Themenimpulses wird aufgegriffen, was gerade nützlich ist.

Am Ende haben wir mit einem Code Review und einer kurzen Retrospektive zum Unterrichtsblock geschlossen. Die Meinungen waren einhellig positiv. Die Zeit war niemandem lang geworden. Nur über das Lehrmaterial zum Impulsthema müssen wir nochmal nachdenken. Wir hatten es einige Tage vorher verschickt, was nicht unbedingt das Interesse am Impuls erhöht hat. Na, wir schauen mal, was wir da machen…

Unser Fazit: Das hat Spaß gemacht. Und es hat funktioniert. Denn unterrichten ohne Zeitdruck ist anders. Es geht tiefer, es ist ruhiger. Immer wieder haben wir gemerkt, wie locker wir als Trainer sein konnten, weil wir nicht auf 4 oder 8 oder wieviele Stunden begrenzt sind. Wir müssen nicht „alles“ in einen fixen Zeitrahmen pressen. Stattdessen können wir Themen nach Bedarf und in Ruhe angehen. Ich würde sagen, das ist eher „holographisches Lehren“, weil in jedem Unterrichtsblock quasi alles eine Rolle spielen kann. Und was besonders wichtig ist, kommt eben häufiger dran.

Fördern und Fordern

Lernen wird in den meisten Unternehmen als Angebot betrachtet. (Wenn es denn überhaupt ein Thema ist, mit dem sich das Management auseinandersetzt.)

Es gibt Lernangebote für die Mitarbeiter. Die können sie annehmen oder nicht. Sie reichen von der abonnierten Zeitschrift über ein Budget für Fachliteratur bis zu 3 oder 5 Tagen Training oder Konferenzbesuch. Gelegentlich gibt es auch inhouse „Lernzirkel“. Teilnahme freiwillig.

Das ist alles wunderbar. Weiter so und mehr davon! Das ist wichtige Förderung der Weiterentwicklung von Mitarbeitern.

Was aber, wenn diese hübschen Angebote nicht angenommen werden? Dann passiert nichts. Die Zeitschriften lesen nur wenige, das Buchbudget wird nicht ausgeschöpft oder immer bestellen nur dieselben 2-3 Mitarbeiter sich Fachbücher, Trainings und Konferenzen werden besucht, doch niemand weiß, ob das Gehörte auch angewandt wird.

Das, was dann am ehesten passiert ist, dass diese Angebote über die Zeit gestrichen werden. Scheinen ja nicht so wichtig zu sein. Und da ein Effekt nicht überprüft wird, sind sie im Zweifelsfall disponibel, wenn grad mal wieder Releasedruck für drei oder sechs Monate herrscht.

Das halten wir für falsch. Lernen darf kein Incentive sein. Es geht nicht darum, mit Lernangeboten irgendjemanden persönlich zu motivieren. Oder zumindest ist das nicht ihre einzige Aufgabe. Es geht vielmehr um die Fitness des Unternehmens. Mitarbeiter, die nicht lernen, bleiben stehen und werden in Relation zum Markt, der sich weiterentwickelt, immer schlechter. Das gleichen auch Neuzugänge nicht aus. Wir reden ja nicht über das Brötchenbacken, sondern über hochkomplizierte „virtuelle Maschinen“ und Werkzeuge, die hergestellt werden. Die Vielfalt nimmt ständig zu. Die Komplexität von Systemen wächst ständig. Und da soll Lernen ein freundliches Angebot sein?

Nein, Lernen ist das Gebot der Stunde. Und deshalb bedarf es nicht nur der Förderung, sondern auch der Forderung. Lernen und Üben muss vom Unternehmen nachgefragt werden. „Heute schon gelernt?“ muss stets als Frage im Raum stehen.

Die Clean Code Developer School (CCDS) sieht sich als Unterstützer solcher Strategie. Unternehmen, die ihren Mitarbeitern ein Abo für die CCDS geben, fördern. Sie machen ihnen ein attraktives Lernangebot, das sie finanzieren und für das sie die Mitarbeiter sogar z.T. freistellen.

Andererseits fordern diese Unternehmen durch diese konkrete Investition aber auch das Lernen. Denn anders als ein Fachbuchbudget, das eher passiv ist, weil man es nutzen kann oder nicht, ist die CCDS „aktiv“. Sie zieht an den Teilnehmern. Sie will jede Woche besucht werden – denn warum sonst dafür Geld ausgeben?

Und anders als in einem inhouse „Lernzirkel“, bei dem die Kollegen vor allem nett und freundlich miteinander sind, zieht die CCDS inhaltlich an den Teilnehmern. Sie hat den Anspruch, etwas zu wissen und zu vermitteln. Ja, die CCDS fordert Lernen und Üben. Aber natürlich in freundlicher Art, keine Sorge.

Lernen ist Veränderung. Veränderung fällt nicht immer leicht. Deshalb reicht Förderung allein nicht. Liebevolle, aber bestimmte Forderung ist auch nötig. Ein Besuch der CCDS bietet beides.