Vou te contar uma coisa que aprendi apanhando.
Por muito tempo eu achei que ser um bom programador era sobre código. Aprender a stack certa, ler os livros certos, contribuir com open source, dominar a arquitetura. Faz parte, claro. Mas depois de mais de dez anos nisso, vendo gente subir, gente estagnar, gente sair, gente voltar, eu percebi uma coisa que ninguém me disse logo no começo:
A maior parte da carreira de quem programa não é decidida por código. É decidida por conversa.
Conversa que você teve. Conversa que você evitou. Conversa que você teve tarde demais. Conversa que você teve com o tom errado.
Eu já vi programadores brilhantes ficarem 4 anos no mesmo salário porque nunca souberam pedir aumento. Já vi dev mediano virar tech lead porque sabia se posicionar. Já vi gente sair queimando relacionamento que demorou anos pra construir, por causa de uma demissão mal feita. E já vi gente perder cliente bom porque não soube dizer "esse prazo não dá".
Esse texto é sobre as 5 conversas que mais travam a carreira dos programadores, e como eu aprendi (na marra, quase sempre) a fazer cada uma delas.
Não é manual. Não é fórmula. É o que eu queria que alguém tivesse me contado.
————————————————————————————————————————
CONVERSA 01. QUEM ACEITA TUDO, ENTREGA NADA.
Essa eu errei umas 200 vezes antes de aprender.
Era sempre o mesmo padrão. Vinha uma demanda nova, prazo já vinha definido pela liderança, eu olhava, fazia uma conta de cabeça, percebia que estava apertado, mas pensava "vou dar um jeito". Saía da reunião empolgado por ter mostrado disposição. E aí virava madrugada, comprometia outras entregas, ou simplesmente atrasava com aquela vergonha de quem prometeu o que não conseguiu.
Por anos eu não entendia que dizer sim pra tudo não me fazia parecer mais capaz. Me fazia parecer menos confiável. Porque na conta final, quem promete e não entrega é pior do que quem avisa que não vai dar.
A virada aconteceu quando comecei a fazer uma coisa boba: antes de aceitar qualquer prazo, eu pedia 15 minutos. "Deixa eu olhar com calma e te volto." Esses 15 minutos, mesmo curtos, fazem duas coisas que mudam tudo. Primeiro, te dão espaço pra olhar o que já está no seu prato. Segundo, sinalizam pra outra pessoa que sua resposta tem peso, que você não topa só pra agradar.
E quando o prazo realmente não dá, você não diz "não". Você diz "dá, com essas condições". A diferença é enorme. "Não dá em 3 dias, mas dá em 5". "Dá em 3 dias se eu pausar X". "Dá em 3 dias com uma versão mais simples". Você não vira o dev problemático. Você vira o programador que negocia.
Aceitar tudo pode parecer compromisso mas é o contrário. É a forma mais rápida de virar um entregador medíocre.
————————————————————————————————————————
CONVERSA 02. NINGUÉM VAI TE PROMOVER POR TE VER CANSADO.
Isso demorou uns 3 anos pra eu entender.
Eu trabalhava muito. Entrava cedo, saía tarde, atendia mensagem no fim de semana, resolvia problemas que ninguém pediu pra resolver, ficava acordado pensando em arquitetura. E achava, sinceramente, que isso ia me levar pra algum lugar. Que em algum momento alguém ia bater na minha porta e dizer "olha, você se dedicou muito, está promovido".
Spoiler: nunca aconteceu.
O que eu não tinha entendido é que ninguém na liderança fica olhando quem está cansado. Eles olham quem mostra resultado, quem comunica resultado, e quem se posiciona pra próxima coisa. Você pode estar entregando 3x mais que o resto do time, mas se o resto do time conta melhor o que faz, eles passam na sua frente.
Não é injusto. É o jogo.
A conversa de reconhecimento não é uma só. São várias. É um update bem feito na one-on-one mostrando o que você entregou. É uma mensagem direta pro seu gestor depois de uma entrega importante, contando o impacto que aquilo teve. É chegar na avaliação de performance com documento, com número, com histórico, e não com sentimento. É ter o desconforto de pedir aumento sem rodeio, com pedido específico, com argumento, e não esperar que alguém leia sua mente.
E quando eu finalmente fiz isso, a primeira vez, eu lembro de ter ficado tremendo. Achei que ia ouvir um não. Ouvi um sim. E percebi que tinha passado anos sendo subaproveitado por covardia minha, não por má-fé do outro lado.
A lição que eu queria ter aprendido antes: mostrar valor não é trabalhar dobrado. É comunicar o trabalho de um jeito que o valor seja inegável.
————————————————————————————————————————
CONVERSA 03. NÃO LEVANTAR A BOLA, SAI CARO.
Esse erro eu paguei caro mais de uma vez.
Era assim: estava numa reunião, o cliente ou o PM propunha algo que eu sabia que ia dar errado. Tecnicamente errado. Estrategicamente errado. Eu olhava, fazia a careta interna, mas pensava "ah, não sou eu quem decide, vou só implementar". Engolia. Saía da reunião sabendo que aquilo ia explodir em 3 semanas, mas como ninguém perguntou minha opinião, eu não dei.
Em 3 semanas, explodia. Aí vinha a conversa "como isso aconteceu?" e eu, lá no fundo, sabia que tinha visto. Tinha sentido. Tinha calado.
Essa é uma das conversas mais difíceis da carreira, porque ela junta duas coisas desconfortáveis: discordar de quem está acima de você, e arriscar errar a leitura. Ninguém quer ser o dev chato que sempre acha um problema. Mas tem uma coisa pior: ser o responsável pelo problema!
Aprendi a fazer essa conversa em três movimentos. Primeiro, eu não trato como confronto. Trato como pergunta. "Antes de a gente seguir, eu queria entender melhor X. Pensei nesse cenário e fiquei com uma dúvida, será que faz sentido considerar Y?" Não é falar não, é abrir espaço para discussão.
Segundo, eu separo o que é certeza do que é intuição. Se é uma certeza técnica, eu trago dado, exemplo, referência. Se é intuição, eu digo que é intuição. "Posso estar errado, mas tenho uma sensação ruim sobre isso, vale a pena a gente desenhar antes de implementar?" Isso é diferente de "isso vai dar errado".
Terceiro, e mais importante, eu falo cedo. Falar 2 dias antes do problema acontecer é uma coisa. Falar na reunião do começo do projeto é outra completamente diferente. Quem fala cedo é visto como prudente. Quem fala depois é visto como reclamão.
Responsabilidade técnica não é só escrever bom código. É falar quando você vê algo. Calar é decidir que outra pessoa vai pagar a conta.
————————————————————————————————————————
CONVERSA 04. NÃO FOI O ATRASO. FOI O SILÊNCIO.
Essa eu aprendi de um jeito particularmente doloroso.
Tinha um projeto, prazo apertado, eu sabia desde a segunda-feira que ia atrasar. Sabia mesmo. Mas ficava esperando uma virada, achando que ia compensar, que ia trabalhar à noite, que ia dar conta. Quinta-feira chegou, e o que era um atraso de 1 dia virou um atraso de 4 dias. Aí eu finalmente avisei.
A reação do cliente não foi sobre os 4 dias. Foi sobre os 3 dias em que eu tinha sabido e não tinha falado.
Ele me disse uma frase que eu nunca esqueci: "se você tivesse me avisado na segunda, eu teria 4 dias pra me organizar. Agora eu tenho zero".
Caiu a ficha. O cliente não estava bravo com a engenharia. Estava bravo porque eu tinha tirado dele a possibilidade de reagir.
Atraso, em projeto, é normal. Quase sempre rola alguma coisa: dependência atrasou, escopo cresceu, bug imprevisto, vida real acontecendo. O que separa o dev profissional do dev problemático não é nunca atrasar. É como o atraso é comunicado.
A regra que eu pratico desde aquele dia: no momento em que percebo que vai atrasar, eu já sinalizo. Não espero confirmar. Não espero ter solução. Eu mando uma mensagem do tipo "estou vendo um risco de atraso aqui por causa de X, ainda estou tentando contornar, mas queria te avisar pra você poder se planejar". Isso muda todo o tom da relação. Você vira o profissional que protege o outro, não o que esconde até o último minuto.
E tem mais. Quando você avisa cedo, muitas vezes o outro lado tem informação que você não tem. "Ah, esse cara que ia receber pode esperar 3 dias mesmo, sem problema." Ou "se for atrasar, prefiro adiar pra semana que vem inteiro pra fazer direito." Ou ainda "consigo te conseguir mais 2 pessoas pra te ajudar". Nada disso aparece quando você avisa no dia.
Quem avisa no dia, já era. Não pelo atraso. Pelo silêncio antes dele.
————————————————————————————————————————
CONVERSA 05. DEMISSÃO É ESTRATÉGIA, NÃO DESABAFO.
Essa eu não aprendi apanhando. Aprendi vendo outras pessoas apanharem.
Vi gente sair de empresa boa, com chefe bom, queimando tudo. Mandar mensagem grosseira, sumir sem dar transição, deixar projeto pendurado, contar pra colegas que o gestor era ruim. Saída como desabafo. Como vingança da raiva acumulada nos últimos meses.
O problema é que o mundo é menor do que parece. Aquele gestor "ruim" que você queimou, daqui 3 anos, está sendo consultado sobre você pra uma vaga sênior. Aquele colega que você abandonou no projeto inacabado, está numa empresa onde você quer entrar. A indústria tem memória.
Pedir demissão é uma decisão pessoal, e sair de uma empresa que não te serve mais é saudável. A questão nunca é se você deve sair. É como você sai.
A regra que aprendi, vendo erro alheio, é que demissão é estratégia, não desabafo. Estratégia significa três coisas: você cuida do tempo de transição com seriedade, você protege o trabalho que está deixando, e você sai com a relação intacta com quem importa.
Cuidar do tempo de transição é o básico. Aviso prévio respeitado. Documento o que precisa ser documentado. Treino quem vai pegar o que era meu, ou pelo menos preparo o terreno. Não saio na segunda-feira sem fechar a sexta-feira anterior.
Proteger o trabalho é resistir à tentação de deixar tudo "do jeito que é problema do próximo". Não. O trabalho que eu fiz me representa, mesmo depois que eu sair. Se eu deixo um lixo organizado pra próxima pessoa, isso fica registrado como "o que o Fulano fez". Eu prefiro deixar limpo.
Sair com a relação intacta é o mais subestimado de todos. Conversa de saída tem que ser conversa, não comunicado. Honesta sobre o motivo, mas profissional no tom. Agradecer o que foi bom, sem inventar nem omitir. Oferecer continuar disponível por um tempo pra dúvidas. E principalmente: não falar mal nem pra colegas próximos. Aquela mensagem pro grupo do trabalho, no ímpeto, vai te assombrar.
A melhor forma de pensar nisso é simples: você tá saindo, mas a sua reputação continua. Cuida dela com o mesmo carinho que cuidou do código.
————————————————————————————————————————
O QUE TODAS TÊM EM COMUM.
Você olha as cinco conversas juntas e percebe uma coisa: elas são todas conversas que dão pra evitar. A maioria dos devs evita. E é exatamente aí que a carreira trava.
Aceitar um prazo impossível é evitar a conversa. Trabalhar 14 horas por dia esperando reconhecimento é evitar a conversa. Calar sobre um problema técnico que você viu é evitar a conversa. Esconder o atraso até a última hora é evitar a conversa. Sair sem se posicionar é evitar a conversa.
O que eu queria ter entendido cedo, e que tô tentando passar aqui pra te poupar uns anos de cabeçada, é que evitar conversa difícil é a forma mais lenta de matar uma carreira. Você não percebe acontecendo. Vai um ano, dois, três, e um dia você olha pra trás e percebe que está no mesmo lugar, ganhando quase a mesma coisa, frustrado com as mesmas situações.
A boa notícia é que dá pra mudar. Cada uma dessas conversas é um músculo. Você não precisa fazer todas perfeitamente amanhã. Precisa começar a fazer. Da primeira vez vai sair tremido. Da segunda menos. Da quinta você vai estar fazendo sem perceber.
A pergunta que importa não é "sou bom de código?". Quase todo dev que chegou em você é bom de código.
A pergunta é:
» Você tem coragem de ter as conversas que sua carreira pede?
————————————————————————————————————————
Se você chegou até aqui, manda esse texto pra um dev que precisa ler. Talvez seja o melhor presente que você pode dar pra alguém que está numa dessas cinco situações agora, sem saber.
A maior parte do que define uma carreira de tech não está no editor. Está nas conversas em volta dele.
E essas, ninguém te ensina na faculdade.
Está gostando dos nossos conteúdos, faça parte da comunidade Super Patos, não tem custo e vai te ajudar a evoluir na carreira, muita mais do que você pensa.