Du arbeitest von 9 bis 17 Uhr? Wir müssen reden!

Inhaltsverzeichnis

Wenn Sie bereits einige Zeit in der Softwareentwicklung tätig sind, dann sind Ihnen die Begriffe "nine to five"-Entwicklerin oder -Entwickler wahrscheinlich schon begegnet. Vielleicht wurde eine Kollegin oder ein Kollege so bezeichnet, oder sogar Sie selbst. In der Regel wird dieser Ausdruck nicht positiv verwendet, sondern eher abwertend. Denn jemand, der "von 9 bis 17 Uhr" arbeitet, denkt – zumindest laut diesem Klischee – vor 9 Uhr morgens nicht über die Arbeit nach – und nach 17 Uhr erst recht nicht mehr.

Und das wird oft als verwerflich angesehen, denn das Mindeste, was man von einer Entwicklerin oder einem Entwickler erwarten könnte, ist, dass sie sich rund um die Uhr mit Softwareentwicklung beschäftigen und weiterbilden. Dass dies allerdings nicht der Realität der meisten Menschen entspricht, wird gerne übersehen. Und über genau diese überzogene Erwartungshaltung müssen wir sprechen. Ist es wirklich fair oder gar sinnvoll, Entwicklerinnen und Entwickler nach ihrer Arbeitszeit zu bewerten?

Unser Alltag ist getaktet

Unser aller Alltag ist getaktet, und das in hohem Maße. Tatsächlich werden wir schon von klein auf daran gewöhnt. Schülerinnen oder Schüler müssen morgens zu einer bestimmten Uhrzeit aufstehen und sich innerhalb einer gewissen Zeit fertig machen, um pünktlich um 8 Uhr in der Schule zu sein. An der Universität beginnt der Tag häufig später, etwa um 9 oder 10 Uhr, und in den meisten Büros geht es ebenfalls um 9 Uhr los. Diese Zeiten haben sich etabliert und die meisten Menschen richten sich danach – unabhängig davon, ob dies zu ihrem biologischen Rhythmus passt oder nicht.

Empfohlener redaktioneller Inhalt

Mit Ihrer Zustimmmung wird hier ein externes YouTube-Video (Google Ireland Limited) geladen.

YouTube-Video immer laden YouTube-Video jetzt laden

Ich bin damit einverstanden, dass mir externe Inhalte angezeigt werden. Damit können personenbezogene Daten an Drittplattformen (Google Ireland Limited) übermittelt werden. Mehr dazu in unserer Datenschutzerklärung.

Doch hier beginnt es schon, unfair zu werden: Denn diejenigen, die ein früher Start in den Tag am meisten trifft (Kinder und Jugendliche), müssen morgens am frühesten beginnen. Und das, obwohl inzwischen erwiesen ist, dass ein späterer Schulstart besser für die geistige und körperliche Entwicklung wäre. Aber nein: Kinder und Jugendliche sollen sich nicht beschweren; sie werden es schon schaffen, jeden Tag zu einer frühen Uhrzeit hoch konzentriert im Unterricht zu sitzen. Und wenn ein Kind damit Schwierigkeiten hat, ist natürlich das Kind und nicht das System schuld …

Lerchen und Eulen

Unabhängig davon lässt sich nicht leugnen, dass es Menschen gibt, die eher früher aufstehen und solche, die eher später den Tag beginnen – die sogenannten Lerchen und die sogenannten Eulen. Mir ist unklar, wann es angesagt wurde, auf Menschen hinabzublicken, weil deren Tagesrhythmus nicht mit dem eigenen übereinstimmt, aber Lerchen versuchen häufig, den Eulen ein schlechtes Gewissen einzureden. Sie argumentieren, dass man morgens so viel verpasse und schimpfen über Langschläfer und Faulpelze. Umgekehrt müssen sie sich abends allerdings von den Eulen anhören, dass sie langweilig seien und kein Leben hätten. Wenn sie nicht jeden Morgen so früh aufstehen würden, könne man abends noch länger etwas mit ihnen unternehmen.

Hier treffen also zwei biologische Modelle aufeinander, von denen jedes glaubt, das überlegene zu sein. Eigentlich ist die ganze Diskussion völlig sinnlos. Doch mit Initiativen wie dem "5-Uhr-Club" werden solche Unterschiede genutzt, um andere herabzusetzen und sich selbst als Teil einer scheinbar höherwertigen und elitären Gruppe zu feiern. Ich persönlich bin kein Freund dieser Vorgehensweise.

Meine Abneigung gegen solche Haltungen rührt jedoch nicht daher, dass ich eine ausgesprochene Nachteule wäre: Ich stehe selbst oft relativ früh auf. Mein Problem damit ist viel eher, dass dieses Verhalten grundsätzlich überheblich und arrogant ist. Wir sollten als Gesellschaft doch vielmehr danach streben, jedem einzelnen Menschen gerecht zu werden. Dies entspricht auch der grundlegenden Forderung des Agilen Manifests: "Individuals and Interactions over Processes and Tools". In der Informatik und Softwareentwicklung ist zudem die Arbeitszeit nicht zwingend an feste Zeiten gebunden. Das betrifft sowohl die Frage, wann gearbeitet wird, als auch die Dauer der Arbeit.

