Warum Entwickler ein Augenmerk auf ihre Gesundheit legen sollten

Inhaltsverzeichnis

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.