• Teaser Home

    Clean Code Developer School

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

Die Schule als Startup

Die Clean Code Developer School (CCDS) zu gründen, ist für Stefan und mich ein Experiment. Mit der Idee sind wir in der einen oder Form schon einige Jahre schwanger gegangen… doch jetzt hat uns ein Erlebnis bei einem Training den entscheidenden Impuls gegeben:

Nach 7 Tagen Clean Code Developer inhouse Training mit 8 sehr motivierten Entwicklern, das viel Spaß gemacht hat, sind wir nämlich vor eine Wand gelaufen. Die Wand der Realität des Tagesgeschäftes. Alles lief flüssig während des Trainings, alle hatten große Lust, etwas zu lernen. Doch auf die Frage, wie man denn das Gelernte nach dem Training weiter üben und ins Projekt einfließen lassen wolle… da waren die Teilnehmer ratlos. Sie hatten keinen Plan dafür und konnten sich nur schwer vorstellen, konsequent jede Woche zu üben.

Das war sehr frustrierend für uns. Wir wollen Trainings ja nicht irgendwie für die Kohle absitzen, sondern etwas bewirken. Es macht uns Freude zu sehen, wenn anschließend die Softwareentwicklung besser von der Hand geht.

Leider mussten wir wieder feststellen, dass dieses Ziel mit dem üblichen Trainingsformat nicht zu erreichen ist. Für Technologietrainings mag das noch eher gehen, für Methodentraining funktioniert es jedoch nicht. Da ist nicht zu erwarten, dass nach den Trainingstagen der Lehrstoff sitzt und nur noch angewendet werden muss. Er ist vielmehr weiter zu üben und die Ergebnisse sind zu überprüfen. Wenn dafür im Tagesgeschäft notorisch aber nicht der Raum ist, ist das Training vergebens.

Wir sehen das nun nicht mehr als Problem der Entwickler, sondern als Problem des Trainings. Ein Training darf sich nicht der Tagesgeschäftrealität seiner Teilnehmer verschließen. Wenn die so ist, dass Üben nicht stattfinden kann, dann muss sich das Training ändern. Das versuchen wir nun mit der CCDS. Ob das klappt, ob das bei den Unternehmen und Entwicklern ankommt, müssen wir abwarten.

Beispiel ist für uns der lernende Umgang mit anderen Disziplinen, sei es Sport, Ernährung, Präsentieren. Überall wird kontinuierlich gelernt. Jede Woche ein paar Stunden zusammen mit anderen, darüber hinaus vielleicht noch allein zuhaus. Fitnessstudio, Weight Watchers, Toastmasters wissen, dass sich das gesteckte Ziel nicht mit 2-5 Tagen Kursus erreichen lässt. So funktioniert persönliche Veränderung einfach nicht. Unzählige weitere Beispiele lassen sich finden.

Nur die Softwareentwicklung glaubt, dass sie der noch größeren Flut an Neuerungen im Vergleich zu anderen Disziplinen Herr wird, indem sie am besten gar nicht mehr lernt, nachdem eine „Grundausbildung“ abgeschlossen wurde. Oder wenn schon lernen, dann möglichst kurz und zwischendurch.

Daran glauben wir nun nicht mehr. Das Thema ist durch für uns. So geht es nicht. Weiter zu machen wie bisher, wäre Heuchelei.

Die Herausforderung ist nun, diese Erkenntnis in ein Produkt zu überführen. Das versuchen wir mit der CCDS.

Wir wissen grob, was wir wollen, wo wir einen Bedarf sehen. Aber wie genau dieses Ziel erreichen… das müssen wir ausprobieren. Wir fangen deshalb mal mit einer Idee für Format und Preisgestaltung an – und schauen, wie sich das anlässt. Schön, wenn es funktioniert. Aber wenn nicht, dann drehen wir an irgendeiner Schraube, die uns das Feedback nahelegt.

