Was sorgt für eine gute Developer Experience? Die folgenden Themen haben für zahlreiche Entwickler:innen einen erheblichen Einfluss auf ihre Zufriedenheit:
1. Entwickler:innen sind Techniker, sie sollten technische Aufgaben haben
Der Alltag vieler Entwickler:innen sieht leider vollkommen anders aus. Sie müssen an Meetings teilnehmen, bei denen Erkenntnisgewinn und Zeitaufwand häufig in keinem akzeptablen Verhältnis stehen. Zudem sind oftmals Reports zu erstellen oder es soll minutiös protokolliert werden, wofür sie ihre Zeit aufwenden – unter Umständen gar in mehreren unterschiedlichen Erfassungssystemen. Hin und wieder werden erfahrene Entwickler:innen auch gebeten, in Einstellungsgesprächen dabei zu sein. All diese Aufgaben mögen einzeln betrachtet sicherlich ihre Berechtigung haben. Unterm Strich bedeuten sie jedoch einen erheblichen Zeitaufwand, der im Umkehrschluss zu Zeitmangel und Drucksituationen bei der Entwicklungsarbeit führt. Solche Tätigkeiten sollten daher nur einen geringen Teil der Arbeitswoche ausmachen, der überwiegende Anteil der Arbeitszeit jedoch für technische Aufgaben zur Verfügung stehen, nicht umgekehrt.
2. Entwickler:innen möchten nicht ständig mit veralteter Technologie arbeiten
Entwickler:innen gehen auf Konferenzen, tauschen sich aus und sie lesen Magazine. Dort erfahren sie, welche tolle neue Technologien es gibt und woran andere Entwickler:innen arbeiten. Um Frust zu vermeiden, ist es wichtig, allen Entwickler:innen zu ermöglichen, zumindest punktuell auch neue Technologien einzusetzen. Es gibt unterschiedliche Strategien, wie das erreicht werden kann. Bei der Entwicklung von Microservices-Architekturen oder der Aufspaltung von Monolithen ist es beispielsweise möglich, einzelne Services oder Module in neuen Technologien zu implementieren. Unabhängig davon ist es ohnehin wichtig, keine zu großen technischen Schulden aufkommen zu lassen und auch in Wartung befindliche Anwendungssysteme regelmäßig zu modernisieren.
3. Entwickler:innen sollten auch Neues entwickeln, nicht bloß bestehende Systeme warten
Eine noch immer recht verbreitete Unternehmensstrategie besteht darin, neue Systeme von externen Mitarbeitern oder Dienstleistern entwickeln zu lassen, weil diese vermeintlich das nötige Know-how mitbringen. Die Wartung bestehender Systeme geschieht dagegen durch angestellte Entwickler. Das führt früher oder später zu Unzufriedenheit, da es verständlicherweise nur wenig Freude bereitet, immer nur erweitern und reparieren zu dürfen, was andere hinterlassen haben. Der kreative Aspekt der Softwareentwicklung, das Erschaffen neuer Architekturen und Lösungen, geht für diese Entwickler:innen somit fast vollständig verloren. Im Grunde offenbart ein solches Vorgehen bloß, dass in der Vergangenheit versäumt wurde, die eigenen Mitarbeiter fortzubilden. Ein deutlich besserer Ansatz besteht darin, neue Systeme von gemischten Teams entwickeln zu lassen. Idealerweise bestehen diese Teams sogar überwiegend aus eigenen Entwickler:innen, die nur punktuell durch externes Know-how unterstützt werden. Somit sind angestellte Entwickler:innen von Beginn an in die Entwicklung derjenigen Systeme eingebunden, die sie anschließend über längere Zeit warten müssen. Es entsteht zudem ein bestmöglicher Know-how-Transfer.
Stay tuned
Regelmäßig News zur Konferenz und der Java-Community erhalten
4. Entwickler:innen sollten ihre Tools selbst wählen dürfen
Das gilt insbesondere für die IDE. Wenn Tools wie Maven oder Gradle für Builds verwendet werden, ist es letztlich gleichgültig, welche IDE die einzelnen Entwickler:innen einsetzen. Der verbreitete Einwand, dass für gewisse IDEs Lizenzierungskosten anfallen, während andere kostenlos einsetzbar sind, ist zu kurz gedacht. Zum einen sollte es Grund zur Sorge sein, wenn die üblicherweise dreistelligen Lizenzkosten für IDEs vom Arbeitgeber nicht aufgebracht werden können. Noch viel wichtiger aber ist das Argument, dass die Effizienz, mit der Entwickler:innen arbeiten, deutlich höher zu bewerten ist. Berücksichtigt man die Lohnkosten von Entwickler:innen, ergeben sich erhebliche Einsparungen, falls diese mit der von ihnen bevorzugten IDE auch nur fünf bis zehn Prozent schneller arbeiten können als mit einem Konkurrenzprodukt. Es ergibt daher wirtschaftlich wenig Sinn, an eventuellen Lizenzierungskosten zu sparen.
5. Entwickler:innen brauchen schnelle Hardware
Das bedeutet: schnelle Entwicklungsrechner mit ausreichend RAM und schneller Festplatte. Equipment, das bremst, etwa durch langsam laufende Builds oder Tests, ist letztlich deutlich teurer. Doch auch die Performance der Services, die Entwickler:innen täglich nutzen, ist von großer Wichtigkeit. Hierzu zählen etwa Git, Maven oder Docker Repositories, Build-Server, Datenbanken und das Netzwerk. Sind diese langsam oder weisen sie mangelnde Stabilität auf, werden Entwickler:innen unnötig ausgebremst. Erneut gilt: Multipliziert man die Anzahl der Entwickler:innen mit Arbeitstagen und Wartezeiten, können erhebliche Kosten zusammenkommen. Diese sollten eher in die Verbesserung der Infrastruktur investiert werden.
