Diese Woche ist die letzte Woche bei meinem aktuellen Arbeitgeber. Meinem ersten "echten" Arbeitgeber. Meinem Arbeitgeber, bei dem ich auch meine Ausbildung gemacht habe. Das ist jetzt ca. 5 1/2 Jahre her.
Angefangen mit etwas Erfahrung aus einer SHK-Stelle als Entwickler und viel Enthusiasmus. In diesen fünf Jahren hat sich eine Menge getan - technisch in der .NET-Welt (.NET Core, .NET Standard, Xamarin, ...) aber vor allem in meiner Einstellung zum Job des Entwicklers. Wie die meisten Neulinge denkt man ja, es sei besonders wichtig, "toll programmieren" zu können. Besonders clevere Inkantationen von Methoden-Aufrufen ineinander zu verschlängeln und bloß keine Zeile zuviel zu virtuellem Papier zu bringen.
Während sich das noch relativ schnell gibt und man sich bemüht, Code zu schreiben, den die Kollegen auch reparieren können, kommt die eigentliche Einsicht erst mit der Zeit. Die Einsicht, die einem jeder bestätigen wird, der schon ein paar Jahre beruflich im Team entwickelt: Das eigentliche Programmieren ist gar nicht der essentielle Part des Jobs eines Entwicklers. Die wichtige Kompetenz eines Entwicklers ist die Kommunikation. Diese Kommunikation findet auf mehreren Ebenen statt:
Code: Durch Code kommuniziert man Absicht. Wenn ich meinen Code so strukturiere, dass sich allein aus der Abfolge der Aufrufe erkennen lässt, was er tut, dann tut der nächste Kollege sich leichter, in meinen Code einzuarbeiten.
Dokumentation: Zumindest bei uns war es gang und gebe, dass die Kollegen von Professional Services und Support zu uns kommen und sagen "sag mal, kann man eigentlich ...?" und die Antwort war natürlich: "Steht alles genau in der Entwickler-Doku". Ok, schlechter Witz. Entweder kann der Entwickler noch aus dem Kopf sagen, was das Programm eigentlich machen oder man nuschelt die berüchtigten Worte "ich guck mal kurz im Code nach". Dokumentation ist immer ein leidiges Thema, das irgendwie niemandem so recht Spaß macht (jedenfalls von den Leuten, die ich bisher getroffen habe). Ich merke gerade diese Tage, wo ich Übergaben meiner Entwicklung und Projekte an Kollegen mache, wie wichtig gute Dokumentation wäre. An vieles erinnere ich mich noch - zumindest was das Konzept angeht. Ganz viel ist aber auch in den Tiefen des SVN-Logs versteckt - wenn überhaupt.
Gespräche mit Nicht-Entwickler-Kollegen: Wir entwickeln unseren Code ja nicht im leeren Raum. In meinem alten Job habe ich Software für's Kanalmanagement geschrieben. Bevor ich da angefangen habe, hatte ich keine Ahnung von Siedlungswasserwirtschaft und was alles daran hängt. Wenn man aber keinen Kontext hat, in dem man seine Lösungen implementiert, dann wird man die eigentlichen (oft ungenannten, weil selbstverständlichen) Anforderungen des Kunden / des Anwenders nie zu 100% treffen. Ganz oft kann man Zeit und Nerven sparen, wenn man mit seinen Kollegen, die sich fachlich auskennen, mal über das neue Feature spricht, was das eigentlich soll und wie die Kunden das einsetzen.
Gespräche im Entwickler-Team: Eigentlich auch eine Selbstverständlichkeit sollte man denken. Leider nicht überall. Oft kam's mir in meinem alten Job vor, als würde ich völlig alleine arbeiten und nur alle zwei Wochen (wenn gepatcht wurde) in Kontakt mit meinen Kollegen treten. Ganz so schlimm war's natürlich nicht (man sieht sich ja zwangsweise, wenn man im selben Büro arbeitet), aber eine echte Team-Atmosphäre kam nicht auf. Was dann dazu führt dass Feature A zwei Wochen Entwicklungszeit benötigt an deren Ende man von einem Projektmanager hört "das haben wir doch letztes Jahr für Kunde X schon so ähnlich gemacht". Neben der also vermeidbaren Doppel-Arbeit spart man sich aber auch viel Aufwand, wenn man seine Features mal mit den Kollegen daraufhin abklopft, in welchem anderen Kontext die noch einsetzbar wären.
Zu all diesen Punkten könnte man ganze Bücher schreiben (und erfahrenere Entwickler als ich haben das auch schon), ich will's hier an dieser Stelle erstmal dabei belassen.
Für mich geht's nächste Woche weiter mit einem neuen Buch - das ich hier schreiben möchte. Dieses hier schließe ich mit diesem Epilog (und vielleicht einem Epi-Epilog, mal sehen, was noch so aufkommt, wenn ich erstmal fertig bin).