- Laut Forschung aus der Kognitionspsychologie liegt die Grenze für Deep Work beim Menschen bei 3–4 Stunden pro Tag; danach nehmen Konzentration und Code-Qualität rapide ab
- Die Analyse von mehr als 250.000 Entwicklern zeigt, dass die tatsächliche Median-Coding-Zeit nur 52 Minuten pro Tag beträgt; der Rest geht für Meetings, Management und Zusammenarbeit drauf
- Nach einer einzelnen Unterbrechung dauert es 23 Minuten, bis man zur ursprünglichen Aufgabe zurückkehrt; bei Programmierern sind für die vollständige Wiederherstellung des Kontexts 30–45 Minuten nötig
- Im Flow-Zustand steigt die Produktivität um 500 %, doch der Einstieg erfordert 15–25 Minuten ununterbrochene Konzentration
- Die Aufgabe von Engineering-Managern sollte nicht darin bestehen, weitere Prozesse hinzuzufügen, sondern sich auf die Beseitigung von Störfaktoren und den Schutz von Deep-Work-Zeit zu konzentrieren
Kognitive Grenzen: Deep Work hat bei 4 Stunden pro Tag eine Obergrenze
- Cal Newport definiert Deep Work als „berufliche Tätigkeit in einem Zustand ungestörter Konzentration, bei der die kognitiven Fähigkeiten bis an ihre Grenzen gefordert werden“; für die meisten Menschen sind im Schnitt 4 Stunden pro Tag das Maximum
- Auch K. Anders Ericssons Studie zu Violinisten zeigte, dass nach 4 Stunden konzentrierten Übens Ermüdung einsetzt
- Softwareentwicklung ist ebenfalls hochintensive kognitive Arbeit mit kreativem Problemlösen und Systemdesign; nach 3–4 Stunden setzt daher ein abnehmender Grenzertrag ein
- Der Mathematiker Henri Poincaré arbeitete 2 Stunden morgens und 2 Stunden nachmittags, G.H. Hardy nur am Vormittag; auch Charles Darwin, B.F. Skinner und C.S. Lewis hielten Zeitpläne mit 3–4 Arbeitsstunden ein
- Laut einer Studie von Gloria Mark an der UC Irvine beträgt die durchschnittliche Bildschirm-Aufmerksamkeitsspanne heute 47 Sekunden – deutlich weniger als die 2,5 Minuten im Jahr 2004
Wie Entwickler ihre Zeit tatsächlich nutzen
- Laut der Analyse von mehr als 250.000 Entwicklern von Software.com beträgt die Median-Coding-Zeit 52 Minuten pro Tag (etwa 4 Stunden 21 Minuten pro Woche)
- Nur 10 % der Entwickler programmieren mehr als 2 Stunden am Tag, 40 % mehr als 1 Stunde
- Laut der Analyse von 1,5 Millionen Meetings von Clockwise verbringen Softwareingenieure im Schnitt 10,9 Stunden pro Woche in Meetings
- Engineering-Manager verbringen 18 Stunden pro Woche in Meetings, also fast die Hälfte einer 40-Stunden-Woche
- Entwickler in großen Organisationen verbringen 12,2 Stunden pro Woche in Meetings, in kleineren Organisationen 9,7 Stunden
- Zieht man Meetings, Management, Code Reviews und Zusammenarbeit ab, bleiben pro Woche 19,6 Stunden potenziell fokussierbarer Zeit – meist in kurzen, praktisch unbrauchbaren Fragmenten
- 45 % des gesamten Codings finden zwischen 14 und 17 Uhr statt, zwischen 9 und 11 Uhr hingegen nur 10 %
- Nicht weil Entwickler grundsätzlich nachmittags produktiver wären, sondern weil der Morgen von Stand-ups, Syncs und Zeremonien verschlungen wird
Die hohen Kosten von Unterbrechungen
- Laut Gloria Marks Forschung dauert es nach einer Unterbrechung exakt 23 Minuten und 15 Sekunden, um vollständig zur ursprünglichen Aufgabe zurückzukehren
- Eine Studie des Georgia Institute of Technology zeigt: Bei Programmierern dauert es 10–15 Minuten bis zur Wiederaufnahme der Codebearbeitung, für den vollständigen Wiederaufbau des mentalen Kontexts jedoch 30–45 Minuten
- Paul Grahams Essay zum „Maker Schedule“: Meetings sind nicht bloß ein einfacher Aufgabenwechsel, sondern eine Ausnahme, die den Arbeitsmodus selbst verändert
- Ein einziges Meeting kann einen ganzen Nachmittag zerstören, und schon ein geplantes Nachmittagsmeeting hält einen morgens davon ab, ambitionierte Arbeit zu beginnen
Flow-Zustand: Der Produktivitätsmultiplikator für Programmierer
- Mihaly Csikszentmihalyi definiert den Flow-Zustand als einen „Zustand völliger Vertiefung in eine Tätigkeit, in dem das Selbst verschwindet und das Zeitgefühl verloren geht“
- Das Ergebnis von 10 Jahren Forschung: Im Flow-Zustand steigt die Produktivität um 500 % gegenüber dem Normalzustand
- Entscheidend für den Einstieg in den Flow ist das Gleichgewicht zwischen Herausforderung und Fähigkeitsniveau; ist die Herausforderung zu hoch oder zu niedrig, wird Flow verhindert
- In Softwareteams liefern Teams, die häufiger Flow erleben, schneller mehr Wert und haben dabei eine höhere Zufriedenheit
- Flow entsteht nicht von selbst; entscheidend ist der Schutz vor den Faktoren, die ihn aufzehren
Wie man beim Coden in den Flow kommt
- Eine störungsfreie Umgebung schaffen: Slack schließen, Benachrichtigungen stummschalten, sichtbare Statusanzeigen nutzen, die Deep-Work-Modus signalisieren
- Schon das bloße Sehen einer Benachrichtigung senkt die Konzentration, selbst wenn man nicht darauf reagiert
- Vor einer Coding-Session klare Ziele setzen: nicht „Backend-Arbeit“, sondern konkret „den Authentifizierungs-Endpunkt so anpassen, dass er passende Error-Responses zurückgibt“
- Schwierige Probleme in kognitiven Peak-Zeiten lösen: Studien zum zirkadianen Rhythmus zeigen, dass die kognitive Leistung je nach Tageszeit um 9–40 % schwankt
- Für die meisten Erwachsenen liegt die beste Zeit für Problemlösung zwischen 10 und 14 Uhr
- Da Morgenmenschen („Lerchen“) und Abendmenschen („Eulen“) unterschiedliche Peak-Zeiten haben, sollte die individuelle Hochphase geschützt werden
- Time-Blocking für den Maker Schedule: Im Kalender 2–4-stündige Deep-Work-Blöcke reservieren und Meetings ans Tagesende oder auf bestimmte Wochentage bündeln
- Für jeden Arbeitsblock ein Ziel festlegen und in drei umsetzbare Tasks zerlegen
- Kontextwechsel eliminieren: Statt sofort zu reagieren lieber zweimal täglich Kommunikationsfenster einplanen und Browser-Tabs schließen, die nichts mit der aktuellen Aufgabe zu tun haben
- In fokussierten Sessions statt in Marathon-Sprints arbeiten: 25-Minuten-Pomodoros eignen sich schlecht für komplexe Entwicklungsarbeit, weil der Timer oft genau dann unterbricht, wenn man gerade in den Flow kommt
- Das Ziel ist nicht maximale Zeit, sondern maximale Qualität innerhalb der Grenzen der kognitiven Leistungsfähigkeit
- Der Zinseszinseffekt von Reflexion und Lernen: Ericssons Forschung zum absichtsvollen Üben zeigt, dass nicht die reine Arbeitszeit, sondern reflektiertes Denken Expertise schafft
Cal Newports 4 Deep-Work-Strategien
- Monastische Strategie (Monastic): flache Arbeit vollständig eliminieren
- Donald Knuths Abschaffung von E-Mail im Jahr 1990 ist ein typisches Beispiel
- Bimodale Strategie (Bimodal): Die Woche in Deep-Work-Tage und Tage für flache Arbeit aufteilen
- Beispiel: Mo–Mi nicht erreichbar, Do–Fr Meetings und E-Mails bearbeiten
- Rhythmische Strategie (Rhythmic): Jeden Tag zur gleichen Zeit Deep Work, ohne Ausnahmen
- Jerry Seinfelds Ansatz „Don’t break the chain“
- Journalistische Strategie (Journalistic): Immer dann sofort in Deep Work wechseln, wenn freie Zeit entsteht
- Funktioniert auch in 30–45-Minuten-Blöcken, birgt in der Praxis aber das Risiko, Kontextwechsel mit Deep Work zu verwechseln
- Für die meisten Entwickler ist die rhythmische Strategie am effektivsten; entscheidend ist, morgens Zeit fürs Coding zu sichern, ohne der reaktiven Versuchung von Slack zu erliegen
Warum Engineering-Manager das interessieren sollte
- Wenn Entwickler real nur 52 Minuten pro Tag coden und eine einzige Unterbrechung mehr als 23 Minuten Wiederanlauf kostet, dann verbraucht eine einzige Nachricht fast die Hälfte des täglichen Coding-Budgets
- Ein Experiment von TechSmith: Werden Meetings vollständig entfernt, steigt die wahrgenommene Produktivität um 15 %; 85 % der Beschäftigten würden Meetings lieber durch asynchrone Kommunikation ersetzen
- In einer Microsoft-Umfrage unter 31.000 Personen waren ineffiziente Meetings der größte Störfaktor für Produktivität am Arbeitsplatz
- Empfehlungen für Manager:
- Ungestörte Vormittagszeit sichern
- No-Meeting-Day einführen (z. B. Mittwoch)
- Asynchrone statt synchrone Kommunikation zum Standard machen
- Realistische Deadlines setzen, die Raum für kreative Erkundung lassen
- Messgrößen für den Effekt: kürzere Cycle Time, Teamzufriedenheit, Engagement-Scores, Bug-Rate und Nacharbeitsquote als Qualitätsmetriken
Fazit
- 3–4 Stunden Deep Programming pro Tag sind keine Frage der Disziplin, sondern die physische Grenze kognitiver Belastbarkeit
- Entscheidend ist die Optimierung kontrollierbarer Faktoren: Benachrichtigungen abschalten, dem Team ankündigen, erst nachmittags zu antworten, zweimal pro Woche morgendliche Meetings verhindern usw.
- 4 Stunden Deep Work liefern immer bessere Ergebnisse als 8 Stunden „halb konzentrierter“ Arbeit
- Mehrere Stunden Flow pro Tag führen zu hochwertigerem Code, geringerem Bug-Risiko, innovativeren Lösungen und besserer Work-Life-Balance
- Coder sind keine Sprinter, sondern Marathonläufer – sie müssen ihre Energie bewahren
Hinweis zu AI-Coding-Assistenten
- Tools wie Copilot, Cursor und Claude verlängern die Deep-Work-Zeit nicht, sondern verschieben nur den Fokus
- Auch das Prüfen von AI-Ausgaben statt das Schreiben von Code von Grund auf erfordert denselben Kontext, dieselbe Urteilskraft und dieselbe Konzentration
- Die 3–4-Stunden-Grenze ist keine Frage der Tippgeschwindigkeit, sondern die Grenze des Gehirns, qualitativ hochwertige Entscheidungen dauerhaft aufrechtzuerhalten – daran ändert sich nichts, nur weil Code schneller erscheint
- Wirklich hilfreich ist AI in flachen Stunden (shallow hours): Entwürfe für Dokumentation, Boilerplate-Generierung, Fragen zur Bibliotheksnutzung usw.
- Wenn man solche Aufgaben an AI delegiert, lässt sich das Deep-Work-Budget für Architekturdenken und komplexe Problemlösung aufsparen
- Die Falle besteht darin, mit AI mehr Code zu produzieren, als man mental verarbeiten kann
- Das Ziel sind nicht mehr Codezeilen pro Tag, sondern die Fokussierung begrenzter kognitiver Ressourcen auf die wichtigsten Entscheidungen
13 Kommentare
Der Vergleichsmaßstab selbst ist falsch.
K. Anders Ericssons Studie zu Violinisten basierte nicht auf dem Niveau bereits ausgereifter Könner, sondern auf dem Üben selbst. Bei Instrumenten ist selbst dann, wenn man ein Stück perfekt einstudiert hat, eine perfekte Aufführung nicht immer garantiert (es gibt bei jeder Aufführung Ausnahmen). Im Gegensatz dazu sind in der Entwicklung die Anforderungen klar, und nach der Fertigstellung liefert sie immer dasselbe Ergebnis. Es gibt einen sehr großen Unterschied zwischen dem fortlaufenden Tun von etwas mit einem Ende und dem fortlaufenden Tun von etwas ohne Ende. Deshalb ist schon die Festlegung, dass die menschliche kognitive Leistungsfähigkeit im Durchschnitt 3 bis 4 Stunden betrage, problematisch, weil es wiederum einen Unterschied gibt zwischen 3 bis 4 Stunden Entwicklung auf Anweisung anderer und 3 bis 4 Stunden Entwicklung aus eigenem Antrieb. Dieser Text wirkt auf mich wie ein Text, der alles verallgemeinert und plausibel davon überzeugen will, dass 3 bis 4 Stunden die Grenze der menschlichen kognitiven Leistungsfähigkeit seien. Nur weil ihre Konzentrationszeit 3 bis 4 Stunden beträgt, heißt das nicht, dass die Konzentrationszeit aller Menschen 3 bis 4 Stunden beträgt. Eher wirkt es wie ein Text, der eine Grenze festlegt und auf ein stilles Einvernehmen hinauswill: Lasst uns nur 3 bis 4 Stunden arbeiten.
Genau~! Tatsächlich gibt es viele Leute, die einfach wirklich gute Arbeit leisten.
Ich hoffe, man definiert sich nicht über die Spitzenleistung der eigenen Konzentration in der Karriere nach dem Motto: So bin ich eben. Dieser Text setzt Deep Work als idealen Arbeitszustand voraus und bemüht sich übermäßig darum, dorthin zu gelangen. Natürlich entsteht Deep Work und die Produktivität steigt, wenn man interessante Ideen zur Problemlösung und sinnvolle Richtungen für Versuche erkennt. Wenn man aber, sobald das ausbleibt, glaubt, das eigene Gehirn sei eigentlich zu noch viel Genialerem fähig, und deshalb ständig unzufrieden ist, dann verringert man am Ende die Wahrscheinlichkeit, selbst in einen "Flow" zu kommen, erheblich. Je schwächer die Metakognition, desto leichter denkt man, dieses Gehirn gehöre ganz einem selbst, aber diesen Zustand des Gehirns schafft man niemals allein. Man sollte anerkennen, welche Unterstützung aus dem Umfeld nötig war, damit diese Konzentration überhaupt entstehen konnte — nicht nur, dass man in Ruhe gelassen oder bezahlt wurde, sondern auch, dass man viele Reize erhalten hat und irgendwann etwas geschieht, das sie präzise in eine Richtung bündelt; genau das ist ein Zustand tiefer Konzentration. Unabhängig vom Ergebnis hilft es, innerlich dankbar zu sein, und auch ohne es anderen ausdrücklich zeigen zu müssen, in einem angemessenen Maß zufrieden zu sein und sich selbst positiv zu sehen — das steigert langfristig die Konzentrationsfähigkeit und den eigenen Zustand.
Ich arbeite in einem Unternehmen, in dem wir morgens 3 Stunden arbeiten, zu Mittag essen und dann nachmittags noch einmal 3 Stunden arbeiten (insgesamt 7 Stunden, 4 Tage pro Woche). Schon das allein ist psychisch deutlich angenehmer.
Eine gute Firma!
Der Grund, warum es immer gut geklappt hat, wenn ich nach Feierabend allein programmiert habe, wenn niemand mehr da war, ist wohl...;;;
Deshalb gehe ich sogar eher nach Hause, wenn andere Überstunden machen.
Ich denke, mit Training, Erholung und einem passenden Umfeld lässt sich das etwas steigern, aber wenn man Menschen verheizt, ist das auf Dauer kaum durchzuhalten. Unternehmen drücken darauf, genau das zu tun, und schweigen darüber, aber ich sehe auch immer wieder Techniker, die nur mit Medikamenten (Antidepressiva, ADHS-Medikamente) arbeiten.
Stimmt, dass psychologische Praxen in Pangyo gut laufen, ist eine unbequeme Wahrheit.
Ich denke, eine Stunde Programmieren am Tag reicht aus. Schon vor AI war die tatsächliche Zeit, die man mit Programmieren verbracht hat, gar nicht so lang, und jetzt ist sie erst recht noch kürzer geworden.
Wenn es um Entwicklung, Spiele oder Lesen geht, auf die ich wirklich Lust habe, kann ich mich scheinbar stundenlang konzentrieren, bis die jeweilige Aufgabe erledigt ist.
Mit diesen 4 Stunden ist hier wahrscheinlich die Konzentrationsfähigkeit für Arbeit gemeint, die man zwar nicht machen will, aber wegen des Berufs macht (sollte man das passive Konzentration nennen?).
Ganz einfach. Jeder Mann dürfte schon einmal erlebt haben, beim Zocken die ganze Nacht hindurch die Konzentration aufrechterhalten zu können.
Meiner persönlichen Erfahrung nach fühlt es sich gar nicht wirklich ermüdend an, selbst mehrere Stunden am Stück zu entwickeln, wenn ich an etwas arbeite, das ich wirklich machen möchte.
Schon das Ausführen mehrerer Sessions wird zu Multitasking und kann die Konzentration verringern.