Samstags 10 vor 9 einen Parkplatz in der Dieselstraße zu bekommen, ist kein Problem. Ich steige aus und freue mich darauf, die 53 Menschen kennen zu lernen, die heute am Global Day of Code Retreat in den Schulungsräumen der Fiducia & GAD teilnehmen wollen. Toll zu wissen, dass heute in den USA, in China, Indien und in vielen anderen Ländern sich genauso wie hier Menschen zum weltweiten Programmiertag treffen.
Ausgerüstet mit meinem Laptop und Entwicklungsumgebung mit Programmiersprache meiner Wahl betrete ich Saal 1 im FAZ, wo sich schon die ersten mit Kaffee und Butterbrezeln stärken. Von diesen erfahre ich, woher sie kommen, ob sie zum ersten Mal da sind und wie sie vom GDCR erfahren haben. Später in der Mittagspause werde ich noch mehr Zeit haben, mit den Einzelnen zu reden.
Um 9.30 Uhr beginnt es offiziell mit Begrüßung, Organisatorischem und dem Erklären der Aufgabe von heute: Wir sollen die Geschäftslogik von dem bekannten Spiel „Vier gewinnt“ implementieren. In jeder der fünf Sessions programmieren wird dieselbe Aufgabe, variiert durch je ein „Constraint“ – eine Übungsvariante.
Für die Zusammenstellung der Programmierpaare für die erste Session stellen wir uns nach der Anzahl teilgenommener GDCRs auf und teilen uns dann so auf, dass diejenigen mit viel Vorkenntnissen mit jemand mit wenigen Vorkenntnisse zusammenarbeiten.
Mein erster Partner programmiert Kotlin. Das passt prima, denn diese Sprache wollte ich eh mal kennen lernen, da meine Freundin mir davon schon vorgeschwärmt hat.
Ich finde es recht viel auf einmal mit den vielen Infos zu der für mich neuen Programmiersprache und der fremden IDE. Ich versuche mir die Shortcuts zu merken, denn ich weiß, dass damit effizienter und schneller programmiert und die Programme damit fehlerfreier überarbeitet werden können.
Allerdings brauchen wir erstmal mehr Zeit als erwartet, bis alles eingerichtet ist und wir uns über die genaue Aufgabe, Vorgehensweise und Programmiersprache genauer ausgetauscht haben. Daher bleibt gar nicht mehr so viel Zeit für den ersten Constraint „ohne Maus“ zu arbeiten.
Mein Partner der 2. Session ist ein Kollege der Fiducia & GAD aus einer anderen Abteilung, den ich davor noch nicht kannte. Mit Java und dem Constraint Test-Driven-Development (TDD) klappt es ganz flüssig. Mit dieser Technik können gut testbare und schnell lesbare Programme in kleinen Schritten erstellt werden. Hierbei entstehen maschinelle Tests mit extrem hoher Codeabdeckung. Ein Kollege hat mir berichtet, dass in seinem Team die Ticketanzahl durch maschinelle Tests stark reduziert werden konnte. Ich selbst habe erlebt wie ich eine große Klasse in meinem Themengebiet mit TDD wesentlich übersichtlicher und damit schneller erweiterbar gestalten konnte.
In den weiteren Sessions stelle ich fest, dass hier bei dieser Veranstaltung der Softwerkskammer jeder sein Handwerk beherrscht, denn alle meine Programmierpartner verwenden TDD ohne dass wir uns deswegen groß abstimmen müssen. Ich finde es sehr hilfreich, eine Vorgehensweise zu haben, um zügig und gezielt mit jemand Fremden mit der Implementierung loszulegen.
Damit auch Neulinge mit gut ausgestattetem Werkzeugkasten an den Start gehen können, wurde zu Beginn TDD nach Kent Beck in 3 Schritten erklärt. Die offene und konstruktive Atmosphäre hilft dies praktisch umzusetzen. Wer trotzdem noch Fragen hat, kann sich jederzeit an einen der 4 Coaches wenden, die sehr hilfsbereit, freundlich und echte Meister in ihrem Fach sind!
In der Pause lerne ich T. kennen. Sie arbeitet in Pforzheim, hat viele Kollegen in Indien und kommt gerne zum GDCR, da sie sich hier mit anderen Programmierern vor Ort austauschen kann.
In der 3. Session schlägt sie vor, dass ich doch gleich die Tastatur übernehmen soll, obwohl ich die Sprache Python noch gar nicht kenne. Sie ist die perfekte Navigatorin und führt mich toll in die für mich neue Sprache ein. Ungern gebe ich dann die Tastatur an sie ab, weil es so gut klappt. Der Constraint keine primitiven Datentypen zu nutzen, ist gar kein Problem. Über die Vorteile, mehr Objekte zu verwenden, unterhalten wir uns in der großen Runde in der anschließenden Retro.
Beim Mittagessen in der Kantine habe ich die Möglichkeit mich mit den verschiedenen Programmierern zu unterhalten.
Gegenüber von mir links sitzt C. aus einem großen bekannten Unternehmen, der dort erst vor ein paar Wochen den Bereich gewechselt hat. Das Thema Testautomation liegt ihm in seiner neuen Abteilung besonders am Herzen.
Mir gegenüber sitzt eine Physik-Studentin, die nach dem erst kürzlich abgeschlossenen Studium überlegt, ob sie in die Softwareentwicklung einsteigen soll. Natürlich erwähne ich gleich, dass die Fiducia & GAD neue Mitarbeiter sucht!
Rechts daneben sitzt ein langjährig erfahrener Mitarbeiter. Früher war er eine Zeitlang in der Qualitätssicherung tätig, nun ist er wieder in der Entwicklung mittendrin dabei und erzählt mir von seinen Erfahrungen in den verschiedenen Abteilungen.
Nach der Mittagspause möchte ich noch die Programmiersprache Go anschauen, denn schließlich hat mir letztes Jahr ein Kollege begeistert davon erzählt. Als mein Programmier-Partner erfährt, dass wir nun in Baby-Steps von 2 Minuten programmieren sollen, fragt er mich, ob wir das wirklich mit der für mich neuen Programmiersprache probieren sollen oder ob ich nicht doch lieber Java nehmen möchte. Aufgrund der positiven Erfahrung mit dem Baby-Step-Partner letztes Jahr, der immer total ruhig und cool geblieben ist, entscheide ich mich für Go.
Mein Partner legt gleich mit dem ersten Test los und schafft diesen tatsächlich in den 2 Minuten. Nach dem Committen legen wir erstmal das Smartphone mit der Stoppuhr beiseite und er erklärt mir die Grundlage dieser Sprache. In meinem ersten Versuch schaffe ich es selbst nicht, als ich das nächste Mal drankomme – dank seiner guten Anleitung – dann doch. Bald stellen wir fest, dass wir für den nächsten Test den Schritt wesentlich kleiner wählen müssen, um es in 2 Minuten hinzubekommen. Allmählich haben wir es raus, wie groß – genauer gesagt – wie klein die Schritte sein müssen und ich bekomme es nun auch in 2 Minuten hin! Wow, und das in einer fremden Sprache!
Nicht nur große Elefanten sollte man vor dem Verspeisen in Scheiben schneiden. Das ist auch mit kleinen Mäusen notwendig, wenn die Zeit eng bemessen ist! Und erst recht sollte man das Aufteilen der Problemstellung fürs Programmieren üben!
In der Abschlusssession wird es wieder einfacher: In Java programmieren wir Methoden, die maximal 3 Zeilen haben dürfen. Mit Hilfe von Eclipse geht es ganz schnell, den Code in eine neue Methode zu extrahieren, wenn diese zu groß wird. Wir kommen recht zügig voran.
Ich weiß, wenn auch in der Praxis darauf geachtet wird, dass die Methoden klein sind, bleibt der Code übersichtlich und Erweiterungen sind schneller und damit kostengünstiger.
Während ich an einer Stelle überlege, ob dieser Schritt nicht zu groß ist, scheint meine Programmierpartnerin meine Gedanken erraten zu haben und spricht genau dies aus. Diese Gedankenübertragung muss daran liegen, dass sie – wie ich – aus dem Schwäbischen kommt!
Abends um 18 Uhr lasse ich die zusätzlichen Trainingsgewichte an Händen und Füßen – die Constraints – im Trainingszentrum zurück, gehe mit gestärkten Programmierer-Muskeln zum Auto und freue mich schon auf den GDCR im nächsten Jahr!
Ein großes Dankeschön an die Softwerkskammer für die inhaltliche Gestaltung und an die Fiducia & GAD für Hosting und Sponsoring!