Das romantische Bild des nächtlichen Hackers

Wie ich bereits erwähnte: Ich bin keine Eule. Ich stehe grundsätzlich gerne früh auf. Es gefällt mir, vor allen anderen wach zu sein, zu erleben, wie die Natur erwacht, die ersten Vögel zu hören und den Sonnenaufgang zu beobachten. Je nach Jahreszeit stehe ich manchmal sogar schon um vier oder fünf Uhr morgens auf. Aber: Das fällt mir nicht immer leicht, und es bedeutet auch, dass ich abends entsprechend früh ins Bett gehen muss.

Ich bin aber auch keine Lerche: Wenn ich nicht wegen anstehender Termine früh aufstehen müsste, würde ich oft auch gerne bis fünf Uhr morgens wach bleiben und erst dann schlafen gehen. Das habe ich während meiner Schul- und Studienzeit in den Ferien oft getan – ich habe buchstäblich die Nacht zum Tag gemacht. Das entspricht auch ein wenig der romantisierten Vorstellung von Hackern, wie beispielsweise Neo in "Matrix", die nicht von 9 bis 17 Uhr arbeiten, sondern von 21 Uhr bis 5 Uhr morgens. Mit diesem Modell könnte ich mich durchaus anfreunden, zumindest zeitweise. In gewisser Weise wäre ich also manchmal gerne ein "nine to five"-Entwickler.

Der Einfluss des Tagesrhythmus

Wäre ich dann produktiver? Nicht unbedingt. Denn ob ich von 9 bis 17 Uhr arbeite oder von 21 Uhr bis 5 Uhr morgens: Es sind beides jeweils acht Stunden. Und keine dieser Zeiten ist per se besser oder schlechter als die andere. Deshalb finde ich es wenig sinnvoll, Menschen danach zu be- oder gar verurteilen, wann sie arbeiten. Eine Entwicklerin oder ein Entwickler leistet nicht bessere Arbeit, weil sie oder er früher oder später beginnt.

Die Qualität der Arbeit hängt vielmehr davon ab, ob die Arbeitszeit zum individuellen Tagesrhythmus passt. Wenn ich ständig gegen meine innere Uhr arbeiten muss, wirkt sich das natürlich auf die Qualität meiner Arbeit aus. Es wäre auch merkwürdig, wenn das anders wäre. Doch auch wenn man seine biologische Uhr berücksichtigt, ist der Tagesablauf nicht jeden Tag gleich. Wir sind keine Roboter, und unsere Gesellschaft sollte das berücksichtigen.

Acht Stunden sind nicht acht Stunden

Hinzu kommt aber noch ein weiterer Aspekt: Acht Stunden sind nicht gleich acht Stunden. Was die eine Entwicklerin in acht Stunden schafft, gelingt dem anderen Entwickler vielleicht in einer ganzen Woche nicht – oder umgekehrt. Es macht daher aus einer bestimmten Perspektive kaum Sinn, Softwareentwicklung ausschließlich nach Zeit zu bemessen. Dies war bei rein körperlichen Tätigkeiten am Fließband sinnvoll, weil Anwesenheit gleichzeitig auch Arbeitszeit bedeutete.

Aber bei einer vorrangig kreativen und geistigen Tätigkeit wie der Softwareentwicklung trifft das nicht zu. Ich könnte acht Stunden in einem Büro sitzen, sehr beschäftigt aussehen und den ganzen Tag rein gar nichts erledigen. Oder ich könnte eine schlaflose Nacht im Bett verbringen, ein Problem durchdenken und plötzlich die Lösung finden, die mir die ganze Woche über nicht eingefallen ist. Wie bewertet man das? Hätte ich den entscheidenden Gedanken in der Nacht auch ohne die vorherige vergebliche Grübelei gefunden? Wer weiß. Und weitergedacht: Auf welche Kostenstelle verbuche ich eigentlich die Idee, die mir morgens unter der Dusche gekommen ist?

Eine Frage der Erfahrung

Unabhängig davon hängt die Zeit, die ich für eine Aufgabe benötige, stark von meiner Erfahrung ab. Auf Konferenzen, auf denen ich Live-Coding durchführe, wird mir oft gesagt, es sei beeindruckend, wie schnell ich Software entwerfen und programmieren könne. Was dabei oft übersehen wird: Den entsprechenden Vortrag habe ich in dieser oder einer ähnlichen Form vielleicht schon hundertmal gehalten. Ich weiß also genau, was ich mache, welche Probleme auftreten können und was mein Ziel ist.

