Aus dem Alltag eines Entwicklers

Was ist eigentlich dein Beruf?

Wenn mich Leute, die nicht viel mit der IT-Branche zu tun haben, nach meinem Beruf fragen, so ist die Antwort nicht immer ganz einfach. Die offizielle Bezeichnung des Java Entwicklers fällt meistens weg, weil hier vorausgesetzt würde, dass mein Gegenüber die Programmiersprache kennt. Was hingegen besser passt, ist wohl der Begriff Software-Entwickler. Er ist in Bezug auf die Programmiersprache neutral gehalten, was sinnvoll ist, weil kaum ein Java-Entwickler nur Java benutzt. Außerdem ist er semantisch leicht verständlich. Ein Software-Entwickler ist jemand, der Software entwickelt. Doch was genau heißt das in der Praxis und wie sieht dieses „Entwickeln“ eigentlich aus?

Um dieser Frage, die wohl jeden small talk sprengen würde, aus dem Weg zu gehen, läuft es dann in der Regel darauf hinaus, dass ich mich als Programmierer vorstelle. Ein Titel, der sich meiner Erfahrung nach hartnäckig in der Alltagssprache hält, weil er Nicht-ITlern immer noch die beste Vorstellung davon gibt, was ein Entwickler macht. Doch gleichzeitig ist es ein Titel, den man nur zähneknirschend ausspricht, weil er den Berufsstand auf einen einzigen, wenn auch sehr wichtigen, Teilaspekt reduziert.

Software-Entwickler von heute

Ein Arbeitskollege sagte vor einiger Zeit bei einer Diskussion zu diesem Thema: „Sogar Affen können programmieren.“ Natürlich ist das bei allem Respekt vor der Intelligenz dieser Lebewesen eine Übertreibung. Aber diese Aussage spiegelt gut wider, wie der Software-Entwickler von heute sich selbst sieht bzw. wie er nicht gesehen werden will: Als reiner Code-Schreiber. Und dies absolut zurecht, denn die klischeehafte Vorstellung vom weltfremden Nerd, den man bloß nicht in einen Geschäftstermin mit Kunden schicken sollte, ist weit weg von der heutigen Realität. Software-Entwicklung im Dienstleistungssektor ist eine vielseitige Tätigkeit und erfordert mehr als nur geschickten Umgang mit Nullen und Einsen.

Kontakt zu den Kunden

Um das zu verdeutlichen, kann man sich beispielsweise die Tatsache bewusst machen, dass man als Dienstleister ein hohes Maß an Empathie und Kommunikationsstärke an den Tag legen muss. Man hat in der Regel täglich Kontakt zu Kunden und muss in der Lage sein, Gespräche mit Nicht-Informatikern zu führen und deren Perspektive (zum Beispiel die vertriebliche Sichtweise) zu verstehen. Neuanforderungen und Wünsche des Kunden an das Software-Produkt müssen zudem vom Entwickler verstanden und ihrem Aufwand nach beurteilt werden. Ob eine Sache einfach und kostengünstig zu realisieren ist oder viele Arbeitsstunden erfordert, ist oft nicht intuitiv und ohne Kenntnis des Bestandscodes nachvollziehbar. Hier ist es wichtig, dass ein Entwickler Probleme verständlich und ohne technische Spitzfindigkeiten transportieren kann.

Was will der Kunde vs. was braucht der Kunde

Wirklich spannend wird unsere Arbeit auch in dem Moment, wo sich das, was der Kunde will, von dem unterscheidet, was er eigentlich braucht. Hier eröffnet sich für den Entwickler dann die Möglichkeit den Weg eines Beraters einzuschlagen und auf Basis seiner Erfahrungen mögliche Optionen aufzuzeigen. Gleichzeitig ist es aber auch eine Glaubensfrage: Gebe ich dem Kunden genau das, was er will und fahre damit Umsatz für mein Team ein? Oder schlage ich eine Alternative vor, die möglicherweise schneller implementierbar ist und entsprechend weniger kostet, mich aber langfristig als kompetenten Berater beim Kunden platziert? Es liegt im Ermessen des Entwicklers und macht seine Arbeit vielschichtig.

Prozesstreue vs. Zugeständnisse

Gleichermaßen großen Spielraum bietet Software-Entwicklung auch in Bezug auf das Einhalten von Prozessen. Damit meine ich keinesfalls, dass man sich nicht an Regeln halten muss, sondern vielmehr, dass man ein Gespür dafür entwickelt, in welchen Situationen man dem Kunden entgegenkommt und in welchen man strickt nach Protokoll vorgeht. Ein Beispiel hierfür wäre der Umgang mit Anforderungen, die sich erst im Laufe der Bearbeitung ergeben haben bzw. von der ursprünglichen Aufgabenstellung abweichen. Strenggenommen müssen solche Anforderungen in einem eigenen Ticket ausformuliert, in ihrem Aufwand geschätzt und für den nächsten Sprint eingeplant werden – also kurz gefasst durch den gesamten Prozess wandern. Das kostet natürlich Zeit. Und daher ist es nicht verwunderlich, dass es wohl kaum einen Entwickler gibt, der nicht schon mal „ein Auge zugedrückt“ hat.

Eine Kleinigkeit obendrauf, wenn man ohnehin schon an einer großen Implementierung arbeitet, schadet wohl nicht und man verdient sich das Wohlwollen des Kunden. Ein Entwickler, der auch mal spontan eingreift, um Hindernisse aus dem Weg zu schaffen, kommt gut bei jedem Product Owner an. Doch schnell können sich die Zugeständnisse häufen und im schlimmsten Fall entsteht eine Ticket-Kultur, die Anforderungen nach Belieben am Prozess vorbeischleust. Hier greift dann wohl die Kleiner-Finger-ganze-Hand-Redensart, weshalb ein Abweichen vom Prozess immer zumindest gut überlegt sein sollte.

Die soziale Komponente des Entwickler-Alltags

Solche und viele andere Entscheidungen sind Teil des Entwickler-Alltags und bringen eine soziale Komponente in die Welt der Algorithmen, die nicht zu unterschätzen ist. Natürlich bleibt alles in allem das „Coden“ die Schlüsselkompetenz des Entwicklers. Wer keine Freude daran hat Algorithmen zu schreiben oder Quellcode nach Bugs zu durchforsten, der kann den Beruf nicht ausüben. Dabei zeigen aber heutige Berufsbezeichnungen wie zum Beispiel Software-Architekt oder Software-Ingenieur, dass Komplexität und Verantwortlichkeit innerhalb des Berufstands deutlich zugenommen haben. Auch Bewegungen wie Software Craftsmanship sind darum bemüht, das Bild des mündigen Software-Entwicklers mit Beratungs- und Führungs-Kompetenz zu stärken. Mir ging es in diesem Beitrag aber vor allem darum, aufzuzeigen, dass sich auch im zwischenmenschlichen Bereich – sozusagen zwischen den Code-Zeilen – bei unserer Arbeit viel bewegt.