Die CCDS geht also ganz bewusst einen anderen Weg. Sie ist kein „me too“-Produkt, sondern der Versuch, das Lernen in der Softwareentwicklungsbranche neu zu erfinden.

Dadurch wollen wir bisherige Formate nicht per se ersetzen. Auch ein 3-Tage Training hat seinen Sinn. Auch ein Coding Dojo Abend im Kreise von Community-Kollegen hat seinen Sinn. Aus unserer Sicht fehlt jedoch ein entscheidender Baustein zur deliberate practice und zum nachhaltigen Lernen. Den wollen wir mit der CCDS liefern.

Wir sind gespannt, welches Ergebnis unser Startup-Experiment liefert. Vielleicht machen Sie ja mit. Wir freuen uns auf Ihr Feedback.

School reloaded

Eine Clean Code Developer School (CCDS) gab es früher schon einmal. Vielleicht sind Sie darüber bei Google gestolpert.

Stefan Lieser und mir schwebte der Gedanke einer „schulischeren Vermittlung“ von Clean Code Developer Bausteinen schon früher im Kopf herum. Da haben wir dann unsere Trainings schon mal mit dem Zusatz „School“ versehen. Was draußen drauf stand, war aber noch nicht drin. Das haben wir uns nicht getraut.

Heute sind wir mutiger. Jetzt machen wir Butter bei die Fische und bemühen uns um Kongruenz von Gedanken und Taten. Wir glauben immer noch daran, dass „schulischere Vermittlung“ im Sinne von kleinen, kontinuierlich eingenommenen „Lernstoffhappen“ nachhaltiger ist – und damit unterm Strich auch kostengünstiger für die Lernenden bzw. die, die das Lernen bezahlen.

Für uns als „Kollegium“ hingegen ist es aufwändiger. Doch das soll erst mal nichts machen. Wir sehen es als Experiment – und haben auch Ideen, wie diese Lern- und Übungsplattform skalieren könnte.

Die CCDS macht andere Lernformen ja auch nicht überflüssig. In der Community beim Bier plaudern und Codieren behält seinen Wert wie 2 Tage Javascript Einführung. Die CCDS will nicht ersetzen, sondern ergänzen. Eine klaffende Lücke soll geschlossen werden. Der Wert kontinuierlichen Lernens soll ins Bewusstsein gerückt werden.

Mit unserer Erfahrung der vergangenen vier Jahre in verschiedenen Formen von Clean Code Developer Trainings – von Camp über School bis zu Akademie – haben wir nun den Mut, die ursprüngliche Idee wirklich anzugehen. Erst ganz klein… und dann mal schauen.

Wir freuen uns sehr darauf, Inhalte in viel entspannterer Situation zu vermitteln und den Fortschritt der Teilnehmer begleiten zu können. Das „fire and forget“ der üblichen Trainings mag lukrativer sein – ist aber persönlich weniger befriedigend. Darauf haben wir immer weniger Lust. Deshalb läuten wir jetzt mal mit der Schulglocke und sind gespannt, wer mit uns an diese Form des Lernens glaubt und sich damit ernsthaft auf den Weg kontinuierlicher Verbesserung macht.

Accountability Partner

Das einsame Genie, der zurückgezogene Hacker, der disziplinierte Arbeiter: das sind romantische Ideale unserer Arbeitsgesellschaft. Einer nimmt sich was vor, jemand folgt einer Berufung – und erreicht mit heldenhafter Anstrengung sein Ziel.

Woher kommt diese Vorstellung nur? Denn die ist völlig irreal. Es mag hier und da Erfolge geben, die ein Mensch allein erzielt. Aber dieses Modell lässt sich nicht auf die Masse der Menschen übertragen. Einsame Genies sind genauso möglich wie Menschen, die am Tag 40 Zigarren rauchen und auch noch alt werden (Beispiel Mark Twain) – deshalb ist ein solches Leben jedoch nicht für jeden erreichbar.

