Wir haben einen Code-Retreat ausprobiert

Letzten Monat habe ich bei unserer monatlichen Treffen eine Code Retreat geleitet. Lass uns darüber sprechen, was gut war, was schlecht gelaufen ist, und was wir mitnehmen konnten. Ja, es ist die beliebteste Sprint-Zeremonie aller Zeiten: Es ist Zeit für eine Retrospektive!

Ein Code Retreat ist eine eintägige Aktivität, bei der die Teilnehmer das Handwerk der Softwareentwicklung üben, indem sie in Zweiergruppen an einem bestimmten Problem arbeiten (typischerweise eine Implementierung von Conway's Game of Life). Der Tag ist in mehrere Sitzungen aufgeteilt, wobei die Teilnehmer in jeder Sitzung mit anderen Personen zusammenarbeiten und unterschiedliche Vorgaben erhalten, um sie zu neuen Denkweisen anzuregen. Am Ende jeder Sitzung löscht jeder den Code, den er in dieser Sitzung geschrieben hat, wir alle reflektieren die Erfahrung, diskutieren, was wir beim nächsten Mal anders machen könnten, und dann beginnt jeder die nächste Sitzung mit einem anderen Partner und anderen Einschränkungen.

Ich habe das auf der c't 2024 bei einem Vortrag von Wolfram Kriesing und Marco Emrich kennengelernt und wollte es seitdem unbedingt ausprobieren. Als wir also über Aktivitäten für den monatlichen Hackathon im Januar sprachen, schlug ich es vor und wir probierten es aus.

Wie haben wir das gemacht?

Code Retreats haben eine vorbereitete Struktur, die es relativ einfach macht, sie zu organisieren. Es gibt Moderationsleitfäden, die online verfügbar sind, und jede Menge Ratschläge und Ressourcen in verschiedenen Blogs und auf anderen Websites. Der Grundgedanke besteht darin, die Teilnehmer in jeder Runde dieselbe Aufgabe erledigen zu lassen, was ihnen einen Teil der Arbeit abnimmt. Die wichtigsten Punkte, die ich vorbereitet habe, waren die Einführung, in die Struktur des Tages, die Funktionsweise der testgetriebenen Entwicklung und die Regeln von Game of Life.

Wir hatten an diesem Tag einige Einschränkungen, die die Einhaltung der normalen Struktur erschwerten. Normalerweise dauert unser Arbeitstag von 8:30 bis 17 Uhr, aber unsere Hackathons beginnen in der Regel um 9 Uhr, und wir versuchen, uns zwischen 15 und 16 Uhr final auszutauschen. Am Ende konnten wir aufgrund anderer Probleme nur drei Sitzungen abhalten, statt der üblichen fünf oder sechs. Wir hatten auch nur fünf Teilnehmer, so dass ich am Ende sowohl Moderator als auch Teilnehmer war, um die Anzahl auszugleichen.

Außerdem handelte es sich um eine firmeninterne Veranstaltung, im Gegensatz zu einem normalen Code Retreat, bei dem Leute aus verschiedenen Unternehmen und Arbeitsorten zusammenkommen. Das bedeutete, dass wir uns bereits gut kannten und dass wir uns nicht allzu viele Gedanken über die Wahl der Sprache oder der Werkzeuge machen mussten - wir sind eine Typescript-Firma, also war es ganz natürlich, diese neben Vitest und VS Code zu verwenden. Dass wir alle aus dem gleichen Umfeld kamen, war ein Vorteil, aber möglicherweise auch ein Nachteil, da wir wahrscheinlich nicht so unterschiedliche Ansätze hatten, wie wenn wir mit Leuten aus ganz anderen Bereichen der Softwareentwicklung gearbeitet hätten. (Obwohl ich überrascht war, wie unterschiedlich unsere verschiedenen Ansätze manchmal waren!)

Was lief gut?

Das Format des Code Retreats sieht viel Zeit für Retrospektiven vor, und wir haben am Ende des Tages auch unsere Eindrücke über das gesamte Format diskutiert. Einer der positiven Aspekte, der in diesen Retrospektiven zur Sprache kam, war der Aspekt des Pair Programming. Da wir oft an unterschiedlichen Themen arbeiten, haben wir nicht so häufig die Gelegenheit, gemeinsam zu programmieren, wie wir es gerne hätten - wir versuchen, regelmäßig Herausforderungen miteinander zu besprechen, aber wir setzen uns seltener zusammen und programmieren gemeinsam. Es war eine schöne Abwechslung, auf diese Weise zusammenarbeiten zu können.

Auch die Herausforderung, Game of Life zu implementieren, hat uns viel Spaß gemacht, vor allem in der letzten Runde, in der wir einige Regeln geändert und untersucht haben, wie das Spiel auf einem hexagonalen Raster gehandhabt werden kann. Es ist toll, die Möglichkeit zu haben, ein wenig zu experimentieren und Code zu schreiben, den wir normalerweise nicht schreiben würden, und das in einem Kontext, der sich von unserer täglichen Arbeit unterscheidet.

Was hätte besser laufen können?

Das Ziel eines Code Retreats ist es, sich auf den Prozess des Codeschreibens zu konzentrieren und nicht auf das Endziel. In der Praxis haben wir uns als Gruppe sehr schnell darauf konzentriert, das Endziel zu erreichen, nämlich eine funktionierende Game of Life-Implementierung. Im Laufe des Tages stellten wir fest, dass wir uns eher auf die „Zeit für eine funktionierende Implementierung“ konzentrierten, als verschiedene Architektur- und Entwicklungstechniken auszuprobieren.

Ich glaube nicht, dass dies etwas besonders Schlechtes ist: Das Ziel der Entwicklung ist es normalerweise, den einfachsten und kürzesten Code zu schreiben, der ein bestimmtes Problem löst, und in der Praxis haben wir uns oft darauf geeinigt - sehr einfache Abstraktionen, einfach zu handhabende Datenstrukturen und einfacher Code. Dadurch bekamen wir aber keine Gelegenheit, komplexere Fähigkeiten zu üben, wie z. B. das Erstellen von Abstraktionen um kompliziertere Datenstrukturen herum.

Für uns hätte eine andere Aufgabe, die nicht so einfach zu lösen war oder mehr offene Möglichkeiten bot, besser funktioniert. Alternativ hätte es uns vielleicht besser gefallen, eine spezifischere Fähigkeit wie Refactoring zu üben und eine Aufgabe zu haben, die sich mehr darauf konzentriert (z. B. Gilded Rose oder Trivia).

Fazit

Ich genieße unsere monatlichen Hackathons, denn sie sind eine gute Gelegenheit, mich ein wenig auszutoben und etwas zu tun, was ich normalerweise nicht ausprobieren würde. In diesem Fall war die Möglichkeit, diese Art von Workshop zu leiten, neu für mich, und das Herumspielen mit Game of Life war eine gute Abwechslung zu meiner täglichen Arbeit.

Für uns hat das Format des Code Retreats jedoch nicht sehr gut funktioniert. Es war trotzdem ein nützlicher Tag, und wir haben viel gelernt, aber beim nächsten Mal werden wir wahrscheinlich einen anderen Ansatz versuchen.