Ainda que possa parecer o título de um “filme de terceira categoria”, qualquer semelhança é apenas mera coincidência fruto de um qualquer infortúnio das palavras! Passando as brincadeiras, e mudando para o verdadeiro assunto do artigo, todos ouvimos falar de interrupts (sinal emitido pelo hardware ou software enviado ao processador, indicando que um evento necessita de atenção imediata), para os mais “vintage” da tecnologia que passaram pelos “tormentos” de configurar os interrupts nas BIOS cada vez que se acrescentava uma placa num PC, o conceito será certamente mais familiar, mas não se trata de interrupts de hardware ou software que escrevo! Trata-se antes das “interrupções” no trabalho de um programador e na relação das interrupções com a produtividade.

Todos nós certamente já passamos por situações em que as tarefas que estamos a realizar necessitam de atenção focada e exclusiva, sem distracções ou interrupções, sem ruídos nem perturbações da concentração, para podermos manter o ritmo e a concentração no que estamos a fazer. Ao contrário do ficcionado tantas vezes em televisão ou cinema, programar não é digitar código freneticamente, é desenvolver raciocínios que permitam digitar código eficiente, seguro, estável, e não digitar a velocidades estonteantes, como quem escreve um qualquer texto numa rede social, enquanto toma café, escuta música e fala ao telefone.

Um programador, quando está a trabalhar, numa grande parte das vezes está num estado de uma quasi-meditação, numa espécie de “bolha protectora”, onde a “velocidade do tempo é definida por ele”, onde o próprio som da música que possa estar a ouvir na realidade acaba sendo uma espécie de “silêncio”, na medida em que reflecte uma ausência de sons que possam retirar a sua atenção do seu raciocínio e da tarefa em curso.

Vejo vezes por demais, programadores a quem é pedido que não usem headphones, durante as horas de trabalho, a quem é exigido que respondam a todo o tipo de solicitações enquanto realizam o seu trabalho, interrompendo-o de forma quase constante, quer seja para responder a um simples email, quer seja para algo tão questionavelmente desnecessário como responder verbalmente a uma qualquer questão à qual já respondeu seja por email, seja por qualquer outra via, mas que a pessoa inquiridora, não quer despender tempo a ler a resposta, optando por um “atalho”, sem se preocupar com as consequências que esse “atalho” possa ter para quem está efectivamente concentrado a realizar uma tarefa complexa. Para quem essa interrupção poderá significar horas de esforço para retomar o trabalho no ponto em que estava quando foi interrompido.

Honestamente não entendo esta “dislexia” de atitude, numa espécie de “contra-senso” de pessoas que apesar de muitas vezes serem altamente instruídas, não parecem entender ou ter conhecimento de nenhum dos diversos estudos que comprovam que uma tarefa interrompida, leva o dobro do tempo a ser terminada.

Segundo alguma documentação e estudos realizados um programador leva em média 15 minutos a entrar no seu estado de concentração para trabalhar. Ou seja cada interrupção custará pelo menos mais 15 minutos de tempo, na execução das tarefas! Considerando como média de interrupções num dia um valor de 4, pode-se considerar que 1h do dia é completamente desperdiçada! Essa mesma hora pode ser motivo de tensão e stress, para o programador, reduzindo ainda mais a produtividade.

Num estudo realizado por Chris Parnin, onde foram analisadas 10.000 sessões de programação de 86 programadores, e um questionário a 414 programadores, concluíram o seguinte:

• Um programador leva em média 10 a 15 minutos de tempo, a retomar uma tarefa, após ter sido interrompido.
• Quando interrompido durante a edição de um método, apenas 10% das vezes o programador retomou o seu trabalho em menos de 1 minuto.
• Um programador é provável que apenas tenha duas horas por dia de trabalho sem interrupções.
• A maioria dos programadores navega para diversos locais para reconstruir o contexto, antes de resumir a tarefa.
• Muitas vezes forçam erros de compilação para relembrarem o raciocínio.

Ou seja, cada interrupção, causa não só stress, e perda de tempo, como se traduz em ineficiência, perda do “equilíbrio”, e perda da qualidade do trabalho. Não obstante de tudo isto, numa esmagadora maioria das vezes, constato que quem trabalha com programadores, nem sempre tem a percepção do mal que fazem as interrupções e as distracções cada vez maiores.

Se a toda esta situação acrescentarmos a “aparente fixação patológica” pelos “ing’s”, que parece assolar a cultura portuguesa, (pressing, forcing, etc…”ing”), denote-se bem a sátira, é quase impossível um programador não ter algumas vezes a necessidade soberana de férias, tão pouco de cometer erros de programação, ou de escrever código que nem sempre faz grande sentido! Tão pouco e ainda que não apenas português, de deixar comentários quase humorísticos no código como um que se tornou conhecido a quando da divulgação do código fonte da framework .Net “//this is a hack for this release”. Existem diversas “piadas privadas” noutros exemplos de software, mas não valerá a pena citar mais, pois o objectivo é apenas ilustrar a situação.

É complicado explicar a um colega ou um gestor de projecto ou mesmo a qualquer pessoa que não seja programador, o quão complexo é estar no meio de um raciocínio complexo e ter de o suspender!

Não havendo uma fórmula “mágica”, para explicar isso a uma pessoa, existem algumas formas mais ou menos lúdicas, de o ilustrar de forma perceptível! Uma delas que até parece trivial é pedir a quem interrompe, depois de devidamente atendido, para fazer um favor. No caso somar uma lista de números, tipo “0+987+765+543+321+012+234+456+678+9”, sem recorrer a papel e caneta. Enquanto o interlocutor executa a operação, interrompe-lo em lapsos de tempo irregulares! Até se pode oferecer café, ou mesmo o almoço ao interlocutor, de forma a tentar tornar o desafio mais interessante, no entanto não pode escrever nada, nem usar papel ou qualquer instrumento para escrever. Mas em qualquer dos casos nunca deixar que o nosso interlocutor execute a tarefa, sem se distrair ou ser interrompido! Passados cerca de 2 minutos, que tal dizer que apenas restam 15 segundos para terminar a operação, e poucos segundos depois começar a “contagem decrescente”. Como é óbvio, o interlocutor não irá conseguir resolver a operação, acabando por desistir ou manifestar-se incomodado. Assim que pare e perceba que não existe forma de conseguir realizar a operação, será mais fácil explicar porque ser interrompido vezes sem conta, bem como sentir-se pressionado, apenas dificulta mais o trabalho e faz aumentar o lapso de tempo despendido a realizar o mesmo! Sim, é apenas uma brincadeira, mas como o leitor deve entender, é uma forma lúdica de ilustrar a dificuldade que um programador tem, quando é constantemente interrompido ou pressionado.

A título de conclusão deste artigo de opinião, recomendo vivamente a leitura do estudo de Chris Parnin, sobre este mesmo tema, pois creio ser deveras interessante.