O ruído que sobra no silêncio do Slack
Terminei de fechar o VS Code agora. São quase sete da noite e a última mensagem que recebi no Slack ainda está ali, martelando. “Acho que talvez alguém precise dar uma olhada rápida naquele bug urgente, é só um ajuste.” É impressionante como uma frase tão curta consegue carregar tanta incerteza. Fiquei olhando para aquilo e pensando no tempo que a gente perde tentando decifrar o que as pessoas realmente querem dizer quando não estão na nossa frente.
Comunicação assíncrona era para ser a nossa salvação, o paraíso dos introvertidos. Sem reuniões, sem interrupções, apenas o texto. Mas a realidade é que o texto aceita qualquer coisa, inclusive a nossa insegurança. No código, a gente busca clareza. Um booleano não é “talvez verdadeiro”. Um ponteiro não aponta para “algum lugar por aí”. Mas, quando abrimos a caixa de mensagens, parece que todo esse rigor analítico desaparece.
Sempre notei que existem certas palavras que funcionam como um código mal escrito. Elas compilam, mas o resultado é imprevisível. Elas minam a confiança de quem lê, mesmo que quem escreveu não tenha percebido.
O peso do “acho” e do “talvez”
Eu me pego usando o “acho” mais do que gostaria. É uma espécie de proteção, um buffer contra o erro. Se eu digo que “acho que o problema é no banco de dados”, e não for, eu tecnicamente não menti. Mas, no ambiente assíncrono, onde a resposta pode demorar duas horas para vir, o “acho” é um desperdício de tempo. Ele gera uma dúvida desnecessária no outro desenvolvedor.
O “talvez” segue a mesma linha. Ele é o estado de indefinição absoluta. Quando alguém me manda um “talvez possamos subir o deploy hoje”, eu não sei se preparo o café ou se desligo o computador. É uma palavra que mata a credibilidade porque sinaliza que a pessoa não se deu ao trabalho de validar a informação antes de apertar o enter. No fim das contas, a gente escreve para se livrar do peso da decisão e joga a bola murcha para o outro.
Essa ambiguidade costuma gerar o mesmo tipo de tensão que aparece quando recebemos uma crítica vaga em reunião. A falta de precisão cria insegurança dos dois lados. Falei mais sobre como responder a esse tipo de situação em 5 Frases para Responder Críticas Inesperadas em Reuniões.
A armadilha do “tentar”
Outra que me incomoda profundamente é o “tentar”. “Vou tentar corrigir isso até amanhã.” Na minha cabeça, isso soa como um try-catch que já nasce com o catch pronto para ser executado. Quem tenta, já está aceitando a possibilidade da falha antes mesmo de começar. É muito diferente de dizer “vou investigar até tal hora e te dou um retorno”.
O “tentar” é vago. Ele não estabelece um compromisso, apenas uma intenção murcha. Em TI, a gente lida com sistemas determinísticos. O servidor não “tenta” rodar o script; ele roda ou falha. Quando a gente leva esse “tentar” para a comunicação, parece que estamos admitindo que não temos controle sobre o próprio processo.
A desvalorização do “apenas” e do “só”
Essa talvez seja a mais perigosa para quem lida com prazos. “É só uma alteração simples”, “É apenas um ajuste no CSS”. No momento em que você usa essas palavras, você está diminuindo o próprio trabalho e, pior, o do colega. Nada em um sistema complexo é “apenas”. Um ajuste simples pode quebrar uma herança que ninguém lembrava que existia.
Quando eu leio um “é só fazer isso”, sinto que a pessoa está tentando me manipular para aceitar uma tarefa sem questionar a complexidade real. Isso mata a credibilidade porque demonstra uma falta de visão sistêmica. Quem entende de verdade de código sabe que o “só” é o prelúdio de um final de semana perdido recuperando backup. É uma palavra que ignora o risco.
O “urgente” que não significa nada
Trabalhar em suporte ou infra ensina que, se tudo é urgente, nada é urgente. O uso indiscriminado dessa palavra no assíncrono é um dos maiores causadores de burnout silencioso que eu já vi. A pessoa escreve “URGENTE” no assunto, mas quando você abre, é algo que poderia esperar dois dias.
A credibilidade morre aqui porque você para de acreditar na gravidade dos problemas relatados por aquela pessoa. É o famoso bug que gritou lobo. Depois da terceira “urgência” que era apenas um capricho estético, o cérebro começa a filtrar e ignorar. O canal de comunicação fica poluído, o sinal-ruído se perde.
A fuga do “alguém”
“Alguém pode ver o que está acontecendo no staging?” Essa frase é o vácuo da responsabilidade. Quando você solta um “alguém” num canal com vinte pessoas, você está falando com ninguém. É a difusão de responsabilidade em forma de texto.
Sempre que vejo isso, percebo que ninguém quer ser o dono do problema. A comunicação assíncrona exige nomes. Exige que a gente aponte a direção. Quando jogamos um “alguém” no ar, estamos apenas fazendo barulho, esperando que um herói apareça para nos salvar da nossa própria inércia de não querer designar uma tarefa ou assumi-la.
No fundo, isso é uma falha de estrutura da mensagem. Quando a dúvida é vaga ou mal direcionada, o resultado é dispersão. Exploro uma forma mais clara de estruturar pedidos técnicos em Dúvidas Técnicas: Clareza na Ajuda
O cansaço da “rapidinha”
“Pode entrar numa call rápida?” No mundo ideal, isso seria inofensivo. No mundo real de quem precisa de foco profundo para entender um fluxo de dados, a “call rápida” é um sequestro. Ela mata a premissa do assíncrono. Geralmente, quem pede isso é quem não quis ter o trabalho de escrever de forma clara e prefere descarregar o fluxo de consciência de forma verbal, interrompendo o fluxo de quem está do outro lado.
Dizer que vai ser “rápido” quase nunca é verdade. É uma promessa falsa que a gente faz para o outro se sentir menos culpado por ser interrompido. E, depois de algumas vezes, a gente para de atender, para de responder. A credibilidade de quem pede essas interrupções constantes vai para o ralo porque mostra que o tempo dele é mais valioso que o nosso.
O que sobra no fim do dia
Escrevendo isso agora, percebo que o problema não são as palavras em si, mas o que elas escondem. Elas são sintomas de uma preguiça mental ou de um medo de se posicionar. A gente usa esses termos para amaciar o impacto, para não parecer ríspido ou para não ser responsabilizado se algo der errado.
O engraçado é que a gente passa o dia tentando escrever um código limpo, sem ambiguidades, com nomes de variáveis que façam sentido. Aí a gente vai para o Slack e escreve como se estivesse jogando palavras num liquidificador. É como se houvesse uma desconexão entre o profissional técnico e o profissional que se comunica.
No fim, a credibilidade não vem de ser o gênio que resolve tudo, mas de ser a pessoa em quem os outros podem confiar quando leem uma mensagem. Se eu digo que está pronto, está pronto. Se eu digo que não sei, eu realmente não sei, e não fico camuflando isso com “achos” e “talvez”. É cansativo manter essa vigilância sobre a própria escrita, mas o custo de não fazer isso é viver num eterno estado de mal-entendido.
Talvez o que mais me incomode não seja nem o uso dessas palavras pelos outros, mas o quanto eu ainda dependo delas para me sentir seguro em conversas que eu não queria estar tendo.
É curioso como essa necessidade de se proteger através da ambiguidade parece aumentar proporcionalmente ao tamanho da responsabilidade que a gente recebe. Fico pensando se esse vício de linguagem não é apenas o reflexo de algo mais profundo sobre como a gente lida com a visibilidade dentro do time. Tem algo aí que eu ainda não consegui isolar, uma espécie de bug na forma como a gente se expõe quando o código não é a única coisa que está sendo julgada.
Continue aprofundando
Se comunicação escrita é um ponto sensível no seu dia a dia, estes textos ampliam essa reflexão:
• Escuta Ativa: A Técnica Simples Para Ser O Mais Inteligente Da Sala
• 4 Erros de Comunicação no Slack que Geram Bugs
• 7 Táticas Anti-Ansiedade: Domine Reuniões no Zoom/Teams
