Você resolveu aquele bug que fazia o suporte responder o mesmo ticket havia três semanas. Fez tudo sozinho, sem pedir ajuda, e o fix foi mergeado numa quinta-feira às onze da noite. Na sexta, no standup, ninguém comentou nada. Duas semanas depois, seu gestor te pergunta numa 1:1 se você está "engajado" com o projeto, porque quase não te vê nas conversas do time.
Isso acontece o tempo todo com devs seniores no remoto, e quanto melhor você é no seu trabalho, mais isso acontece. Com seis, oito, dez anos de experiência, você resolve as coisas rápido e sem barulho. O problema é que, num time distribuído, sem barulho significa invisível. Ninguém te vê pensando, ninguém te vê iterando, ninguém te vê descartando três soluções antes de chegar na boa. Só veem um PR que apareceu e foi mergeado.
Minha visão é simples: visibilidade no remoto não é uma questão de personalidade nem de "ligar a câmera". É um problema de informação. O time toma decisões melhores quando sabe o que você está pensando, o que você avaliou e por que escolheu o que escolheu. Se essa informação fica só na sua cabeça, quem perde é o time, não só você.
Por que o conselho genérico não serve mais para você
O conselho típico (ligue a câmera, participe das reuniões, dê um alô no canal da empresa) foi pensado para quem está chegando agora e precisa mostrar que está aprendendo rápido. Você já não precisa provar isso. O problema inverso é que, como você precisa cada vez menos de ajuda, acaba se comunicando cada vez menos, e se comunicar menos no remoto passa a impressão de estar menos presente, mesmo quando você está rendendo no máximo.
A solução não é falar mais só por falar. É tornar visível o trabalho de pensar, que num senior é metade do valor real que você entrega.
Documente as decisões, não só o código
Um PR que diz "refactor: novo protocolo interno" não conta nada. Um PR que diz qual problema estava resolvendo, quais alternativas você avaliou e por que a escolhida venceu, conta.
Exemplo concreto: se você migrou um serviço interno de REST para gRPC, o diff não basta. Escreva um documento curto (um ADR de uma página resolve) com o problema real (latência de rede entre microsserviços que estava afetando um SLA), as alternativas que você considerou (manter REST com streaming HTTP, usar GraphQL subscriptions, ir para gRPC) e o trade-off que você aceitou em troca (curva de aprendizado do time, tooling menos maduro em algumas linguagens). Esse documento vale mais para a sua carreira do que o código em si, porque é a prova de que você pensa em sistemas, não só em tickets.
Na Howdy, muitos times usam a descrição do PR como se fosse o ADR: contexto, alternativas, decisão, risco aceito. É de graça, não exige nenhuma ferramenta nova e fica pesquisável para sempre.
Torne-se a pessoa que consultam, não só a que entrega
Existe uma diferença grande entre resolver problemas no privado e resolvê-los onde o time consegue ver. Se alguém te manda uma dúvida técnica no DM e a resposta serve para mais de uma pessoa, responda no canal público do time, não no privado. Não é um truque de marketing pessoal, é evitar que outras três pessoas percam o mesmo tempo na semana que vem.
O mesmo vale quando você resolve algo estranho e não trivial: um bug de concorrência, uma race condition num cron, um edge case numa integração de pagamentos. Escreva dois parágrafos na wiki interna ou no canal do time explicando o que aconteceu e como você diagnosticou. Isso te posiciona como a pessoa que entende o sistema a fundo, que é exatamente o que separa um senior de alguém que só escreve código bom.
Quantifique seu impacto em vez de listar tarefas
Relatórios semanais tipo "trabalhei em X, avancei em Y" são ruído. Ninguém lê duas vezes. Um relatório que diz "reduzi o tempo de build de 14 para 4 minutos ajustando o cache do Docker, o que economiza uns 45 minutos por dia para cada dev do time" é informação que um gestor consegue usar, repetir para cima e lembrar na sua próxima revisão salarial.
Isso não é inflar conquistas. É traduzir trabalho técnico para uma linguagem que o resto da empresa, que não lê seu código, consiga entender e valorizar. Se você não fizer isso, ninguém mais vai fazer por você.
O limite: nem tudo precisa de um anúncio
Isso não é licença para lotar o canal geral de atualizações a cada meia hora. Existe uma diferença entre visibilidade e ruído, e cruzar essa linha tem um custo real: se tudo que você compartilha é de baixo valor, o time aprende a te ignorar justo quando realmente importa.
Reserve a comunicação proativa para os momentos de maior alavancagem: quando você resolve algo que estava travando outras pessoas, quando detecta um problema de arquitetura antes de chegar em produção, quando toma uma decisão que outro time vai herdar. O resto (o trabalho rotineiro do dia a dia) pode entrar no seu relatório semanal, sem precisar narrar em tempo real.
Nada disso substitui o contato humano de verdade: vale a pena aparecer no escritório de vez em quando, se você tiver um por perto, porque o vínculo presencial continua construindo confiança de um jeito que nenhuma ferramenta assíncrona consegue igualar. Na Howdy temos oito escritórios na América Latina justamente para isso, mesmo que o trabalho do dia a dia continue sendo remoto.
Visibilidade num time remoto não se conquista agindo com mais confiança do que você realmente tem, nem participando só por participar. Se conquista transformando em informação compartilhada o trabalho de pensar que você já faz todos os dias. Se você é a pessoa que evita que o time repita erros e ninguém além de você sabe disso, esse é um problema do time, não só seu. Resolver isso começa por escrever melhor sobre o que você já faz bem, não por falar mais.
