Global Day of Code Retreat 2013 @München / E.S.R Labs

Ich habe am 14.12.2013 am Global Day of Code Retreat teilgenommen. Hier sind meine Eindrücke.

Start in den Tag war ab 8:15, ich war ab 8:30 vor Ort. Es gab ausreichend Kaffee und und Frühstück. Viele Teilnehmer waren bereits genauso früh vor Ort.

Geleitet wurde der Tag von Sebastian Benz, den ich auch von der Softwerkskammer kenne.

Worum geht es beim CodeRetreat.

Als Softwareentwickler steht man quasi ständig unter Zeitdruck. Der Kunde möchte eine Funktionalität geliefert haben, einen Bug gefixt haben und das möglichst noch heute. Während ich etwas implementiere habe ich oft das Gefühl, dass unter der Oberfläche eine noch bessere Lösung schlummert. Wenn ich nur ein bisschen mehr Zeit investieren könnte… Und in diesem Moment kommt von Kundenseite die nächste Anfrage, wie lange es denn noch dauert.

Kurzum, wenn wir unsere Arbeit mit der eines Rockstars vergleichen. Wir Softwareentwickler stehen quasi ständig auf der Bühne, haben aber niemals Zeit zu proben und zu üben. Und dabei ist es gerade in unserem Beruf enorm wichtig, seine Fähigkeiten zu trainieren und zu schulen (siehe Code Kata).

Ein Retreat ( ein sich Zurückziehen) gibt uns genau die Möglichkeit zu machen, wofür wir tagtäglich keine Zeit und keine Möglichkeit haben. Dinge auszuprobieren, mit neuen Programmiersprachen zu arbeiten, mit fremden Entwicklern in Pairs zu arbeiten ohne dabei gestört zu werden (naja, vielleicht bis auf die letzten Session, aber dazu später mehr).

Wichtig – egal mit welcher Problemstellung gearbeitet wird – Ziel ist es nicht, das Problem zu lösen. Ziel ist es, perfekten Code zu schreiben und möglichst viel zu lernen. Selbst wenn nur eine einzige Zeile perfekter Code pro Session geschrieben wird ist das völlig in Ordnung.

Ablauf

Ich habe nicht durchgezählt, aber ich schätze dass gut 30 Entwickler teilgenommen haben.

Der Tag ist unterteilt in 6 verschiedene Sessions, in der immer und immer wieder das Gleiche Problem mit leicht veränderten Constraints gelöst wird. Das Problem was an diesem Code-Retreat gelöst wurde ist der Klassiker schlechthin – Convays Game of Life.

Das war für mich ganz spannend, da zum Einen die meisten anscheinend wirklich sehr vertraut mit dem Problem sind (manche sogar zu vertraut) und ich das Game of Life das letzte Mal im zweiten Semester programmiert hatte, was gute 10 Jahre her ist.

Nach jeder Session wird der Code unwiderbringlich gelöscht, was je nach Lösung wirklich hart sein kann. Diese Regel ist eisern und erlaubt (bis auf eine Ausnahme) keine Ausnahme.

In jeder Session (wieder bis auf eine Ausnahme) wird in verschiedenen Pairs gearbeitet, um möglichst viele unterschiedliche Eindrücke zu bekommen.

Session 1 – Get to know the Problem

In der ersten Session wurden keine bestimmten Constraints vorgegeben. Es gilt quasi, sich zunächst mit der Problemstellung vertraut zu machen und zu versuchen, das Problem zu lösen.

Programmiersprache: Java
Umgebung: IntelliJ
Lernfaktor: Ich musste mich wirklich erst nocheinmal mit dem Problem vertraut machen.

Session 2 – Ping Pong Pairing

In dieser Session sollten wir versuchen, Strict TDD zu üben. Einer schreibt den Test, der Andere schreibt die Implementierung. Einer schreibt den Test…

Programmiersprache: Java
Umgebung: IntelliJ
Lernfaktor: Pair-Programming funktioniert, Ping-Pong finde ich ein interessantes Konzept. Mich würde interessieren, ob das jemand auch im richtigen Leben einsetzt

Session 3 – Evil muted Programmer

Die meiner Ansicht nach beste Session des Tages. Es war verboten, mit seinem Pairing-Partner zu sprechen. Kommuniziert wurde nur über den Code. Gearbeitet wurde quasi wieder im Ping-Pong Modus. Der “Gute” gibt einen Test vor, der “Böse” implementiert den Test, aber nur so, dass er gerade eben mal grün wird.

