Ich bin später als die meisten meiner Kolleg*innen zur Softwareentwicklung gekommen. Während viele von ihnen Schulen besucht haben, die gezielt auf eine Zukunft als Entwickler*in ausgerichtet waren, habe ich ein ganz normales Gymnasium besucht, mit Kurs auf Studium und Forschung. Dieser spätere Einstieg bedeutete, dass ich in mancher Hinsicht aufholen musste, brachte mir aber auch einen anderen Blickwinkel: Ich habe Softwareentwicklung als Erwachsener gelernt, ohne die selbstverständlichen Grundannahmen, die entstehen, wenn man mit dem Feld aufwächst. Zusammen mit meiner Erfahrung als ausgebildeter Pfadfinderleiter hat das geprägt, wie ich über Feedback denke; ich musste mir selbst ein Gespür dafür erarbeiten, wann Feedback wirklich hilfreich ist und wann nicht. Genau dieses Bedürfnis, das Warum und nicht nur das Was zu verstehen, vermisse ich oft im Feedback, das ich zu meinem Code bekomme.
Wenn man als Softwareentwickler*in anfängt, muss man zwangsläufig irgendwann anfangen, Code zu schreiben. Bevor man aber einfach "auf main pusht", sollte man vielleicht jemanden vorher über den geschriebenen Code schauen lassen. Also öffnet man einen PR ("Pull Request"). Damit können Kolleg*innen den geschriebenen Code anschauen und ihn entweder freigeben oder Änderungen einfordern. Änderungen einzufordern ist der Normalfall. Der eigene Code ist beim ersten Versuch fast nie perfekt. Die reviewende Person hinterlässt dann Kommentare dazu, was geändert oder verbessert werden könnte, meist in etwa in der Art von Das sieht nicht ganz richtig aus, probier's mal so, zusammen mit einem Codebeispiel. Das ist einigermassen hilfreich, denn man kann schliesslich keine Gedanken lesen und weiss nicht von selbst, was der reviewenden Person nicht gefallen hat.
Aber als Neuling, als jemand ohne viel Erfahrung im Schreiben von Code oder im Umsetzen von Features, ist Nachvollziehbarkeit alles. Nach einem Review bleibe ich oft mit Fragen zurück: Warum ist meine Lösung nicht passend? Warum ist die vorgeschlagene Änderung die bessere Lösung? Wie ist die reviewende Person überhaupt auf ihre Lösung gekommen?
Es gibt auch seltene Fälle, in denen der eigene Code "perfekt" ist. Die reviewende Person schaut sich den Code an und findet nichts zu bemängeln. Super! Ein Sieht gut aus!-Kommentar, PR freigegeben. Das hilft nicht weiter. Oft habe ich hart an einem neuen Feature gearbeitet, und wenn es sofort freigegeben wurde, habe ich mich in dem Moment richtig gut gefühlt. Aber wenn ich etwas Zeit verstreichen liess, merkte ich, dass ich aus diesem Feature eigentlich nichts gelernt hatte. Ja, ich habe Code geschrieben und er war "gut", aber was heisst das überhaupt? Warum wurde der PR freigegeben? Was war gut an dem Code, den ich geschrieben habe? Hätte die reviewende Person es genauso gemacht, wenn sie das Feature selbst umgesetzt hätte?
Die Feedback-Kultur in diesem Bereich wirkt oft lösungsorientiert statt bildungsorientiert. Das funktioniert gut zwischen Personen mit ungefähr gleichem Erfahrungsstand, die sich die fehlende Begründung selbst zusammenreimen können. Aber es funktioniert nicht mehr, wenn die Person auf der anderen Seite ein Junior ist. Deshalb würde ich mir von jeder Person, die den Code eines Juniors reviewt, Folgendes wünschen: Es ist eure Aufgabe, eure Entscheidungen nachvollziehbar zu machen und Laien zu erklären. Erklärt eure Zweifel, begründet eure Lösungsvorschläge, verweist auf Blogposts oder Tutorials, die neue Konzepte erklären, und versucht, uns verständlich zu machen, warum etwas in eurem Kopf funktioniert oder nicht funktioniert. Das mag im Moment mühsam erscheinen, erspart euch aber viele erneute Lösungsvorschläge in der Zukunft und hat den zusätzlichen Vorteil, dass wir als Entwickler*innen wachsen. Aussagekräftiges und lehrreiches Feedback zu geben ist das Wichtigste, was ihr für Junior-Entwickler*innen tun könnt.
