São quase sete da noite e a luz do monitor é a única coisa que realmente sobra aqui no quarto. Acabei de fechar um chamado que levou três horas a mais do que deveria, e nem foi por causa do código em si. Foi por causa de uma mensagem que recebi às duas da tarde. “Não está funcionando”, dizia o texto no Slack, sem anexo, sem log, sem contexto. Fiquei olhando para aquilo por um tempo, sentindo aquele cansaço mental que a gente conhece bem, tentando adivinhar o que o outro lado queria. É estranho como a nossa área, que é puramente baseada em lógica e troca de dados, falha tanto quando a gente precisa trocar informação entre seres humanos.
Eu já estive do outro lado também. Muitas vezes. Aquele silêncio que a gente guarda quando não sabe como explicar que está travado. A gente fica ali, batendo a cabeça no teclado, achando que pedir ajuda é admitir uma falha grave de sistema no nosso próprio cérebro. Ou então, no desespero, a gente joga a dúvida de qualquer jeito, esperando que o outro tenha uma bola de cristal. Mas o que aconteceu hoje me fez pensar que essa nossa dificuldade em transformar um problema técnico em uma pergunta clara não é preguiça. É um bug de comunicação que a gente carrega desde o começo da carreira.
Muitas vezes, a dúvida técnica é um amontoado de sensações antes de virar uma pergunta. É aquele incômodo de que o deploy vai quebrar, ou a percepção de que aquela query está demorando mais do que o normal, mas a gente não sabe quantificar. Quando eu escrevo “está estranho”, eu estou sendo honesto, mas estou sendo inútil para quem vai ler. O problema é que, para ser claro, a gente precisa de um esforço cognitivo que, no meio de uma crise, a gente simplesmente não tem. É mais fácil despejar o lixo mental no outro.
Lembro de uma reunião, há uns dois anos, onde passamos quarenta minutos tentando entender o que um desenvolvedor sênior estava perguntando. Ele era brilhante, mas a pergunta dele era uma colcha de retalhos de suposições. Ele não estava perguntando nada, na verdade; ele estava apenas pensando alto e esperando que alguém validasse o caos. A gente faz muito isso. A gente confunde “pedir ajuda” com “transferir a responsabilidade de pensar”. E quando a resposta não vem, ou vem errada, a gente se sente isolado, como se ninguém falasse a nossa língua.
O que eu percebo agora, olhando para o log de hoje, é que a clareza numa pergunta técnica é quase como um refactoring. Você tem a primeira versão da dúvida, que é suja, cheia de dependências desnecessárias e comentários inúteis. Se você joga isso direto na produção — ou seja, no chat da equipe — o sistema trava. Ninguém responde porque ninguém entendeu o que é para ser feito. O segredo, se é que existe um, talvez seja tratar a própria dúvida como um bug report que você mesmo teria que resolver.
Se eu recebo “o banco caiu”, eu perco dez minutos só perguntando “qual banco?”. Mas se a mensagem é “perdi conexão com a instância de staging após o merge da branch X”, o caminho já está metade percorrido. Parece óbvio falando assim, mas no dia a dia, com o backlog gritando no ouvido e o cansaço acumulado de reuniões que não chegam a lugar nenhum, o óbvio é a primeira coisa que a gente descarta. A gente quer ser rápido, então a gente corta caminho na explicação. Só que esse atalho é o que faz a ajuda demorar duas horas para chegar.
Às vezes, acho que a gente tem medo da exposição. Se eu detalho demais a minha dúvida, eu mostro exatamente onde o meu conhecimento termina. E para quem é introvertido e técnico, esse limite é um lugar desconfortável. É mais seguro ser ambíguo. Se eu sou vago, eu posso fingir que o problema é a ferramenta, não a minha falta de compreensão sobre ela. É uma falha silenciosa, um erro que não gera log, mas que drena a produtividade do time inteiro.
Eu ando tentando mudar o jeito que eu escrevo essas coisas. Não por um método novo, mas por cansaço mesmo. Cansei de ver conversas em loop. Hoje, antes de mandar qualquer coisa, eu tento ler a minha própria pergunta como se eu fosse um estranho. “Eu conseguiria resolver isso com essas informações?”. Geralmente a resposta é não. Então eu volto, adiciono o contexto que eu achei que era implícito, tiro os adjetivos e deixo só os fatos. É quase um processo de compilação. Se tem erro de sintaxe na pergunta, ela não vai rodar na cabeça de quem recebe.
Engraçado pensar que a gente gasta tanto tempo aprendendo sintaxe de linguagem de programação, mas gasta quase nada refinando a sintaxe do pedido de ajuda. No fim, a gente acaba isolado em silos de incompreensão mútua. O sênior reclama que o júnior não sabe perguntar, o júnior reclama que o sênior não tem paciência para explicar, e o problema continua lá, parado no código, enquanto o ego de todo mundo fica levemente ferido.
Talvez o que falte seja aceitar que pedir ajuda de forma clara é uma tarefa técnica tão importante quanto escrever um teste unitário. Exige o mesmo rigor, a mesma análise. Não é “soft skill”, como o pessoal do RH gosta de dizer. É lógica pura aplicada à comunicação. Se os inputs da minha pergunta estão zoados, o output da ajuda vai ser nulo.
Vou fechar o notebook agora. Já é tarde e essa tela já está me dando dor de cabeça. O chamado está resolvido, a dúvida foi sanada, mas o peso de como as coisas chegaram nesse ponto ainda está aqui. A gente resolve o bug do sistema, mas o bug do processo continua rodando em background, consumindo memória sem a gente perceber.
É curioso como essa necessidade de ser entendido o tempo todo acaba esbarrando em outros silêncios que a gente mantém, mesmo quando não tem nenhum erro no console. Isso de tentar ser claro para o outro acaba revelando o quanto a gente é confuso com a gente mesmo em situações que não envolvem código. Talvez eu ainda não tenha entendido onde essa falta de conexão começa de verdade.