Programmiersprache: Java
Umgebung: IntelliJ
Lernfaktor: Ich war der Gute. Mein Partner hatte es zu Beginn sehr leicht, meine Tests zu sabotieren. Je mehr Tests aber da waren, desto schwieriger wurde es. Irgendwann musste tatsächlich auch Logik implementiert werden. Trotz der Constraints haben wir es geschafft, das Game of Life in dieser Session abzuschliessen. Sehr beeindruckend.

Session 4 – Be as fast as you can

In dieser Session sollte so schnell wie möglich gearbeitet werden. Keine Vorgaben ob Tests zu schreiben sind, wie implementiert wird. Hauptsache, das Game of Life ist so schnell wie möglich implementiert.

Programmiersprache: C#
Umgebung: Visual Studio
Lernfaktor: C# sieht wirklich gut aus und gefällt. Wir haben versucht, das Game of Life Objektorientiert zu lösen und da wir schnell sein wollten – ohne Tests:). Schön zu sehen, nachdem wir angenommen hatten fertig zu sein mussten wir trotzdem Tests schreiben um zu verifizieren, ob die Implementierung wirklich funktioniert. Leider hatte sich ein Fehler eingeschlichen, so dass die Regeln nicht funktioniert haben. Hätten wir Tests von Anfang an geschrieben hätte zum Einen unsere “API” besser ausgesehen und wir hätten den Fehler viel schneller bemerkt. Wir mussten leider mitten im Umbau aufhören, so dass wir eine unfertige Implementierung zurücklassen mussten.

Nach dieser Session sollte der Code nicht gelöscht werden!

Session 5 – Refactor this mess

In der vorherigen Session sollte der Code nicht gelöscht werden, da jetzt der Rechner einfach an das nächste Paar weitergereicht wurde. Und diese sollten unseren Code refactoren und verbessern. Zugegeben, sie hatten keine leichte Aufgabe.

Was mich sehr erstaunt hat waren die Kommentare von einem der beiden, der sich fürchterlich über unsere Implementierung aufgeregt hat. Ich weiß, dass derjenige sehr viel Erfahrung mit Code-Retreats, Katas und auch mit dem Game of Life hat. Er hatte aber offensichtlich vergessen, dass der Tag für Experimente da ist und keinesfalls für fertige Implementierungen.

Andererseits war dies die wirklich falsche Session für Experimente..

Programmiersprache: Java
Umgebung: Eclipse
Lernfaktor: Ich habe einen komplett neuen Ansatz kennengelernt, wie das Problem gelöst werden kann (mit einem endlosen Board). Diese Lösung ist mit Sicherheit nicht in dieser Session entstanden, da sie sehr ausgereift war.

Session 6 – Dictator

Letzte Session des Tages war Dicator. Es gab keine Vorgaben wir gearbeitet werden sollte. Sebastian ging aber durch die Reihen in der Rolle des Architekten-Diktators und hat fleissig Zettel auf die Bildschirme geklebt, was denn refactored werden muss und was nicht gut ist. Es war uns nicht erlaubt, weiterzuarbeiten bis die angeprangerten Refactorings durchgeführt wurden.

Programmiersprache: Java
Umgebung: Eclipse
Lernfaktor: Es stört unglaublich, wenn jemand von aussen vorgibt, was man wann zu tun hat. Wir waren mitten in einem Test als der Dictator von hinten kam und eine viel zu lange Methode angeprangert hat. Interessanterweise hatte mein Pairing-Partner eine Lösung anprogrammiert die ich so noch nicht kannte und die ich auch nicht auf Anhieb durchblicken konnte. Es war also doppelt schwer, Code zu refactoren für den Diktator und gleichzeit noch zu verstehen, welche Lösung wir anstreben.

Fazit

Der Tag war interessant und lehrreich. Ich würde aber beim nächsten Mal ein wenig besser vorbereiten. Ich habe viel zu viel Zeit verschwendet, die verschiedenen Möglichkeiten des Game of Life zu verstehen als auf den eigentlichen Sinn des Tages. Mein Tipp – wieso wird das Problem nicht vorher bekannt gegeben? Nicht jeder programmiert das Game of Life einmal die Woche und ist damit vertraut. Ich würde mich an diesem Tag gerne auf andere Dinge konzentrieren und nicht auf die Implementierung des Algorithmus.

Effective Trainings & Consulting - Martin Dilger



Hat Ihnen dieser Blog-Eintrag gefallen? Ich stelle in diesem Blog Informationen über Tools, Frameworks und Werkzeuge zur Verfügung, die mich produktiver machen. Vielleicht kann ich auch Ihnen helfen, produktiver zu werden.


Ich unterstütze Sie als freier Mitarbeiter bei der Entwicklung von Software-Projekten, Agiler Arbeit sowie Schulungen / Fortbildungen.


Jeden Tag ein bisschen produktiver - ab heute