Viele Programmierer, und gerade gute, schaffen einfach alles, heißt es. Und alleine Projekte zu schultern, ist das tägliche Brot vieler Entwickler. Dabei sollte alles dafür getan werden, Programmierern die oftmals viel zu harte Arbeit zu erleichtern und den viel zu hohen Druck zu reduzieren. Dazu müssen automatisierte Deployments und Tests her. Alles andere führt geradewegs in den technischen und gesundheitlichen Untergang. Allerdings sparen Unternehmen leider oft an der Gesundheit und Lebensqualität ihrer Entwickler.

Klar ist: Gute und junge Entwickler, zwischen 20 und 30, wollen was bewegen, Verantwortung übernehmen und die meisten Tickets durchbringen. Sie wollen die Anerkennung der Senior-Entwickler erhalten. Doch irgendwann im Leben verschiebt sich das. Da will man lieber effizient arbeiten und weniger Zeit am Schreibtisch verbringen. Auf kluge Weise faul sein, indem man etwas schreibt und nutzt, das einem Arbeit abnimmt, und hierbei in erster Linie zuverlässig liefern – ohne Bugs. Sonst machen einen ineffiziente Abläufe und stetig steigender Druck auf Dauer mürbe und krank.

Deswegen gehört Arbeitgebern, die aus "Spargründen" auf veralteten, nicht standardisierten Applikationen beharren oder automatisiertes Testing ausklammern und somit die Gesundheit ihrer Arbeitnehmer aufs Spiel setzen, der Rücken gekehrt. Möglicherweise hilft man ihnen auf diese Weise gar und bringt sie dazu, eines Tages doch noch den Kurs zu ändern – indem sie die stetige Abwanderung von Mitarbeitern zur Einsicht und Selbstreflexion bringt.

Transparenter Arbeitsaufwand durch Tickets sind ein Muss

Tickets schützen nicht vor chaotischen Arbeitsbedingungen und hohem Druck. Aber sie bilden Arbeitsaufwände transparent ab. So sieht man, was gerade gemacht wird und was noch zu bewältigen ist. Das klingt banal und selbstverständlich, ist aber noch lange nicht der allgemeine Zustand. Denn viel zu viele kleine Dinge werden in Projekten einfach nicht erfasst, und gerade auf sich selbst gestellte Programmierer laufen dann Gefahr, unter der zunehmenden Last erdrückt zu werden.

Wenn es hier keine Einsicht gibt und ein Projekt auf Biegen und Brechen zu retten ist, dann muss Hilfe her, um sich selbst zu retten. Entwickler sollten transparente Arbeitsaufwände einfordern und sich nicht immer wieder auf kaum zu haltende Deadlines einlassen. Es gilt, einfach auch mal nein zu sagen, wenn etwas in der "von oben" angedachten Zeit schlichtweg nicht zu schaffen ist, ohne größere Kollateralschäden an Qualität und bei der Gesundheit nach sich zu ziehen. Zumal oft gar nicht mal so viel passiert, wenn man nicht pünktlich liefert.

Denn genau das ist das Problem. Weil man nicht nein sagt, kommt es dazu, dass man verheizt wird. Entwickler sind gefragt und viel wert. Sie dürfen in der Prozesskette und den Entscheidungen nicht immer hinten nachgestellt sein. Kunden dürfen nicht einfach sagen, dass was in der Hälfte der Zeit fertig sein müssen und dann alle kuschen, weil es sonst eine andere Agentur macht.

Problem ist außerdem, dass Dinge wie Instandhaltung und Infrastruktur nicht bezahlt werden. Ja, ganze Deployments werden teilweise nicht abgerechnet und automatisierte Tests nicht bezahlt.

Legacy Fighter: Refactoring – alles andere ist sinnlos

Agile Programmierer sagen oft zum Spaß, dass in Zeiten von Microservices jede Methode mit mehr als einer Zeile Code schon Legacy sei. Das hat zumindest einen wahren Kern: Weniger Code ist mehr. Es darf aber auf keinen Fall die Lesbarkeit vernachlässigt werden.

Trotzdem muss man Code immer wieder verbessern. Das hat zwei ganz wesentliche Gründe: Zum einen weil man nicht aus dem Stegreif perfekten Code abliefern kann. In den ersten Schritten – und auch wenn man seinen Code geplant hat –, probiert man ja zunächst, nach dem Prinzip "try, error, debug" eine Funktionalität herzustellen. Zum anderen kommen äußerliche Einflüsse hinzu: Tagesform, Stimmung im Büro, Druck und nicht zuletzt die persönliche Motivation. Daher ist ein zweiter Blick wichtig, und der geschieht am besten im Team. Ziel ist es, Code einfach mal etwas aufzuräumen und zu verbessern. Dann wird er gut, lesbar und wartbar.