Jeder Tastendruck sitzt, und auch wenn es oft spontan aussieht, ist häufig alles im Vorfeld geplant. Selbst die Fehler, die ich live mache, sind in 90 Prozent der Fälle einkalkuliert, denn Fehler bieten bekanntlich die beste Lerngelegenheit. Ich führe mein Publikum gerne bewusst in eine Falle, um dann gemeinsam mit ihnen einen Ausweg zu finden. Das ist lehrreicher, als wenn ich einfach von Anfang an erkläre, wie etwas funktioniert. Es mag also den Anschein haben, als würde mir alles leichtfallen, aber in Wirklichkeit mache ich vieles davon nicht zum ersten Mal. Auch ich koche nur mit Wasser.

Und das merken Sie, wenn Sie mir eine Aufgabe stellen, die mir überhaupt nicht liegt: Nehmen wir an, irgendetwas mit CSS – dann können Sie sicher sein, dass ich deutlich länger dafür benötigen werde als jemand, die oder der halbwegs Erfahrung mit CSS hat. Das verdeutlicht, was ich meine, wenn ich sage: Acht Stunden sind nicht einfach acht Stunden. Je nach Thema benötigt die eine oder der andere für dieselbe Aufgabe deutlich mehr oder weniger Zeit, einfach weil der persönliche Hintergrund unterschiedlich ist.

Daher ergibt es wenig Sinn, jemanden nur deshalb als "nine to five"-Entwicklerin oder -Entwickler zu diskreditieren: Erstens wissen Sie nicht, ob dies nicht vielleicht gerade die Zeit ist, in der die Person tatsächlich am produktivsten ist, und zweitens ist die viel interessantere Frage: Was erreicht die Person in dieser Zeit?

Ergebnis versus Zeit

Der eigentlich wichtige Punkt ist doch: Was kommt am Ende bei alldem heraus? Stimmt die Qualität des Ergebnisses? Es kann durchaus sein, dass jemand, der von 9 bis 17 Uhr arbeitet, bessere Ergebnisse liefert als jemand, der freiwillig 80 Stunden pro Woche schuftet. Es könnte auch sein, dass jemand in nur vier Stunden pro Tag mehr erreicht als ein anderer in acht Stunden. Das hängt alles vom jeweiligen Themengebiet und der spezifischen Aufgabe ab und ist daher einfach nicht vergleichbar.

Dass wir in der IT-Branche immer noch die Arbeitszeit als Metrik verwenden, ist eigentlich absurd: Ja, diese Metrik funktioniert, aber nur weil sie funktioniert, ist sie noch lange keine gute Metrik. Auch "Lines of Code" könnte man als Maßstab heranziehen, und dennoch würde niemand ernsthaft vorschlagen, die Produktivität von Entwicklerinnen und Entwicklern anhand der Anzahl geschriebener Zeilen zu bewerten. Genauso schlecht ist der Ansatz, die benötigte Zeit zu messen. Wir tun dies nur, weil uns keine bessere Alternative zur Verfügung steht. Eine gute Idee ist es deshalb noch lange nicht.

Sachliche statt persönlicher Kritik

Damit kommen wir nun zum eigentlichen Kern dieses Artikels: Der Begriff "nine to five" wird oft benutzt, um auszudrücken, dass jemand angeblich keinen guten Code schreibt oder keine durchdachten Lösungen entwickelt. Dieser Vorwurf zielt letztlich auf die Qualität der Ergebnisse ab. Insofern: Wenn Sie schon Kritik üben möchten, dann benennen Sie doch konkret, was Ihnen an dem Ergebnis nicht gefällt, aus technischer oder fachlicher Sicht.

Treten Sie in eine konstruktive Diskussion über die Inhalte ein. Es ist jedoch wenig sinnvoll, jemanden nur darauf zu reduzieren, dass sie oder er "nur acht Stunden" arbeitet und daraus dann zu folgern, die Person sei faul oder bequem – das finde zumindest ich persönlich menschlich einfach daneben. Vielleicht arbeitet diese Entwicklerin oder dieser Entwickler tatsächlich bereits nach bestem Wissen und Gewissen und manches gelingt vielleicht einfach nicht besser.

Möglicherweise liegt das an mangelnder Erfahrung, vielleicht fehlt eine zweite Meinung, vielleicht sind die eingesetzten Technologien neu und unbekannt, oder oder oder. In solchen Fällen sollten Sie daher also eher die- oder derjenige sein, die oder der hilfsbereit und konstruktiv ist und dazu beiträgt, andere voranzubringen, statt sich über deren Arbeitszeiten oder angeblich minderwertige Einstellung lustig zu machen.

Und wenn Sie das nächste Mal mitbekommen, dass eine Kollegin oder ein Kollege herablassend als "nine to five"-Entwicklerin oder -Entwickler bezeichnet wird, dann unterstützen Sie diese Person, statt mitzumachen. Nehmen Sie sich einen Moment Zeit, um etwas Positives beizutragen. Wer weiß, was Sie damit zum Guten bewirken. (map)