O ponto final do dia é sempre aquela hora que a gente tenta botar ordem na cabeça. Apagar as luzes da IDE, fechar os terminais, e às vezes, a cabeça ainda tá girando com a última daily, ou aquele comentário ambíguo num pull request. Hoje, pensando na tal “progressão para sênior”, que tanto falam, me peguei refletindo sobre o que a gente faz que, sem perceber, nos freia. Não é sobre falta de skill técnica, isso a gente corre atrás, refatora, debuga. É sobre umas coisas mais… etéreas, talvez. Umas falhas silenciosas no nosso próprio “branding pessoal”, se é que dá pra chamar assim.
Lembro de uma reunião que tive, sei lá, semana passada. O assunto era um backend novo, um módulo crítico. Tinha uns caras lá falando alto, defendendo pontos, às vezes com uma veemência que parecia mais teatral do que técnica. Eu, como de costume, estava mais na escuta, processando as informações, tentando visualizar os fluxos, os possíveis gargalos. Tinha um ponto específico, uma decisão de arquitetura, que eu tinha certeza que ia dar problema lá na frente, um bug chato, difícil de reproduzir. Esperei uma brecha. A brecha não veio. Ou eu não criei a minha. No fim, a decisão foi tomada, e eu saí de lá com aquela sensação de “devia ter falado”. Não é que eu fosse o dono da verdade, mas era um insight válido, baseado em experiências passadas. O silêncio, ali, não foi ouro. Foi… só silêncio. E o que ficou para os outros? Provavelmente, nada. Ou, pior, uma imagem de desinteresse. Como um código que não tem comentários, e ninguém entende a intenção.
A gente, muitas vezes, assume que o bom trabalho fala por si só. Que as linhas de código bem escritas, os deployments sem sustos, a refatoração elegante de um módulo legado vão ser notados. E, em certa medida, são. Mas não da forma que a gente imagina. O mérito técnico é fundamental, claro. Mas o caminho para o sênior parece passar por uma camada a mais, um tipo de “interface” com o mundo exterior que a gente nem sempre domina. É como ter um sistema robusto, com APIs internas bem definidas, mas sem uma boa documentação ou exemplos claros de uso para quem vai consumir. O sistema é bom, mas a adoção é lenta.
Outro dia, um colega me perguntou sobre um problema num script. Eu resolvi rápido, coisa simples, um ajuste no PATH. Ele agradeceu, e eu, como sou, só disse “de boa”. Mas, pensando bem, aquela era uma oportunidade de mostrar como cheguei na solução, de explicar o raciocínio por trás, não só a resposta. É uma diferença sutil, mas que muda a percepção. Em vez de “o cara que resolve”, vira “o cara que resolve e me ajuda a entender”. É como a diferença entre entregar um código funcionando e entregar um código funcionando com testes unitários e uma arquitetura que facilita a manutenção futura. Ambos funcionam, mas um agrega mais valor de forma visível.
E o feedback, então? A gente é muito bom em receber feedback técnico, em aprimorar uma função, em otimizar um algoritmo. Mas quando o feedback é sobre “comunicação”, “proatividade” ou “postura”, a gente trava um pouco. Porque não é algo tão tangível quanto uma variável mal nomeada. É mais subjetivo. Lembro de um período em que meu gestor me deu um feedback meio vago: “precisa se expor mais”. Eu fiquei dias pensando no que isso significava. Eu não era de falar muito. Sempre fui de fazer. Pra mim, “expor” era quase como se exibir. E isso não combinava com minha natureza. Mas ele não estava falando de exibir, ele estava falando de “ser visto”. De “deixar claro o que você pensa e o que você faz”. Como um commit que precisa de uma boa mensagem para contextualizar as mudanças, e não só “fix bug”.
A gente tem um jeito de se comunicar que é eficiente entre nós, de TI. Direto ao ponto, técnico. Mas o mundo fora da nossa bolha nem sempre opera assim. O pessoal de produto, os stakeholders, eles querem entender o “porquê” antes do “como”. E a gente, às vezes, entrega só o “como” ou, pior, só o resultado final sem o contexto. É um erro de serialização, sabe? A mensagem chega, mas perde um monte de informação relevante no meio do caminho. E aí, quando o projeto avança, e surgem os créditos, os nomes que vêm à tona são os daqueles que, talvez, não fossem os mais técnicos, mas foram os mais “visíveis”, os que souberam “apresentar” o trabalho. Não é questão de ser melhor ou pior, é questão de ser percebido.
Acho que o maior erro é a gente não enxergar que, mesmo no mundo da tecnologia, onde a lógica impera, a percepção é uma variável poderosa. É como um bug que só aparece em produção, em condições específicas. No ambiente de desenvolvimento, tudo funciona, o código está perfeito. Mas no mundo real, com as interações humanas, as coisas mudam. E, pra subir de nível, não basta só ser bom. É preciso parecer bom, no sentido de ser compreendido, de ter o impacto das suas contribuições claramente visível para quem importa. E isso, pra gente, que vive mais no mundo binário, é um ajuste de paradigma bem complicado.
É interessante como certas coisas permanecem um tanto nebulosas, mesmo depois de tanto tempo. A gente passa a vida depurando sistemas, mas depurar a gente mesmo, o jeito como os outros nos veem, parece uma tarefa bem mais difícil. Continua sendo um daqueles problemas que a gente sabe que existe, mas ainda não encontrou a solução elegante.
