Das konkrete Problem für Programmierer ist, wie teuer eine Unterbrechung im Vergleich zu fast jeder anderen Art von Arbeit tatsächlich ist. Eine komplexe Funktion, einen ganzen Call-Stack oder die wahrscheinliche Ursache eines kniffligen Bugs im Kopf zu behalten, ist eine fragile Art von Konzentration, und ein dreißigsekündiger Blick aufs Handy kostet nicht nur dreißig Sekunden — er kann die zehn oder fünfzehn Minuten kosten, die es braucht, dieses mentale Modell wieder von null aufzubauen, weshalb Programmierer oft beschreiben, eine ganze produktive Stunde an das verloren zu haben, was von außen wie ein paar kurze Pausen aussah. Forschung zum Kontextwechsel bei Wissensarbeit findet durchgängig, dass das Wiederaufnehmen einer komplexen Aufgabe nach einer Unterbrechung deutlich länger dauert als die Unterbrechung selbst, und speziell beim Programmieren — wo der „Kontext” ein ganzes mentales Modell eines Systems ist, nicht bloß ein Gedankengang — fällt diese Lücke meist größer aus als bei den meisten anderen Arten von Arbeit. Das ist mit ein Grund, warum so viel geschrieben wird, in dem Software-Engineering-Kultur Maker-Zeitpläne und lange, ungebrochene Blöcke als echte Produktivitätsanforderung behandelt, nicht als nettes Extra — die Kosten der Fragmentierung sind bei dieser Art von Arbeit messbar höher als in Rollen, deren Aufgaben von Natur aus kürzer und leichter unterbrechbar sind.
Was du wahrscheinlich schon versucht hast
Nicht-stören-Modus während Compiler-Läufen und Code-Reviews, Noise-Cancelling-Kopfhörer als soziales Signal, nicht gestört werden zu wollen, ein Website-Blocker gegen Stack-Overflow-Tab-Hopping, der irgendwie immer eine Ausnahme für „nur diese eine Suche” enthält, und wahrscheinlich ein kostenloser App-Blocker, der beim ersten Mal wieder deinstalliert wurde, als er legitimerweise dem Nachschlagen der Dokumentation oder einer Slack-Nachricht von der Arbeit mitten im Debugging im Weg stand. Pomodoro-artige Timer helfen manchen Entwicklern, sich durch eine lange Sitzung zu takten, aber ein Timer, der mitten im Debugging endet, weiß oder interessiert sich nicht dafür, dass man dreißig Sekunden davor stand, den Bug zu finden, und die Pause trotzdem zu nehmen, nur weil der Timer es sagt, kann ebenso störend sein wie die Ablenkung, die er verhindern sollte. Manche Teams versuchen gemeinsame „Fokusstunden” als Norm, was hilft, wenn sie wirklich alle respektieren, aber eine Norm ohne jeden Durchsetzungsmechanismus erodiert meist beim ersten Mal, wenn eine Deadline für irgendjemanden im Team eine Ausnahme gerechtfertigt erscheinen lässt.
Warum generische Blockier-Tipps hier speziell versagen
„Blockiere Social Media während der Arbeitszeit” übersieht, dass das eigentliche Ablenkungsmenü eines Programmierers breiter und arbeitsnäher ist als bei den meisten Menschen — Foren, News-Aggregatoren wie Hacker News, GitHub-Benachrichtigungen, ein Dutzend Browser-Tabs, die sich alle irgendwie als „technisch arbeitsbezogen” rechtfertigen lassen. Eine Sperrliste, die für einen typischen Büroangestellten gebaut wurde, passt nicht sauber auf diese konkrete Mischung, und eine zu eng gebaute lässt die eigentlichen Lecks weit offen. Sie behandelt außerdem tendenziell alle Unterbrechungen als gleich schlimm, während der Schaden in der Praxis davon abhängt, wie tief der mentale Zustand im Moment der Unterbrechung war — ein kurzer Check während eines routinemäßigen Code-Reviews kostet weit weniger als derselbe Check mitten in der Verfolgung einer Race Condition, und eine Einheitssperre unterscheidet nicht zwischen beidem. Ein Werkzeug, das um eine einzige, feste „Social Media”-Kategorie herum gebaut ist, übersieht außerdem, dass die Versuchung für viele Entwickler gar nicht Social Media ist — sondern eine scheinbar arbeitsnahe Seite, die sich im Moment leicht rechtfertigen lässt und genauso effektiv eine Stunde auffrisst.
Wo es ehrlich passt
Eine quizgesicherte Sperre passt hier gut, weil die Reibung, eine echte Frage zu beantworten, eine ähnliche Art kognitiver Beteiligung ist wie die Arbeit selbst — sie bietet nicht die leichtere, passivere Fluchtmöglichkeit, die ein Countdown-Timer oder ein Fünf-Sekunden-Tippen bieten würde. Und weil die Sperrliste vollständig anpassbar ist, lässt sie sich um die konkreten Apps und Seiten herum bauen, die einem bestimmten Entwickler tatsächlich Zeit fressen, statt um eine generische „Social Media”-Kategorie, die die Hälfte der echten Lecks übersieht. Weil die Fragen aus einem allgemeinen Wissenspool rotieren, statt irgendetwas am Code selbst abzufragen, wird das Beantworten nicht versehentlich zu einer eigenen Form der Prokrastination — ein verbreitetes Scheitermuster bei gamifizierten Produktivitäts-Werkzeugen, die Beschäftigung mit dem Blocker mehr belohnen als Beschäftigung mit der eigentlichen Arbeit. Diese Anpassbarkeit zählt hier mehr als in den meisten anderen Berufen, weil die tatsächliche Ablenkungsliste eines Entwicklers selten der von irgendjemand anderem entspricht, und ein Werkzeug, das sich nicht an die echte Liste anpassen lässt, endet entweder zu locker, um etwas zu bewirken, oder zu streng, um zu überleben.
Wo es nicht passt
Wenn deine tatsächlichen Unterbrechungen legitim sind — Slack-Nachrichten von Teamkollegen, Alarme aus einer Bereitschaftsrotation —, sollte ein Blocker davon überhaupt nichts anfassen, und eine zu breit gebaute Sperrliste wird beim ersten Mal, wenn sie etwas wirklich Dringendes blockiert, einfach wieder deaktiviert. Und für einen fest geplanten, fokusintensiven Coding-Sprint mit harter Deadline mag eine härtere, nicht verhandelbare Sperre wie Cold Turkey besser dienen als wiederholte Reibung, die sich per Design immer irgendwann umgehen lässt. Es ist auch ehrlich, zu sagen, dass das die Unterbrechungskultur auf Team-Ebene nicht löst — wenn das eigentliche Problem eine Erwartung sofortiger Antwort auf jedem Kanal ist, ist das eine Norm, die das Team direkt angehen muss, und kein individuelles Blockier-Werkzeug, so gut es auch konfiguriert ist, ändert, was eine Führungskraft oder ein Team tatsächlich erwartet. Die Aufgabe des Werkzeugs ist eng und spezifisch — die Kosten des reflexhaften, geringwertigen Checks erhöhen —, und man sollte sich klar sein, dass es nie dazu gedacht war, die Reaktionszeitkultur eines Teams allein zu reparieren.