Die allermeisten Erfolge stellen sich durch die Kooperation von Menschen ein. Je größer eine Aufgabe, desto einleuchtender ist das auch. Sie arbeiten an Ihrem Softwareprojekt aus gutem Grund auch nicht allein.

Die irreale Vorstellung ist jedoch hartnäckig und besonders in einem Bereich deshalb kontraproduktiv: beim Lernen, bei der (persönlichen) Veränderung.

Lernen ist weithin immer noch ein einsames Geschäft. Es soll ja auch einer etwas lernen. Es soll ja auch klar sein, was einer kann. Schummeln jeder Art mag in Lausbubengeschichten nett sein, doch im richtigen Leben ist es nicht erwünscht. Wir wollen Zurechenbarkeit von Ergebnissen. Denn wenn klar ist, wer sie erreicht hat, dann kann der besonders belohnt werden.

So geht es von der Grundschule bis zum Vorstandsvorsitz: der Erfolg einer Veränderung soll möglichst einer Person zurechenbar sein.

Doch damit wird erfolgreiche Veränderung erschwert. Der Sacherfolg steht nämlich schnell der Zurechenbarkeit hinten an.

Das wollen wir in der Clean Code Developer School (CCDS) anders handhaben. Uns geht es um den besten Weg beim Aufbau von Kompetenz. Und wenn der nicht über “einsames Lernen” führt, dann gehen wir einen anderen. In der CCDS wird deshalb Kooperation groß geschrieben. Alle helfen sich untereinander. Im Unterricht herrscht Lerngemeinschaft. Alle sitzen im selben Boot. Es gibt keine Konkurrenz. Es gibt auch keine Noten.

Wer einem anderen hilft, etwas hinzubekommen, der kann sich darüber genauso freuen, wie darüber, selbst etwas hinbekommen zu haben.

Lernen ist Veränderung, zuweilen sogar tiefgreifende Veränderung. Die allein konsequent und diszipliniert zu durchlaufen, ist für viele Menschen schwierig. Deshalb sehen Stefan Lieser und ich uns nicht nur als Wissensvermittler, sondern als Accountability Partner der Lernenden. Wir stehen ihnen bei, wir ermutigen, wir ziehen aber auch ihnen. Fördern und fordern. Denn wenn der Fortschritt mal schwieriger wird, dann ist es gut, wenn da einer zum Reden ist.

“Lernwegbegleiter” oder “Veränderungspartner” könnten wir uns auch nennen.

Kennen Sie Das?

konzentriert arbeitenSo ist es am Arbeitsplatz: konzentrierte Arbeit ist kaum möglich. Die nächste Störung – so gut gemeint sie auch sein mag – ist kaum 5 oder 10 Minuten entfernt. Das zerstört nicht nur Produktivität. Das macht auch Lernen schwer bis unmöglich.

Lernen – jedenfalls bewusstes, gezieltes, effizientes wie effektives und nicht das, was unvermeidlich nebenbei passiert – wird deshalb immer wieder auf später verschoben. Wenn mal Zeit ist. Abends, am Wochenende? Kaum. Das schaffen höchstens Enthusiasten.

Muss man aber gleich Enthusiast und Hochmotiviert oder Selbstausbeuter sein, um schlicht nur uptodate zu bleiben, d.h. seine Arbeitskraft fürs Unternehmen zu erhalten? Wir bei der Clean Code Developer School (CCDS) glauben, nein. Lernen, Weiterentwicklung, Freude durch persönliche Verbesserung sollten nicht nur wenigen vorbehalten sein.

Unternehmen tun sich selbst keinen Gefallen, wenn Sie eine Kultur fördern oder zumindest dulden wie die, die zu der Verzweiflungsaktion mit dem Schild im obigen Bild geführt hat. Unterbrechungen kosten einfach bares Geld. Und Lernbehinderung kostet ebenfalls bares Geld.