"Wissen statt glauben" – mit realen Daten von Anfang an

Leider wird in Projekten oft halbherzig gearbeitet. Das betrifft vor allem Livedaten und -umgebungen. In der Produktion kann das auf der Zielgeraden katastrophale Folgen haben, die sich, wären sie im Vorfeld erkannt worden, in Ruhe und ohne Chaos hätten bearbeiten lassen. Doch insbesondere die Datenmenge und ihre tatsächlichen Eigenschaften werden häufig zu wenig oder gar nicht betrachtet. Dabei kann man solche Modelle nicht einfach nur hochrechnen und bei einem Import nicht beliebig die Laufzeit erhöhen und hoffen, dass alles gut geht. Das gilt ebenso für die Ausgabe.

Bestimmte Requests, beispielsweise für Übersichtsseiten, können und müssen auch nicht alle voll aufgelösten Eigenschaften für die jeweiligen Datensätze holen. Hier ist es keine gute Idee, einfach nur darauf zu vertrauen, dass man alles mit einem Caching rausholt. Denn zu glauben ist nicht wissen, und langsame Applikationen sorgen nun einmal für ernste Probleme und Frust.

Da sich Daten ständig ändern – und das nicht nur einmal pro Nacht, ist es umso wichtiger, fehlerhafte oder falsche Informationen sofort korrigieren zu können. Das muss gewährleistet sein, denn etwa ein falscher Preis kann nicht 24 Stunden auf ein Update warten. Das Gleiche gilt für Headlines und viele andere Inhalte.

Ein gutes Projektmanagement besorgt die Daten daher so früh, wie es nur irgendwie geht. Und wenn die Daten noch nicht vollständig vorhanden sind, ist eben ein Puffer von mindestens einer Woche für das Projekt einzubauen. Alles andere ist riskant, gefährlich und verantwortungslos.

Automate All the Things: Automatisierungen und Tests nutzen

Alle Dinge, die sich automatisieren lassen, sollten auch automatisiert abgebildet werden – vor allem Tests. Investieren Unternehmer indes nicht in eine solche Infrastruktur, sparen sie am falschen Ende. Denn so erhöhen sie in Projekten den Zeitaufwand und belasten durch die zusätzliche Arbeitszeit und Unzuverlässigkeit. Schlechte Softwarequalität bringt Kunden und den eigenen Mitarbeitern kein Vertrauen. Die Folge sind Eskalationen, die sich negativ auf das Projekt auswirken. Mitarbeiter kommen unzuverlässiger zur Arbeit, feiern krank und bauen viel Frust auf. Die Folge sind Ängste, Zwangsgedanken, Vermeidungsverhalten, Depressionen, Burn-out, psychosomatische Beschwerden und all die anderen Symptome von Stress und dauerhafter Überforderung. Die Folge ist, dass Arbeit nicht mehr locker von der Hand geht und die nervliche Belastung zunimmt. Das macht auf Dauer krank und niemand dankt es einem – ein Teufelskreis.

Die Entscheider in Unternehmen und Agenturen tun somit gut daran, an dem Punkt für mehr Nachhaltigkeit zu sorgen und mehr Verantwortung zu übernehmen. Das für automatisierte Tests benötigte Know-how ist zunächst einmal zu erarbeiten und aufzubauen, was einen langfristigen Prozess erfordert. Auch gibt es hierbei keine einfache Fertiglösung, die alle projektspezifischen Probleme auf einen Schlag löst. Aber die Investition lohnt sich spätestens mittelfristig. Denn Projekte werden dadurch planbarer und verlaufen reibungsloser, da die Entwickler effizienter arbeiten können und nicht wieder und wieder auf der Zielgeraden überbelastet werden.

Aus Sicht der Programmierer sind automatisierte Test noch aus einem weiteren Grund vorteilhaft: Das entsprechende Wissen ist wertvoll und auf dem aktuellen Arbeitsmarkt gefragt. Insofern lohnt sich die Weiterbildung hierzu. Außerdem machen automatisierte Prozesse viel Spaß und motivieren, was wiederum für Arbeitgeber von Interesse ist, auch um sich im Markt als guter Arbeitgeber zu positionieren

Ziele vereinbaren, um gute Vorsätze umzusetzen

Gute Vorsätze gibt es selbstverständlich auch in der IT. Damit es keine leeren Versprechen bleiben, sind Ziele gemeinsam zu vereinbaren. Geht es dabei aber um Softwarequalität, ist auf beiden Seiten der innere Schweinehund oftmals das größte Hindernis, mit der Folge, dass wichtige und nötige Änderungen gerne aufgeschoben werden. Deswegen muss die Geschäftsführung dafür Sorge tragen, dass die Ziele erreicht werden. Und sie darf die Verantwortung nicht in die Teams tragen, da diese in der Regel ohnehin schon am Limit produzieren und nicht noch mehr schaffen können.

