Was macht eigentlich ein Entwickler bei d.vinci?

Warum uns jede einzelne Position so wichtig ist und warum jeder zum Gesamterfolg der Firma beiträgt, klären wir in diesen Interviews.

Heute stellen wir unseren Entwickler Dennis vor.  

Hallo Dennis! Schön, dass du dir die Zeit nimmst. Stell dich doch mal kurz vor.

Gerne, ich arbeite jetzt seit sechs Jahren bei d.vinci als Softwareentwickler und bin seit drei Jahren (coronabedingt) ungeschlagener Darts-Champion im Unternehmen. In Osnabrück habe ich Technische Informatik und im Master Verteilte Anwendungen studiert. Anschließend wollte ich gerne mal das Arbeiten und Leben in einer Großstadt kennenlernen und bin durch glückliche Fügung auf d.vinci als Arbeitgeber in Hamburg gestoßen.

Was machst du in deiner Position als Entwickler? Worum kümmerst du dich hauptsächlich?

Viele Menschen denken bei einem/einer Entwickler:in zuerst an eine Person, die in einem abgedunkelten Raum vor hellen Monitoren tief in den Programmcode abtaucht. Und ehrlich gesagt mache ich das auch sehr gerne. Aber dieser Job erfordert heutzutage viele weitere Fähigkeiten, da man sich in größeren Teams organisiert und auch übergeordnete planerische Tätigkeiten übernehmen darf. So werden mit dem Product Owner (Produktverantwortlichen) fachliche Anforderungen besprochen. Man stimmt sich mit der IT-Administration über die technische Infrastruktur, mit dem UX-Designer über Bedienbarkeit, Layout und Menüführung sowie mit der technischen Redaktion über die Mehrsprachigkeit ab. Unter den Entwickler:innen muss bei einer gegebenen Anforderung Konsens über eine technische Lösung gefunden werden. Bei der Architekturplanung werden verschiedene Programmstrukturen modelliert. Das macht die Position des/der Entwicklers/Entwicklerin sehr abwechslungsreich. Bei d.vinci hat man des Weiteren die Möglichkeit, sich in verschiedenen Boards zu engagieren, die z.B. nochmal einen genaueren Blick auf die Architektur oder die Sicherheitslandschaft der Anwendungen werfen. 

Du bist ja schon einige Zeit bei d.vinci. Warum wolltest du die Rolle als Entwickler gerne einnehmen? Was schätzt du besonders?

Schon vor d.vinci war ich in unterschiedlichen Entwicklungsabteilungen tätig, in denen oft eine sehr klare Aufgabentrennung herrschte. D.h. jede:r Entwickler:in hat sich mit einem bestimmten Aspekt der Software beschäftigt und musste darüber hinaus schnell Hilfe von anderen Kolleg:innen anfordern. Bei d.vinci gibt es nicht nur flache Hierarchien, auch ist es gewünscht, dass jede:r Entwickler:in sich mit allen Aspekten der zu entwickelnden Software beschäftigt. Dies braucht ein wenig mehr Einarbeitungszeit, allerdings können somit auch alle Entwickler:innen bei einem Thema mitreden, unterstützen, prüfen und den übergeordneten Nutzen der Anwendung verstehen. Natürlich gibt es immer Personen, die sich auf diesem oder jenem Gebiet besser auskennen, da sie länger an bestimmten Themen gearbeitet haben, aber dieses allgemeine Vorgehen der Wissensteilung schätze ich sehr.

Gibt es auch mal Herausforderungen oder Situationen, die dich als Entwickler länger beschäftigen?

