O problema específico para programadores é o quão cara é realmente uma interrupção em relação a quase qualquer outro tipo de trabalho. Segurar na cabeça uma função complexa, uma pilha de chamadas inteira, ou a causa provável de um bug traiçoeiro é um tipo frágil de concentração, e uma verificação do telemóvel de trinta segundos não custa apenas trinta segundos — pode custar os dez ou quinze minutos que leva a reconstruir esse modelo mental do zero, o que é a razão pela qual os programadores costumam descrever ter perdido uma hora inteira de produtividade com o que, visto de fora, parecia apenas um par de pausas curtas. A investigação sobre mudança de contexto em trabalho de conhecimento constata consistentemente que retomar uma tarefa complexa depois de uma interrupção demora significativamente mais tempo do que a própria interrupção, e para a programação especificamente — onde o «contexto» é um modelo mental inteiro de um sistema, não apenas uma linha de pensamento — essa diferença tende a ser pior do que na maioria dos outros tipos de trabalho. É parte da razão pela qual tanta literatura sobre cultura de engenharia de software trata horários de «maker» e blocos longos e ininterruptos como um requisito real de produtividade, e não um extra agradável — o custo da fragmentação neste tipo de trabalho é mensuravelmente pior do que em funções onde as tarefas são mais curtas e naturalmente mais interrompíveis.
O que provavelmente já experimentaste
Não Incomodar durante compilações e revisões de código, auscultadores com cancelamento de ruído como sinal social de não incomodar, um bloqueador de sites para o Stack Overflow que de alguma forma sempre inclui uma exceção para «só esta pesquisa», e provavelmente uma app de bloqueio gratuita desinstalada na primeira vez que interferiu com a necessidade legítima de consultar documentação ou uma mensagem de Slack do trabalho a meio de uma depuração. Temporizadores estilo Pomodoro ajudam alguns programadores a ritmar uma sessão longa, mas um temporizador que termina a meio de uma depuração não sabe nem quer saber que estavas a trinta segundos de encontrar o bug, e fazer a pausa mesmo assim porque o temporizador manda pode ser tão disruptivo quanto a própria distração que pretendia evitar. Algumas equipas tentam «horas de foco» partilhadas como norma, o que ajuda quando toda a gente realmente as respeita, mas uma norma sem qualquer mecanismo de aplicação tende a corroer-se na primeira vez que um prazo faz uma exceção parecer justificada, para alguém, algures na equipa.
Porque é que os conselhos genéricos sobre bloqueio falham especificamente aqui
«Bloqueia as redes sociais durante o horário de trabalho» não vê que o verdadeiro leque de distrações de um programador é mais amplo e mais adjacente ao trabalho do que o da maioria das pessoas — fóruns, agregadores de notícias como o Hacker News, notificações do GitHub, uma dúzia de separadores do browser que parecem todos vagamente justificáveis como «tecnicamente relacionados com trabalho». Uma lista de bloqueio construída para um trabalhador de escritório genérico não se aplica bem a esta mistura específica, e uma construída de forma demasiado estreita deixa as verdadeiras fugas completamente abertas. Também tende a tratar todas as interrupções como igualmente más, quando na prática o dano é proporcional a quão profundo era o estado mental no momento da interrupção — uma verificação rápida durante uma revisão de código de rotina custa muito menos do que a mesma verificação a meio de rastrear uma condição de corrida, e um bloqueio único para tudo não distingue entre as duas coisas. Uma ferramenta construída em torno de uma única categoria fixa de «redes sociais» também não vê que, para muitos programadores, a tentação não é nada disso — é um site ostensivamente adjacente ao trabalho, fácil de justificar no momento e igualmente eficaz a consumir uma hora.
O encaixe honesto
Um bloqueio com quiz encaixa bem aqui porque o atrito de responder a uma pergunta real é um tipo de envolvimento cognitivo semelhante ao próprio trabalho — não oferece uma saída mais fácil e passiva como um temporizador de contagem decrescente ou um toque de cinco segundos oferecem. E porque a lista de bloqueio é totalmente personalizável, pode ser construída em torno das apps e sites específicos que realmente consomem o tempo de um determinado programador, em vez de uma categoria genérica de «redes sociais» que perde metade das fugas reais. Como as perguntas alternam entre um banco de cultura geral em vez de testarem algo sobre o próprio código, responder a uma delas não se torna acidentalmente a sua própria forma de procrastinação — um modo de falha comum em ferramentas de produtividade gamificadas que recompensam o envolvimento com o bloqueador em vez do envolvimento com o trabalho em si. Essa personalização importa mais aqui do que na maioria das outras profissões, porque a verdadeira lista de distrações de um programador raramente coincide com a de qualquer outra pessoa, e uma ferramenta que não pode ser moldada à lista real acaba demasiado solta para importar ou demasiado rígida para sobreviver.
Onde não é o encaixe certo
Se as tuas verdadeiras interrupções forem legítimas — mensagens de Slack de colegas de equipa, chamadas de uma rotação de piquete — nenhum bloqueador devia sequer tocar-lhes, e construir uma lista de bloqueio demasiado ampla vai simplesmente levar a que seja desativada na primeira vez que bloquear algo genuinamente urgente. E para um sprint de codificação de foco profundo e agendado, com um prazo apertado, um bloqueio mais rígido e sem negociação como o Cold Turkey pode servir melhor do que atrito repetido, que, por design, pode sempre ser eventualmente ultrapassado. Também é honesto dizer que isto não resolve a cultura de interrupções ao nível de equipa — se o verdadeiro problema for uma expectativa de resposta instantânea em todos os canais, isso é uma norma que a equipa precisa de resolver diretamente, e nenhuma ferramenta de bloqueio individual, por bem configurada que esteja, muda o que um gestor ou uma equipa realmente espera. O trabalho da ferramenta é estreito e específico — elevar o custo da verificação reflexiva e de baixo valor — e vale a pena ser claro que ela nunca foi feita para resolver sozinha a cultura de tempo de resposta de uma equipa.