Softwarequalität ist außerdem nichts, das man mal eben so an einem Freitagnachmittag einführt. Vielmehr gilt hier als Faustregel, dass dafür mindestens 20 Prozent der Wochenarbeitszeit, also etwa ein ganzer Tag pro Woche, zu investieren sind, und zwar über mehrere Monate. Sonst kommt man aus dem Sumpf nicht raus. Wenn sich Programmierer jedoch über Jahre nicht aus diesem Sumpf befreien konnten, sollten sie schleunigst die nötigen Konsequenzen daraus ziehen und sich nach einem anderen Arbeitgeber umsehen. Sonst droht ein Burn-out.

Auf die eindeutigen Signale hören, bevor es zu spät ist

Ein Burn-out, also medizinisch gesprochen eine Anpassungsstörung, bedeutet vor allem, dass man sich in einer Stresssituation nicht mehr richtig verhalten kann. Umgangssprachlich sagt man auch, dass man "weich" wird. Das ist ein schleichender Prozess, der sicherlich nicht von heute auf morgen kommt.

Hier eine Auflistung eindeutiger Signale, die der Autor bei Befragungen betroffener Entwickler eruieren konnte:

zwanghafte Hatz: Es geht morgens direkt los. Kein Prüfen von E-Mails, kein persönliches Hochfahren, sondern einfach nur rein in den Code. Kein Austausch mit Kollegen, keine Schwätzchen, keine Menschlichkeit. Das wirkt sich auch auf die Persönlichkeit und darauf aus, wie Kollegen einen wahrnehmen. Wenn man also plötzlich auf der Arbeit keine Freunde mehr hat und nicht locker ist, dann ist das ein sicheres Zeichen für den falschen Kurs und eine starke Schieflage.

Code ballern, also ohne Planung und Abstand in einen Try-Error-Modus fallen.

Immer unter Strom und sehr angespannt produziert man stundenlang und am Stück immer neuen Code. Dabei räumt man nicht mehr auf, sondern läuft nur noch dem Ziel des Fertigwerdens hinterher. Kein Refactoring, kein In-sich-gehen und keine Reflexion. So entsteht schlechter Code: Legacy-Code, der auch nur einen ganz kleinen Blickwinkel abdeckt und mögliche Eventualitäten nicht mehr beachtet. Also viel Code mit wenig Struktur und für Fehler anfälligen Funktionen.

Lieber alleine coden und am besten keine zweite Meinung zu seinem Code wollen. Das Ergebnis ist einem einfach peinlich.

"Jetzt nicht, vielleicht später ...": Wenn man so in seinem eigenen Tunnel und der eigenen Welt gefangen ist, geht man diesen Weg leider allein und einsam. Alle angebotene Hilfe wird abgelehnt – oder der Gegenüber auf später "vertröstet". Dadurch entfernt man sich immer mehr vom rettenden Ufer. Da draußen kann einem sprichwörtlich keiner mehr helfen. Hier sind auch die Kollegen und Vorgesetzten gefragt: Wenn sich einer da draußen in einem Projekt verheizt, dann sollten sie helfen, selbst wenn er die Hilfe zurückweist.

Trinken und Essen: Wenn man unter hohem Druck arbeitet, blendet man alles aus, auch menschliche Bedürfnisse. Elon Musk zum Beispiel, der Macher hinter Tesla und ein echtes Arbeitstier, hätte gerne auf Hunger und Essen verzichtet, damit er mehr Zeit für Arbeit gehabt hätte. Das kann allerdings längst nicht jeder. Somit ist es wichtig, seinen Körper und seinen Geist fit zu halten. Das ist insbesondere für Programmierer elementar. Um ausreichend Wasser zu trinken und besser auf der Arbeit zu funktionieren, kann man sich einen Reminder einrichten. Es gilt, auf die Signale des Körpers zu achten. Sonst setzt man in einem schleichenden Prozess die Gesundheit aufs Spiel.

Stress in der Webentwicklung: darüber sprechen und sich helfen lassen

Häufig erstellen Programmierer alleine und mit leisem oder lautem Fluchen irgendwas, das ein ganz bestimmtes Ergebnis verfolgt. Wie der Weg dorthin verläuft und wie lange er dauert, wird dabei nicht weiter beachtet. Hauptsache, es läuft. Das führt zu einem großen Ärgernis und nagt am Selbstbewusstsein. Man hat Angst, den Anschluss zu verpassen, weil man scheinbar einfache Dinge nicht mehr hinbekommt. Insgesamt bringt das leider niemanden weiter.