Einzelne Aufgaben im Arbeitsalltag sollten uns Entwickler:innen nach Möglichkeit nicht zu lange beschäftigen. Die Entwicklung bei d.vinci arbeitet nach dem Scrum-Vorgehen. Dabei wird iterativ in Sprints geplant, die bei uns jeweils ein Zeitraum von 14 Tagen haben. Vor jeden Sprint wird von Entwickler:innen und Product Owner geschätzt, was in den nächsten zwei Wochen geschafft werden kann und anschließend werden für die ermittelte Kapazität entsprechende Tasks (Aufgaben) aus dem Backlog (priorisierte Aufgabenliste) ausgewählt. Diese Tasks sind z.B. Kundenwünsche wie neue Funktionen, technische Verbesserungen oder auch mal das Beheben eines Bugs. Wichtig ist, dass diese Tasks so klein geschnitten und strukturiert geschrieben werden, dass sie innerhalb des Sprints geschafft werden können. Das hat den Grund, dass der Aufwand kleinerer Tasks besser abgeschätzt werden kann und ein:e Entwickler:in nicht an einem „Fass ohne Boden“ programmiert. Sollte ein Task doch mal länger in der Umsetzung dauern oder unvorhergesehene Hürden enthalten, wird im Team schnell Hilfe angeboten und nach einer guten Lösung gesucht.

Es gibt aber auch übergeordnete Aufgaben, die uns Entwickler:innen länger beschäftigen. Neben den Kundenwünschen nach bestimmten Funktionalitäten muss auch immer ein bestimmtes Augenmerk auf die technische Infrastruktur gerichtet werden. Gerade bei der Einführung neuer Produkte müssen wir detailliert abwägen, welche Technologien und Programmiersprachen wir einsetzen möchten. Dabei wird z.B. erwogen, wie lange die Technologie eingesetzt werden soll, wie sie sich zu anderen bestehenden Technologien verhält, oder ob unsere Entwickler:innen effizient mit dieser arbeiten können. Um diese Fragen kompetent beantworten zu können, ist es deshalb auch Teil des Jobs, sich kontinuierlich weiterzubilden.

Wie profitieren unsere Kunden und Kolleg:innen von deiner Rolle als Entwickler?

Auch wenn unsere Kunden oft wenig direkten Kontakt zu unserer Entwicklungsabteilung haben, sind wir essentiell an der Entstehung aller d.vinci Softwareprodukte beteiligt. Der Kunde profitiert durch unsere Software, wenn sie auch wirklich einen Mehrwert bringt und in der täglichen Arbeit unterstützt. Deshalb ist nicht nur der Dialog zwischen Entwickler:in und Produkt Owner wichtig. Wir erhalten z.B. auch viel Feedback der Kunden über den Customer Service oder aus dem Vertrieb. Durch diese Kommunikationswege können wir auch die anderen Abteilungen unterstützen. Welche Funktionalitäten helfen dem Vertrieb um unsere Software noch attraktiver zu machen, womit können wir dem Customer Service die Arbeit erleichtern?

Was sind deine wichtigsten Arbeitsinstrumente als Entwickler?

Eigentlich sind in der Entwicklung alle Arbeitsinstrumente digital, aber ich kann gerne mal einen kurzen Einblick geben, was da so alles auf unseren Monitoren flimmert. Besonders hervorzuheben ist die Entwicklungsumgebung. Das ist das Programm, mit dem wir den eigentlichen Programmcode schreiben und zum Testen auf unseren Rechnern starten. Eng mit der Entwicklungsumgebung gekoppelt ist eine Versionsverwaltung. Damit wird jeder Zustand des Programmcodes als eigene Version abgespeichert. Jede Version kann wieder aufgerufen werden, falls etwas nicht wie gewünscht funktioniert. Auch kann man Code-Änderungen zwischen den einzelnen Versionen sehen, um z.B. die Änderungen eines/einer Kollegen/Kollegin freizugeben. Des Weiteren haben wir ein Ticketsystem, mit dem wir sehen können, wer gerade wo etwas macht. Unsere aktuellen Tasks und die genauen Anforderungen können wir darin aufrufen. Wir haben unterschiedliche Programme um auf Datenbanken, Logging- oder Übersetzungs-Dateien zuzugreifen. Auch haben wir eine Vielzahl an Browsern und Tools installiert, um die Darstellung der Produkte unter verschiedenen Bedingungen zu prüfen. Für jede Funktionalität in den Anwendungen programmieren wir technische Tests. Diese Tests werden bei jeder Codeänderung durch ein eigenständiges System in Hintergrund ausgeführt, um zu prüfen ob durch Seiteneffekte unwissentlich keine anderen Funktionen in der Anwendung beeinträchtigt wurden. Das Internet ist für Recherche sicherlich auch ein wichtiges Arbeitsinstrument. Und natürlich Visualisierungswerkzeuge, wie sie wahrschlich viele Menschen im Homeoffice für Meetings verwenden. Ich habe noch einige weitere Programme auf meinen Rechner, aber die sind hauptsächlich für seltenere Anwendungsfälle.

