Einmal pro Woche steht ein:e Entwickler:in am Pranger, wird wüst beschimpft, ihr/sein Code wird sprich- und wortwörtlich zerlegt, die Meute tobt und lacht hämisch und am Ende weint immer irgendwer.
Warum wir trotzdem an “Roast My Code” hängen und warum es ganz anders abläuft als hier gerade skizziert, das möchte ich euch diese Woche erzählen.
Was ist Roast My Code?
Roast My Code hat seinen Namen natürlich schon von den diversen Roastings, die es vor allem auf YouTube zu erheblicher Reichweite gebracht haben. Ein Haufen A/B/C-Promis macht einen Abend / eine Show lang Witze auf Kosten einer/eines anwesenden A/B/C-Promis. Das ist mal mehr, mal weniger lustig, aber jedenfalls ist klar, worum (oder um wen) es in dieser knappen Stunde geht.
Bei uns steht weniger die Person im Vordergrund als der Code, den er oder sie mitbringt.
Und es ist auch wahrlich weniger bissig und deutlich über der Gürtellinie im Vergleich zu den namensgebenden Roasts. Jede Woche bringt ein:e Entwickler:in ein Stück Code mit, welchen er uns zeigen will.
Das kann mehrere Gründe haben:
- Man ist stolz darauf und will, dass das die anderen auch sehen
- oder man ist unsicher, ob man einen Task “schön” (wartbar, wiederverwendbar, skalierbar, performant) gelöst hat und will die Meinung der anderen
- oder man will einfach seine Herangehensweise mit den anderen diskutieren.
In den 30-45 Minuten, die wir uns dafür reservieren, wird zuerst kurz die Ausgangslage erläutert und der entsprechende Code hergezeigt. Im Anschluss werden von den anderen Entwickler:innen Fragen gestellt, Ansätze vorgeschlagen, Kleinigkeiten vielleicht auch gleich ausprobiert und generell in das Thema eingetaucht.
Warum machen wir das?
Als wir Roast My Code eingeführt haben, waren wir gerade auf sieben Entwickler:innen gewachsen und merkten, dass wir oft gar nicht wissen, woran die Kolleg:innen arbeiten, geschweige denn, wie sie das tun. Gleichzeitig ist uns wichtig, dass wir hier als Team arbeiten und nicht nur eine Front- oder Backend-Ressource sind, die Dinge abarbeitet. Im Zuge unserer Zieldefinition für 2022 ist dann die Idee für RMC (damals noch RCRC – Random Code Review Club) entstanden. Seither treffen wir uns wöchentlich um gemeinsam zu roasten.
Wie machen wir das?
Da es bei so einem flexiblen Team immer wieder mal vorkommt, dass jemand im Homeoffice ist, war uns wichtig, dass es auch funktioniert, wenn man nur online dabei sein kann. Meist nutzen wir eine Mischung aus klassischem Online-Diskussions-Software, mit der Stimmen und Bildschirme übertragen werden können, und unserer IDE (PHPStorm), die es ermöglicht, sich mittels “Code with me”-Plugin im Quellcode einer Person umzusehen. Das funktioniert meist recht reibungslos und gibt uns genug Spielraum, dass beispielsweise das Frontend direkt im Browser über Screensharing hergezeigt wird, gleichzeitig aber alle Teilnehmer:innen sich auch selbstständig durch den Quellcode in der IDE durchklicken können.
Was bringt’s?
Wie oben schon erwähnt, ist es uns wichtig, uns gegenseitig “zu spüren”. Wir sind ein Team, auch wenn wir an unterschiedlichen Projekten arbeiten. Allein dafür ist es hilfreich, ein bisschen Einblick in die Arbeit der anderen zu bekommen. Aber das ist nicht alles.
<em>Durch den gemeinsamen Blick auf Code definieren wir, wie wir arbeiten wollen.</em> Lukas Kindermann-ZeilingerVISION
Wir leben dadurch auch aktiv eine Fehlerkultur, weil wir Code mitbringen, bei dem wir uns unsicher sind. Wir stärken unser Teamgefühl, denn wir sind froh, wenn wir konstruktives Feedback bekommen oder Ideen, wie das eine oder andere Problem noch besser gelöst hätte werden können. Und es ist erhellend und witzig, als Frontend-Dev mal bei Backend-Themen mitzutüfteln, bzw. umgekehrt natürlich auch!
Als Fazit bleibt mir noch zu sagen: Ja, es ist (meist) weniger vulgär als die Roasts auf YouTube. Dafür aber definitiv lehrreicher, nachhaltiger und ebenso unterhaltsam.
Habt ihr auch Methoden, um mit euren Kolleg:innen in regem, fachlichem Austausch zu bleiben? Teilt sie gern in den Kommentaren!
Du willst mehr über unsere Arbeitsweisen erfahren? Hier erzählt Marion warum wir bei Liechtenecker die Methode des User Story Mappings als Fixbestandteil in unserer Konzeptionsphase vorsehen.