Mit der CCDS wollen wir helfen, aus diesem Hamsterrad auszubrechen. Einmal in der Woche 4 Stunden ungestört lernen in einem eigens dafür reservierten (Zeit)Raum: das bringt Fortschritt und Zufriedenheit.

Bildquelle: Twitter

Flipcharts im Titelbild?

Im Titelbild der Homepage der Clean Code Developer School (CCDS) sehen Sie Flipcharts mit merkwürdigen Diagrammen darauf. Was hat das zu bedeuten?

Zuerst dachten wir, es wäre schön, wenn wir Unterrichtssituationen zeigten. Doch dann gefiel uns die Idee noch besser, Arbeitsergebnisse nach vorne zu stellen. Denn das sind die Diagramme: das Ergebnis von Entwurfsarbeit.

In der CCDS glauben wir daran, dass Software korrekter und evolvierbarer wird, wenn man sich vor dem Codieren systematisch Gedanken über ihre Struktur macht. Außerdem kann sie dann auch noch schneller hergestellt werden. Denn aus einer visualisierten Struktur lassen sich Arbeitspakete für mehrere Entwickler leicht herauslesen.

Mit Clean Code Design vermitteln wir eine Methode, die zu solchen Diagrammen führt, die Strukturen beschreiben, die von vornherein zentrale Prinzipien des Clean Code Development (CCD) einhalten.

Dass diese Diagramme mit Papier und Stift entstehen, ist gewollt. Diese einfachen Werkzeuge stehen der Kreativität nämlich am wenigsten im Wege. Sie erlauben flüssige Entwurfsarbeit im Team. Mehrere Entwickler können und sollen am Entwurf arbeiten.

Lesbarkeit über den Moment bzw. das Team hinaus ist dabei nicht so wichtig. Ihnen dürfen die Titelbilddiagramme also ruhig kryptisch vorkommen. Ihre Bedeutung ist zeitlich/räumlich begrenzt gewesen. Aus voller Absicht heraus.

Niemand soll sich nämlich an einen Entwurf hängen und ihn als „heilig“ ansehen. Entwürfe sind nur Visionen, nicht „the real thing“. Ihre Manifestation – der Code – darf und wird von ihnen (in Maßen) abweichen. Die Strukturwahrheit bleibt also im Code. Aus dem muss der Entwurf jederzeit wieder reproduzierbar sein. Die Flipcharts sind also nur flüchtige Spuren eines kollektiven Nachdenkens.

Nichtsdestotrotz sind sie in systematischer Weise entstanden und haben Weisungscharakter für die Codierung. Sie halten die gemeinsame Vorstellung eines Teams von der Struktur eines Softwaresystems in nachvollziehbarer Weise fest.

Das ist uns als Kern professioneller Softwareentwicklung so wichtig, dass wir es zum „Aushängeschild“ der CCDS gemacht haben.

C#, Java, Ruby, PHP & Co

Die Clean Code Developer School (CCDS) richtet sich an Entwickler auf allen Plattformen.

Das primäre Thema der CCDS – die saubere Softwareentwicklung mit den Clean Code Developer Bausteinen – ist plattformneutral.

Auch wenn wir in den letzten 13 Jahren vor allem auf der .NET-Plattform gearbeitet haben, sind wir sicher, Teilnehmer aller Plattformen in diesem Sinne anleiten zu können. Mit zusammen mehr als 60 Jahren Erfahrung in der Softwareentwicklung haben wir gelernt, hinter den Eigenheiten von Sprachen und Frameworks das Fundamentale und Gemeinsame zu sehen. Saubere Softwareentwicklung ist keine Frage von Syntax und modernen Sprachkonstrukten, sondern eine von Prinzipien und Herangehensweise. Clean Code Development dreht sich mehr um Kultur denn um Technik.

