Carreira
7 Erros que Matam a Carreira na prática
Os 7 erros que mais travam devs — desde só aprender frameworks sem fundamentos até não construir network. Com o antídoto para cada um.
CrazyStack
Carregando
Os 7 erros que mais travam devs — desde só aprender frameworks sem fundamentos até não construir network. Com o antídoto para cada um.
7 Erros que Matam a Carreira na prática. Os 7 erros que mais travam devs — desde só aprender frameworks sem fundamentos até não construir network. Com o antídoto para cada um.
Esse é o erro número um — e o mais perigoso porque parece progresso. Dev que aprende React, depois Next.js, depois Remix, depois Astro, depois o framework que saiu semana passada está sempre ocupado aprendendo coisas novas. Mas na entrevista técnica, quando perguntam como closure funciona em JavaScript ou o que acontece quando você faz uma requisição HTTP, trava.
Framework vem e vai. Fundamentos ficam. O dev que entende como JavaScript realmente funciona — event loop, prototype chain, escopo, closures — aprende qualquer framework novo em dias. O dev que só aprendeu o framework leva semanas para cada novo e nunca entende por que as coisas se comportam de jeito estranho.
O antídoto: reserve tempo explícito para estudar o que está embaixo das abstrações que você usa. Leia a documentação de JavaScript ou TypeScript, não só do React. Entenda como HTTP funciona de verdade — não só que ele existe. Entenda por que banco relacional difere de banco de documentos e quando usar cada um. Esses investimentos parecem lentos no começo — e rendem para sempre depois.
Tem um artigo que aborda isso pelo lado das entrevistas técnicas: algoritmos-para-entrevistas, que mostra como fundamentos aparecem nos processos seletivos e por que quem os domina leva vantagem clara.
Projeto pessoal não é portfólio. Portfólio é consequência. Projeto pessoal é onde você aprende de verdade — porque ninguém está te dizendo o que fazer, você decide a arquitetura, escolhe as ferramentas, enfrenta os problemas reais e carrega o resultado.
Dev sem projeto pessoal depende 100% do emprego para aprender. E emprego otimiza para entrega, não para aprendizado. Você vai fazer o que a empresa precisa — que pode ser manter código legado, repetir o mesmo tipo de task ou trabalhar em stack que não te interessa. Projeto pessoal é onde você aprende o que o mercado vai pedir daqui a 2 anos, não o que o emprego atual precisa hoje.
O antídoto: um projeto simples que resolve um problema real para você. Não precisa ser grande. Não precisa ter usuário ainda. Mas precisa ser algo que te faça tomar decisões — de arquitetura, de produto, de UX — e não só escrever código seguindo um tutorial. O processo de decidir, errar e corrigir é onde o aprendizado real acontece.
Como conseguir trabalho remoto para empresas de fora.
Programador que acredita que só código importa vai travar no nível pleno. Ponto final. O mercado está cheio de devs tecnicamente bons que nunca crescem porque não sabem comunicar o que fazem, não conseguem dar feedback sem criar conflito, não sabem conduzir uma conversa com stakeholder não-técnico ou não conseguem liderar nem uma decisão técnica simples.
Soft skills não é eufemismo para 'ser gente boa'. É a capacidade de multiplicar o impacto técnico que você tem. Um dev técnico mediano com comunicação excelente e capacidade de influenciar o time entrega mais valor do que um dev brilhante que só fala com o computador. Isso é fato de mercado, não opinião.
Galera, as soft skills mais relevantes para dev em 2026: comunicação escrita assíncrona (porque trabalho remoto exige), capacidade de dar e receber feedback técnico construtivo, facilidade para explicar contexto e trade-offs para não-técnicos, e ownership — a disposição de ser responsável pelo resultado, não só pela tarefa. Essas quatro mudadas fazem mais diferença na carreira do que qualquer framework novo.
O antídoto: trate soft skills como habilidade técnica — algo que você pode aprender e praticar. Leia sobre comunicação não-violenta, sobre como dar feedback, sobre facilitação de reuniões. Peça para fazer apresentações internas. Escreva documentação. Cada uma dessas práticas é repetição de skill que vai compor ao longo do tempo.
Esse é um equilíbrio difícil — e a maioria erra para um dos dois lados.
Trocar cedo demais: Dev que fica menos de 1 ano em cada emprego perde o período mais valioso de aprendizado — que não é o começo, é os meses 6-18, quando você já conhece o sistema mas ainda está descobrindo suas nuances e problemas não óbvios. E mais: histórico de trocas rápidas levanta bandeira vermelha para recrutador. 'Esse candidato vai embora em 6 meses?' é a primeira pergunta que aparece.
Trocar tarde demais: Ficar 4-5 anos na mesma empresa sem promoção ou crescimento significativo de responsabilidade é estagnação disfarçada de lealdade. O mercado paga bem por lealdade — através de reajuste e crescimento. Se a empresa não está fazendo isso, ela está te dizendo que seu crescimento não é prioridade para ela. Ouvir esse sinal cedo e agir é inteligente, não desleal.
O antídoto: a regra dos 2 anos. Em dois anos em qualquer emprego, faça uma avaliação honesta: você cresceu? Suas responsabilidades aumentaram? Seu salário acompanhou o mercado? Se a resposta para duas dessas três perguntas é não, está na hora de conversa direta com liderança — e se não resolver, está na hora de olhar para fora.
Dado de mercado: a maioria dos devs que aceitou a primeira oferta sem negociar deixou entre R$ 500 e R$ 2.000 por mês na mesa. Multiplicado por 12 meses, por anos de carreira — é um valor enorme que você simplesmente desistiu sem lutar.
Dev não negocia por medo. Medo de parecer ganancioso, medo de a empresa desistir, medo de criar clima ruim antes de começar. Esses medos são compreensíveis — e quase nunca se concretizam. Empresa que vai desistir de um candidato porque ele fez contra-proposta razoável provavelmente não é empresa onde você quer trabalhar.
O antídoto: pesquise o mercado antes de qualquer conversa salarial. Use Glassdoor, grupos de devs, pesquisas de salário. Quando chegar a oferta, peça 24-48h para avaliar e volte com contra-proposta fundamentada em dados de mercado. 'Pesquisei vagas similares e o mercado paga X, então proponho Y' é argumento sólido. Não é ganância — é profissionalismo.
Tem dados reais de mercado no artigo quanto-ganha-desenvolvedor-junior-2026 que ajudam exatamente nessa pesquisa antes de negociar.
Conforto técnico é armadilha. Dev que ficou 4 anos fazendo só jQuery (tecnologia que não sumiu, mas encolheu muito) em 2020 foi pego de surpresa pelo mercado que já não pagava o mesmo por aquela habilidade. Isso acontece em ciclos — e o ciclo está cada vez mais rápido.
Atenção: isso não significa largar tudo e aprender a moda da semana. Stack generalista sólida vale mais do que dez stacks superficiais. O ponto é diferente: você precisa monitorar para onde o mercado está indo e adicionar ao repertório antes de ser obrigado a fazer isso com urgência.
Em 2026, stacks que ganham espaço e merecem atenção: qualquer coisa ligada a AI engineering (embeddings, RAG, orquestração de modelos), infraestrutura como código e Cloud nativa, e TypeScript como língua franca tanto no frontend quanto backend. Dev que tem essas habilidades no radar tem opções. Dev que ignorou está correndo atrás.
O antídoto: um projeto pessoal por ano em uma tecnologia fora da zona de conforto. Não precisa dominar — precisa entender o suficiente para avaliar se faz sentido para sua carreira e para projetos futuros. Esse investimento de algumas horas por semana ao longo de um ano cria um radar muito mais apurado do que ficar lendo posts sobre 'o futuro da tech'.
Network tem fama de coisa para extrovertido, para 'networking de evento corporativo', para gente que fica distribuindo cartão de visita. Nada a ver. Network de dev é diferente — e quem não tem perde oportunidades concretas.
A maioria das vagas boas não aparece em portal público. Circulam em comunidades fechadas, grupos de Telegram, DMs no LinkedIn, conversas entre amigos. Dev com boa rede recebe indicações antes da vaga ir para o mercado. Dev sem rede compete em mercado aberto com centenas de candidatos. A diferença de esforço para conseguir o mesmo emprego é enorme.
Network também é aprendizado. Conversar com devs de empresas diferentes, em stacks diferentes, em estágios de carreira diferentes — isso dá perspectiva que nenhum tutorial dá. Você aprende como outros times resolvem problemas, quais tecnologias estão usando, quais armadilhas enfrentaram. É informação de mercado que vai direto para suas decisões de carreira.
O antídoto: comece pequeno. Entre em uma ou duas comunidades de devs ativas (Discord, Telegram, Slack). Participe das conversas — não só como espectador. Quando aprender algo útil, compartilhe. Quando resolver um problema, documente e publique. Twitter/X, LinkedIn e GitHub são distribuição natural do que você aprende. Consistência ao longo de meses cria presença que vira oportunidade.
Sete erros parecem muita coisa para corrigir ao mesmo tempo. Não precisa ser tudo de uma vez — e tentar corrigir tudo ao mesmo tempo é garantia de não corrigir nada.
O sistema que funciona é simples: escolha um erro por trimestre. Três meses de foco em um problema específico é suficiente para criar mudança real de comportamento. Primeiro trimestre: fundamentos. Segundo: projeto pessoal. Terceiro: comunicação e network. Quarto: avaliar salário e posição no mercado. Em um ano você cobriu os quatro mais impactantes — e cria hábito de revisão que se sustenta no tempo.
A carreira de dev é longa. Quem monta esse sistema de revisão e melhoria contínua desde cedo chega em lugares que quem não monta sequer imagina que são possíveis. Não precisa ser rápido — precisa ser consistente. Dá pra ver exemplos reais dessa jornada no artigo /2025-3/a-historia-nao-contada-do-desa, que mostra o que acontece nos bastidores de uma carreira de dev de verdade.
Olha só: o melhor momento para corrigir esses erros foi no primeiro dia de carreira. O segundo melhor momento é hoje. Cada mês que passa com os erros ativos é custo real — em salário que não foi negociado, em promoção que não aconteceu, em oportunidade que foi para outra pessoa. A decisão de mudar é sua — e só depende de você.