Het specifieke probleem voor programmeurs is hoe duur een onderbreking eigenlijk is in verhouding tot bijna elk ander soort werk. Een complexe functie, een hele call stack, of de vermoedelijke oorzaak van een lastige bug in je hoofd vasthouden is een kwetsbaar soort concentratie, en een telefooncheck van dertig seconden kost niet alleen dertig seconden — het kan de tien of vijftien minuten kosten die nodig zijn om dat mentale model helemaal opnieuw op te bouwen, wat is waarom programmeurs vaak beschrijven dat ze een heel productief uur zijn kwijtgeraakt aan wat van buitenaf een paar korte pauzes leken. Onderzoek naar taakwisseling bij kenniswerk vindt consequent dat het hervatten van een complexe taak na een onderbreking betekenisvol langer duurt dan de onderbreking zelf, en voor programmeren specifiek — waar de "context" een heel mentaal model van een systeem is, niet alleen een gedachtegang — is die kloof doorgaans erger dan bij de meeste andere soorten werk. Dit is deels waarom zoveel geschriften over softwareontwikkelingscultuur maker schedules en lange, ononderbroken blokken als een echte productiviteitsvereiste behandelen in plaats van een leuke bijkomstigheid — de kosten van fragmentatie zijn bij dit soort werk meetbaar erger dan bij rollen waar taken korter en van nature onderbreekbaarder zijn.
Wat je waarschijnlijk al hebt geprobeerd
Niet storen tijdens compiles en codereviews, een noise-cancelling koptelefoon als sociaal signaal om niet gestoord te worden, een websiteblokkeerder voor Stack Overflow-tabbladhoppen die op de een of andere manier altijd een uitzondering heeft voor "even deze ene zoekopdracht", en waarschijnlijk een gratis app-blokkeerder die verwijderd werd de eerste keer dat hij in de weg zat bij legitiem documentatie of een werk-Slackbericht midden in het debuggen checken. Pomodoro-achtige timers helpen sommige ontwikkelaars het tempo van een lange sessie te bewaken, maar een timer die midden in het debuggen afloopt weet of interesseert het niet dat je nog dertig seconden verwijderd was van het vinden van de bug, en de pauze toch nemen omdat de timer het zegt kan net zo verstorend zijn als de afleiding die hij moest voorkomen. Sommige teams proberen gedeelde "focusuren" als norm, wat helpt als iedereen ze daadwerkelijk respecteert, maar een norm zonder handhavingsmechanisme slijt doorgaans de eerste keer dat een deadline een uitzondering gerechtvaardigd laat voelen, voor iemand, ergens in het team.
Waarom algemeen blokkeeradvies hier specifiek faalt
"Blokkeer sociale media tijdens werktijd" mist dat het eigenlijke afleidingsmenu van een programmeur breder en werkgerelateerder is dan dat van de meeste mensen — forums, nieuwsaggregators zoals Hacker News, GitHub-meldingen, een dozijn browsertabbladen die allemaal vaag gerechtvaardigd aanvoelen als "technisch werkgerelateerd". Een blokkeerlijst gebouwd voor een generieke kantoormedewerker past niet netjes op die specifieke mix, en een te nauw opgestelde lijst laat de echte lekken wagenwijd open. Het behandelt ook alle onderbrekingen als even erg, terwijl de schade in de praktijk schaalt met hoe diep de mentale toestand was op het moment van de onderbreking — een snelle check tijdens een routine codereview kost veel minder dan diezelfde check midden in het traceren van een race condition, en een one-size-fits-all blokkade maakt daar geen onderscheid in. Een tool gebouwd rond één vaste "sociale media"-categorie mist ook dat de verleiding voor veel ontwikkelaars helemaal geen sociale media is — het is een schijnbaar werkgerelateerde site die op het moment zelf makkelijk te rechtvaardigen is en net zo effectief een uur opslokt.
De eerlijke fit
Een blokkade met quizvraag past hier goed omdat de wrijving van het beantwoorden van een echte vraag een vergelijkbaar soort cognitieve betrokkenheid is als het werk zelf — het biedt niet de makkelijkere, passievere ontsnapping die een aftel-timer of een tik van vijf seconden wel biedt. En omdat de blokkeerlijst volledig aanpasbaar is, kan hij worden opgebouwd rond de specifieke apps en sites die de tijd van een gegeven ontwikkelaar daadwerkelijk opslokken, in plaats van een generieke "sociale media"-categorie die de helft van de echte lekken mist. Omdat de vragen roteren over een algemene kennisbank in plaats van iets over de code zelf te testen, wordt het beantwoorden ervan niet per ongeluk zelf een vorm van uitstelgedrag — een veelvoorkomend faalpunt bij gegamificeerde productiviteitstools die betrokkenheid bij de blokkeerder belonen boven betrokkenheid bij het echte werk. Die instelbaarheid doet er hier meer toe dan in de meeste andere beroepen, want de echte afleidingslijst van een ontwikkelaar komt zelden overeen met die van iemand anders, en een tool die niet naar de echte lijst kan worden gevormd, wordt uiteindelijk óf te los om iets uit te maken óf te streng om te overleven.
Waar het niet de juiste fit is
Als je echte onderbrekingen legitiem zijn — Slackberichten van teamgenoten, oproepen vanuit een wachtdienstrooster — dan zou geen enkele blokkeerder daar aan moeten komen, en een te brede blokkeerlijst bouwen zorgt er gewoon voor dat hij wordt uitgezet de eerste keer dat hij iets echt urgents blokkeert. En voor een geplande, diepgeconcentreerde codeersprint met een harde deadline kan een strengere, niet-onderhandelbare vergrendeling zoals Cold Turkey beter werken dan herhaalde wrijving, die van nature altijd uiteindelijk te omzeilen is. Het is ook eerlijk om te zeggen dat dit geen onderbrekingscultuur op teamniveau oplost — als het echte probleem een verwachting van instant reactie op elk kanaal is, is dat een norm die het team rechtstreeks moet aanpakken, en geen individuele blokkeertool, hoe goed ook geconfigureerd, verandert wat een leidinggevende of een team daadwerkelijk verwacht. De taak van de tool is smal en specifiek — de kosten van de reflexieve, laagwaardige check verhogen — en het is de moeite waard om helder te zien dat hij nooit bedoeld was om de reactietijdcultuur van een team op zijn eentje op te lossen.