Wer spezifischen Rat zu seiner Plattform sucht, sollte nach einem spezifischen Angebot des Plattform-Ökosystem suchen. Wer jedoch allgemeiner seine Softwareentwicklungskompetenz verbessern möchte, der ist bei der CCDS richtig. Selbst wenn wir nicht so vertraut mit einer Plattform oder Technologie sein sollten, können wir immer noch das Üben sinnvoll begleiten. Regelmäßigkeit, Fokus und persönliche Betreuung sind der Schlüssel zum Lernerfolg.

Lösungen für technische Probleme und Hintergründe zu Technologien lassen sich “ergooglen” – wenn man fest auf dem Boden systematischen Lernens steht. Dabei wollen wir mit der CCDS helfen.

Übende aller Plattformen sind uns deshalb herzlich willkommen. Professionelle Entwicklung sauberer Software tut auf allen Not.

Reflektiert Üben

Dass das Lernen in der Clean Code Developer School (CCDS) nicht wie üblich abläuft, haben Sie vielleicht schon anderen Artikeln hier im Blog entnommen. Ein Aspekt sei jedoch noch einmal hervorgehoben: die Bewusstheit.

In der CCDS wird nicht “einfach so” geübt, indem man versucht, Aufgaben abzuarbeiten. Das klappt dann entweder oder nicht. Bei Schwierigkeiten wird ein wenig nachgeholfen.

Vielmehr glauben wir daran, dass zum effizienten Lernen Bewusstheit gehört. Dass gelernt wird, wie gelernt wird, was gelernt wird, gilt es immer wieder zu reflektieren. Erfolge wie Misserfolge sollen nach dem Warum befragt werden. Das hebt Lernen auf die nächste Stufe. Nur so entsteht die viel beschworene deliberate practice.

In der CCDS kommt dafür auch ein recht spezielles Mittel zum Einsatz: das Portfolio.

Welche Aufgaben Teilnehmer angehen, wie sie sie lösen, was sie dabei erfahren und daraus lernen, dokumentieren sie. Es wird also nicht nur munter am Flipchart entworfen und in einer IDE codiert. Nein, es wird hinterher auch darüber geschrieben. Texte, Bilder, Code und andere Artefakte des Lernens werden in einer Mappe gesammelt. Wohlgemerkt in einer physischen Mappe.

Das Portfolio ist nämlich nicht nur ein Mittel der Reflexion, indem Teilnehmer ihre Arbeit beim dokumentieren überdenken. Es ist auch Mittel zur Motivation: eine wachsende Mappe macht den Fortschritt greifbar. Sie zeigt, was schon alles geschafft wurde.

Und das Portfolio ist auch ein Mittel der Präsentation. Mit einem Portfolio kann dem jetzigen Arbeitgeber oder zukünftigen handfest dargestellt werden, dass und was geübt wurde. In anderen Berufen ist das gang und gäbe und dient der Qualitätssicherung. Warum nicht auch in der Softwareentwicklung.

Portfoliolernen ist schon lange für allgemeinbildende Schulen im Gespräch, aber leider nur vereinzelt im Einsatz. Die CCDS greift diese gute Idee auf, um die Erwachsenenbildung zu verbessern.

Bring Your Own Problem

Unterricht findet üblicherweise mit vorgegebenen Aufgaben statt. Das ist didaktisch sinnvoll, weil damit der Zuwachs beim Lernstoff gesteuert werden kann. Und es macht den Unterrichtenden sicherer, weil er das Feld der potenziellen Probleme überschauen kann.

Einerseits ist das verständlich und sinnvoll – andererseits aber wird damit ein Folgeproblem erzeugt, dem sich der Unterrichtende elegant entzieht: der Transfer. Das vermeintlich Gelernte muss im dreckigen Tagesgeschäft angewandt werden. Da passiert es schnell, dass das gekonnt Geglaubte sich sperrt. Es kommt zu unerwarteten Fehlern, es dauert alles länger, die Motivation sinkt. Unter der Trainer ist weit weg.

