Developer: Entwickler arbeiten schon. Aber sie coden nicht nur

Warum auch hart arbeitende Programmierer gar nicht so viel produktiven Code schreiben, wie man denken könnte.

Artikel von Emanuel Kessler veröffentlicht am 1. Mai 2023, 9:00 Uhr

Arbeit als Developer kann durchaus anstrengend sein, ohne dass massenhaft Code dabei rauskommt. (Bild: Thomas Geider auf Pixabay)

"Wir arbeiten nicht. Null." Der Entwickler Emmanuel Maggiori hat kürzlich eine große Diskussion mit einem Erfahrungsbericht aus der US-Tech-Branche ausgelöst. Darin behauptet er, dass in dortigen Tech-Konzernen praktisch nicht gearbeitet werde. Aus Deutschland kenne ich das so krass nicht – das mag am Land liegen, an den Firmen, in denen ich gearbeitet habe, oder an unterschiedlicher Wahrnehmung. Dennoch fragen sich auch hierzulande viele: Warum kommen bei acht Stunden Arbeit am Tag so wenige Zeilen Programmcode raus?

Die kurze Antwort ist: Programmieren ist mehr als Coden und das muss auch so sein. Um einen militärischen Vergleich zu bemühen – von Clausewitz schrieb in seinem Buch Vom Kriege: "Der Soldat wird ausgehoben, gekleidet, bewaffnet, geübt, er schläft, isst, trinkt und marschiert, alles nur, um an rechter Stelle und zu rechter Zeit zu fechten." Moderner steht es in den Prinzipien des Agilen Manifests. Eines seiner zwölf Prinzipien besagt: "Funktionierende Software ist das wichtigste Fortschrittsmaß." Jede Tätigkeit, die diesem Ziel dient, hat dementsprechend einen Wert.

Bei Entwicklern gehören mindestens sieben Aufgabenbereiche zur Kernarbeit, und das in einer idealen Welt. Ideal bedeutet in diesem Fall: ohne Stundenzettel oder Derivate, Betriebsversammlungen nach § 43 BetrVG und Ähnliches, also ohne all die Störungen im Arbeitstag, die in Unternehmen notwendig sind. Fangen wir mit dem Offensichtlichen an.

Code und guter Code

Zum Entwickeln gehört natürlich das, was viele als ihre eigentliche Arbeit betrachten: das Coden. Ich definiere es als Code schreiben, der in Produktion die gestellte Aufgabe korrekt erledigt. Oder noch besser: guten Code schreiben, der in Produktion die gestellte Aufgabe korrekt erledigt. Denn es gibt einen großen Unterschied zwischen Code und gutem Code.

Ein erster, sichtbarer Unterschied ist oft die Länge. Häufig ist guter Code deutlich kürzer als schnell hingeschriebener Code. Meiner Erfahrung nach ist es zeitintensiver, eine Aufgabe mit wenigen Codestatements zu lösen als mit vielen. Beim Refactoring passiert es manchmal, dass es am Ende weniger Codezeilen gibt als am Anfang.

Deswegen halte ich auch die Idee für absurd, diejenigen aus dem Entwicklungsteam zu entlassen, die den wenigsten Code geschrieben haben, wie es bei Twitter wohl geschah. Der Golem.de-Autor Rene Koch schrieb dazu sehr richtig: "Qualität geht immer vor Quantität und ein Code hat stets den Anspruch, eine hohe Softwarequalität zu erreichen."

Und ja, zum Coden zähle ich sowohl das Refactoring als auch das Debuggen und die Dokumentation. Diese Schritte sind natürlich vor allem dann notwendig, wenn bekannt oder wahrscheinlich ist, dass der Code sich noch mal ändern wird – weil Anforderungen sich ändern, wegfallen oder dazukommen oder weil die Technologie sich ändert. Bei Code, von dem vorher klar ist, dass er sich nie ändert (z. B. ein Prototyp, der im Nachgang gelöscht wird), ist ein anderes Vorgehen möglich.

Diese generische Definition kommt ohne die Nennung einer Programmiersprache aus. Das Beschriebene gilt für viele aktuelle Sprachen. Gleichzeitig gibt es je nach Sprache Besonderheiten, die eine Beschreibung auf Detailebene schwierig machen. Diese Definition enthält auch keine Arbeits- oder Vorgehensweise. Auch wenn ich, wie alle, meine Vorlieben und Abneigungen habe, dem Code in Produktion ist egal, wie er entstanden ist – solange er nur funktioniert.

Zum Programmieren gehört aber mehr als das (gute) Coden, nämlich all die Tätigkeiten, die notwendig sind, um die Programmieraufgaben zu lösen.