Was machst du, wenn du „Baustellen“ erkennst? Wie gehst du da heran?

Es ist glaube ich immer zu unterscheiden, auf welcher Ebene diese Baustelle auftaucht. Setze ich eine kleine Codeänderung um und treffe auf ein Hindernis, hilft oft schon ein Kaffee, logisches Denken oder eine kurze Recherche im Internet. Ist die Baustelle eher fachlicher Natur oder hat sie größere technische Auswirkungen wird mit den Kolleg:innen und dem Product Owner eine gemeinsame Lösung erarbeitet. Um unvorhergesehene Baustellen zu vermeiden und um das Verständnis über die Aufgaben zu stärken gibt es im Rahmen der Sprints auch Plannings, bei denen gemeinsam alle Tasks vor Arbeitsbeginn besprochen werden.

Erzähl mal: Wie sieht ein klassischer Arbeitsalltag von dir aus? Gibt es Dinge, die sich wiederholen oder ist jeder Tag anders?

Da unsere Entwicklungsabteilung nach dem Scrum-Vorgehen arbeitet, gibt es ein paar formelle Termine wie Plannings, Reviews und Retrospektiven, die über den Sprint fest im Kalender gesetzt sind. Auch haben wir feste Termine, an denen wir die neuste Version unserer Software für unsere Kunden zugänglich machen. Das ist meistens nach Abschluss eines Sprints. Wir haben unterschiedliche Teams in der Entwicklung, die sich momentan um jeweils verschiedene Produkte kümmern. Jedes Team muss seine beste Arbeitsweise finden. Mein Team hat im Moment täglich ein Zeitfenster von einer Stunde geblockt, um sich im Team quer über alle täglichen Themen auszutauschen. Das erspart einzelne Termine, die einen immer wieder aus der Programmierarbeit reißen. In der Firma sind wir in einem Großraumbüro organisiert, in dem wir mit dem Schreibtischstuhl mal schnell zu einem/einer Kollegen/Kollegin rollen können, um dort zu helfen. Oder Informationen werden am Kicker oder in der Kaffeeküche ausgetauscht. Im Homeoffice wird dieses hauptsächlich durch spontane Videoanrufe ersetzt. Sind alle Termine durchgeführt, kommt man wieder zur Haupttätigkeit, dem eigentlichen entwickeln.

Wie sieht dein Arbeitsplatz aus? Gibt es typische Dinge, die deinen Schreibtisch ausmachen und zu deiner Arbeit gehören oder dich privat besonders gut beschreiben?

Jeder Mensch gestaltet seinen Arbeitsplatz unterschiedlich. Ich mag den Gedanken, dass alle meine Arbeitsinstrumente digital sind. Ich kann meinen Laptop an irgendeiner Stelle aufklappen und schon steht meine Arbeitsumgebung bereit. Im Büro habe ich für meinen Laptop externe Monitore und weitere Eingabegeräte. Aber sowohl im Büro als auch im Homeoffice ist im Grunde alles sehr aufgeräumt und in einem guten Sinne ersetzbar.