Hier dürfen sich gerne die Entwickler angesprochen fühlen, die sich nicht auf Community-Events rumtreiben und sich überwiegend in Soloprojekte einbringen. Entwickler sollten sich gegenseitig schützen, helfen und gerade in Fällen (zu) hohen Arbeitsaufkommens zusammenstehen. Wichtig ist es, die Probleme offen anzusprechen.

Gute Arbeitgeber sehen hier eine Chance, sowohl die Arbeitsbedingungen als auch die Software zu verbessern. Transparenz ist eben wichtig. Entwickler wollen ja gute Arbeit leisten, und dafür brauchen sie gute Arbeitsbedingungen, gute Arbeitgeber und gute Laune. Sie sollten sich demnach nicht in seelischen oder technischen Problemen vergraben.

Wachsam bleiben und sich über seelische Gesundheit informieren

Die hier besprochenen Probleme betreffen nicht nur die IT. Aber weil nach außen mimmer wieder nur neue Rekorde kommuniziert werden und gesagt wird, wie viel Geld denn verdient wird und dass es der Branche durch die gute Auftragslage so gut geht, werden die Probleme oftmals als Luxusprobleme bezeichnet.

Tatsächlich sind viele Arbeitnehmer in Deutschland betroffen, und zwar quer durch alle Branchen. Beispielsweise ergab eine Umfrage der pronova BKK aus dem Jahr 2018, dass sich jeder zweite Bundesbürger von Burn-out bedroht fühle. Die Leute sind unter anderem ständig erschöpft und ausgebrannt. Schlimmstenfalls können die Folgen über Monate und Jahre anhalten und krankheitsbedingte Ausfälle nach sich ziehen. Und irgendwann geht es recht schnell um Berufsunfähigkeit und damit um Existenzen.

Und in der IT nimmt der Druck weiter zu. Es gibt zunehmend mehr Aufträge, größere Anforderungen und dafür zu wenig Nachwuchs. Dadurch stehen ITler mit dem Rücken zur Wand, bedroht von Deadlines. Wenn agile Methoden wie Scrum falsch angewendet werden, passiert das dann alle zwei Wochen. Dswegen ist es ratsam, sich mit den Themen "seelische Gesundheit", "Burn-out" und "nachhaltige Arbeitsbedingungen" zu befassen.

Pausen an der frischen Luft – ohne Handy und offline

Stress zieht sich durch – man arbeitet zu lange und zu verbissen. Die Körperhaltung ist nicht mehr natürlich und angespannt. Kein Lächeln, keine Wahrnehmung mehr außerhalb des "Tunnels". Man trinkt zu wenig, der Kopf läuft heiß, und es wird zunehmend anstrengender. Das dürfte den meisten sowieso bekannt sein. Wenn man zum Beispiel die PlayStation hochfährt, kommt ein Warnhinweis, man möge nach 45 Minuten Spielzeit eine Pause von 15 Minuten einlegen. Warum sollte das bei kreativer Arbeit am Bildschirm anders sein?

Außerdem sollte man sich zwischendurch auch mal bewegen. Steharbeitstische sind zwar ein großer Fortschritt, aber es ist unabdingbar, auch mal draußen an der frischen Luft zu sein. Das vor allem offline – einige Stunden am Tag ohne Handy unterwegs zu sein, tut gar nicht weh. Man verpasst nichts, und es entspannt den Kopf. Spaziergänge in der Mittagspause sind empfehlenswert. Gleiches gilt für den Abend. Eine halbe Stunde spazieren zu gehen wirkt Wunder.

Never Code Alone

Beizeiten eine Therapie zu machen, ist ebenfalls sicherlich hilfreich, und es gibt Therapeuten, die sich sogar gut mit Dingen aus der Welt der Entwicklung auskennen. Wichtig ist aber vor allem, den Dialog mit Seinesgleichen zu suchen. Es gibt tolle Jobs in einem tollen Markt und Entwickler sollten sich auf jeden Tag und ihre Kunden freuen. Doch dafür können und müssen sie auch selbst was tun, indem sie stets ein Auge auf sich und ihre Gesundheit haben.

Die Entwicklung ist ein lukratives und gutes Geschäft, kein Zweifel. Ressourcen sollten deshalb mit der nötigen Weitsicht behandelt werden. Für Unternehmer und Teamleiter gilt damit, die eigenen Coder wie sich selbst zu lieben.

Roland Golla

ist PHP-Trainer für Testing und Refactoring und setzt sich seit einem Nervenzusammenbruch mit Never Code Alone für Arbeitsschutz in der IT ein. Er glaubt an Open Source, Software Craftsmanship und hilft sozialen Einrichtungen mit Geld- und Softwarespenden aus seinen NCA-Community-Events. (ane)