• Teaser Home

    Clean Code Developer School

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

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.

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.