Le problème précis pour les développeurs, c'est à quel point une interruption coûte réellement cher par rapport à presque tout autre type de travail. Tenir en tête une fonction complexe, toute une pile d'appels, ou la cause probable d'un bug retors est une forme de concentration fragile, et vérifier son téléphone pendant trente secondes ne coûte pas seulement trente secondes — cela peut coûter les dix ou quinze minutes qu'il faut pour reconstruire ce modèle mental à partir de rien, ce qui explique pourquoi les développeurs décrivent souvent avoir perdu une heure entière de productivité à cause de ce qui ressemblait, de l'extérieur, à deux courtes pauses. La recherche sur le changement de contexte dans le travail intellectuel constate systématiquement que reprendre une tâche complexe après une interruption prend significativement plus de temps que l'interruption elle-même, et pour la programmation en particulier — où le « contexte » est tout un modèle mental d'un système, pas seulement un fil de pensée — cet écart a tendance à être pire que dans la plupart des autres types de travail. C'est en partie pourquoi tant d'écrits sur la culture de l'ingénierie logicielle traitent les horaires de « créateurs » et les longues plages ininterrompues comme une véritable exigence de productivité plutôt qu'un simple plus — le coût de la fragmentation dans ce type de travail est mesurablement pire que dans des postes où les tâches sont plus courtes et plus interruptibles par nature.
Ce que vous avez probablement déjà essayé
Le mode Ne pas déranger pendant les compilations et les revues de code, un casque à réduction de bruit comme signal social de ne pas être interrompu, un bloqueur de sites web pour empêcher de sauter d'un onglet Stack Overflow à l'autre qui inclut toujours, on ne sait comment, une exception pour « juste cette recherche-là », et probablement une application de blocage gratuite désinstallée la première fois qu'elle a gêné le besoin légitime de consulter la documentation ou un message Slack professionnel en plein débogage. Les minuteurs de type Pomodoro aident certains développeurs à rythmer une longue séance, mais un minuteur qui se termine en plein débogage ne sait pas et ne se soucie pas que vous étiez à trente secondes de trouver le bug, et prendre la pause quand même parce que le minuteur le dit peut être tout aussi perturbateur que la distraction qu'il était censé prévenir. Certaines équipes essaient des « heures de concentration » partagées comme norme, ce qui aide quand tout le monde les respecte réellement, mais une norme sans mécanisme de mise en application a tendance à s'éroder la première fois qu'une échéance rend une exception justifiée, pour quelqu'un, quelque part dans l'équipe.
Pourquoi les conseils de blocage génériques échouent spécifiquement ici
« Bloquez les réseaux sociaux pendant les heures de travail » méconnaît que le menu de distractions réel d'un développeur est plus large et plus proche du travail que celui de la plupart des gens — forums, agrégateurs de nouvelles comme Hacker News, notifications GitHub, une douzaine d'onglets de navigateur qui semblent tous vaguement justifiables comme « techniquement liés au travail ». Une liste de blocage construite pour un employé de bureau générique ne correspond pas proprement à ce mélange précis, et une liste construite trop étroitement laisse grandes ouvertes les vraies fuites. Elle a aussi tendance à traiter toutes les interruptions comme également mauvaises, alors qu'en pratique le dommage est proportionnel à la profondeur de l'état mental au moment de l'interruption — une vérification rapide pendant une revue de code de routine coûte bien moins cher que la même vérification au milieu du traçage d'une condition de concurrence, et un blocage universel ne fait pas la distinction entre les deux. Un outil construit autour d'une seule catégorie fixe « réseaux sociaux » méconnaît aussi que pour beaucoup de développeurs, la tentation n'est pas du tout les réseaux sociaux — c'est un site apparemment lié au travail, facile à justifier sur l'instant et tout aussi efficace pour engloutir une heure.
La pertinence honnête
Un blocage conditionné par un quiz convient bien ici parce que la friction de répondre à une vraie question est un type d'engagement cognitif similaire au travail lui-même — il n'offre pas d'échappatoire plus facile et plus passive comme le fait un compte à rebours ou un tap de cinq secondes. Et comme la liste de blocage est entièrement personnalisable, elle peut être construite autour des applications et des sites précis qui grignotent le temps d'un développeur donné, plutôt qu'une catégorie générique « réseaux sociaux » qui rate la moitié des vraies fuites. Comme les questions tournent dans une banque de culture générale plutôt que de tester quoi que ce soit sur le code lui-même, y répondre ne devient pas accidentellement sa propre forme de procrastination — un mode d'échec courant des outils de productivité gamifiés qui récompensent l'engagement avec le bloqueur plutôt que l'engagement avec le travail réel. Cette configurabilité compte plus ici que dans la plupart des autres métiers, parce que la liste réelle de distractions d'un développeur ne correspond presque jamais à celle de quiconque d'autre, et un outil qui ne peut pas être façonné à la liste réelle finit soit trop lâche pour compter, soit trop strict pour survivre.
Là où ce n'est pas la bonne solution
Si vos interruptions réelles sont légitimes — des messages Slack de coéquipiers, des alertes d'une astreinte — aucun bloqueur ne devrait y toucher du tout, et construire une liste de blocage trop large finira simplement par être désactivée la première fois qu'elle bloque quelque chose de véritablement urgent. Et pour un sprint de codage programmé, en concentration profonde, avec une échéance ferme, un verrou plus strict et non négociable comme Cold Turkey peut mieux servir qu'une friction répétée, qui, par conception, peut toujours finir par être contournée. Il est aussi honnête de dire que cela ne résout pas la culture de l'interruption au niveau de l'équipe — si le vrai problème est une attente de réponse instantanée sur chaque canal, c'est une norme que l'équipe doit traiter directement, et aucun outil de blocage individuel, aussi bien configuré soit-il, ne change ce qu'un manager ou une équipe attend réellement. Le rôle de l'outil est étroit et précis — augmenter le coût de la vérification réflexe et à faible valeur — et il vaut la peine d'être lucide sur le fait qu'il n'a jamais été conçu pour réparer, à lui seul, la culture du temps de réponse d'une équipe.