Das möchte die Clean Code Developer School (CCDS) ändern. Sie bietet für ihre Hauptinhalte zwar auch einen Fundus an vorbereiteten Aufgaben unterschiedlichen Schwierigkeitsgrades. Darüber hinaus ermuntert sie ihre Teilnehmer jedoch, Probleme aus dem Tagesgeschäft mit in den Unterricht zu bringen.

Die CCDS will also aktiv beim Transfer von Clean Code Developer (CCD) Bausteinen in die Praxis unterstützen. Als “Kollegium” sind wir bereit, uns die Hände am Tagesgeschäft der Teilnehmer schmutzig zu machen. Da mag es dann auch für uns mal haken – doch das ist allemal besser, als wenn der Teilnehmer mit dem Problem im Projekt allein dastünde.

Insofern bietet die CCDS nicht nur Training, sondern auch ein Stück Beratung. Wir leiten im Sinne von CCD und im Rahmen des Unterrichts gern die Bewältigung von Aufgaben des Tagesgeschäftes an. Das sind wir den Teilnehmern einfach schuldig, wenn wir es ernst meinen mit der Vermittlung unserer Inhalte. Wir gefährden sonst den Zweck der CCDS.

Also: Wir meinen es ernst mit “Bring your own problem”. Wer als Teilnehmer nur an vorgegebenen Aufgaben werkeln will, verschenkt eine Chance der CCDS und macht sich den Transfer schwerer als nötig.

Angeleitet Üben

Für sich allein zu üben, ist wichtig. Nur dabei erfährt man wirklich seine Grenzen. Das mag frustrieren – doch der Lerneffekt ist dann am größten.

Sich aber zu lang an seinen Grenzen zu stoßen, ohne weiterzukommen, ist der Motivation allerdings abträglich. Auch das Ergebnis leidet schnell, wenn man es dann mit dem Kopf durch die Wand probiert oder in alte Gewohnheiten verfällt.

Deshalb ist es hilfreich für effizientes wie effektives Lernen, einen Ansprechpartner zu haben. Und zwar einen Ansprechpartner mit einer Meinung nicht nur zum Lernstoff, sondern auch zum Lernprozess. Ersteres mögen auch Kollegen bieten, letzteres eher nicht.

Für zügigen Fortschritt ist es jedoch wichtig, den Lernprozess im Blick zu behalten. Sonst verrennt man sich allzu leicht oder über-/unterfordert sich. Zur deliberate practice gehört eben Reflexion.

Das bietet die Clean Code Developer School (CCDS). Hier wird individuell geübt – aber mit Anleitung und Begleitung. Das “Kollegium” ist da, um zu fördern und auch zu fordern. Unterstützung in Fragen zum Lernstoff ist selbstverständlich. Darüber hinaus gibt es allerdings auch Hilfe für den besten Weg durch den Lernstoff.

Die CCDS ist nicht nur daran interessiert, dass die Teilnehmer sich das eine oder andere “draufschaffen”. Sie möchte vielmehr einen Beitrag zur fachlichen wie persönlichen Weiterentwicklung im Allgemeinen leisten. Es geht auch um das Lernen lernen.

Die Schulpforten sind geöffnet

Es geht los!

Wir haben Schulungsraum, Termine und Inhalte festgezurrt und „gehen live“. Die Clean Code Developer School (CCDS) nimmt nun Anmeldungen entgegen.

Ab dem 7. Mai 2013 findet jede Woche am Dienstag Nachmittag von 15:00 bis 19:00 ein Unterrichtsblock von 4 Stunden in München statt.

Schauen Sie sich im Unterrichtsplan an, wie wir mit den Impulsthemen in Clean Code Design und Clean Code Delivery einführen. Und dann überzeugen Sie sich mit einem Blick auf unsere Preise, dass regelmäßiges, fokussiertes, individuelles und angeleitetes Lernen erschwinglich ist.

Wir sind überzeugt, Ihnen mit der CCDS ein innovatives Angebot für nachhaltiges Lernen zu machen.

Bis bald in der Clean Code Developer School!

Ihr CCDS-„Kollegium“