Job descriptions pedindo cinco anos de experiência em versões de linguagem lançadas há menos de um ano aparecem com regularidade suficiente pra não surpreender ninguém. Pra mim o problema não está nos candidatos que ignoram o número, e sim na premissa de que anos de exposição funcionam como proxy confiável de competência. Essa premissa sustenta um fenômeno mais destrutivo: uma parcela significativa de engenheiros construiu sua identidade em torno de uma stack, se rotulando como dev Java, dev Python ou engenheira React. A exposição intensa a um ecossistema nos primeiros anos de carreira cria a ilusão de que dominar a ferramenta equivale a dominar o ofício, e o efeito colateral aparece quando a linguagem perde relevância ou quando uma oportunidade surge em outro ecossistema e o profissional sequer se candidata, até porque não se reconhece fora da stack.
Na minha análise, o mecanismo opera em múltiplas dimensões, e a mais imediata é cognitiva. Quando um engenheiro trabalha com uma única linguagem por cinco, sete anos, o modelo mental que ele constrói pra resolver problemas vai sendo moldado pelas abstrações dela. Um dev que passou a carreira em Java pensa em classes, interfaces, injeção de dependência e ciclo de vida de objetos gerenciados por GC, e esse modelo funciona em Java e em linguagens com as mesmas abstrações (C#, Kotlin), mas falha em outro paradigma quando ele não construiu vocabulário conceitual pra fazer a transição. O resultado é uma monocultura cognitiva travestida de especialização profunda. A dimensão social opera junto, até porque crítica à linguagem se confunde com crítica à identidade.
A dimensão econômica torna o mecanismo visível. O desenvolvedor COBOL dos anos 1990 era commodity. Em 2025 comanda entre 86 e 150 mil dólares anuais nos EUA, porque 43% dos sistemas bancários globais ainda rodam COBOL e o programador médio tem entre 55 e 58 anos. A inflação de salário não significa carreira saudável: o dev COBOL tem mobilidade próxima de zero, em um cenário de captura em que qualquer movimento lateral exige reconstrução do repertório.
O padrão inverso também ocorre. Python subiu de 49% pra 51% em adoção entre o Stack Overflow Developer Survey de 2023 e o de 2024, e ocupa a primeira posição entre desenvolvedores em formação (66%) por deslocamento impulsionado por IA e ciência de dados. Um engenheiro que construiu identidade em Python pra web, com Django ou Flask, olha pra esse número e sente validação. Na minha avaliação ele lê o gráfico errado: o mercado passou a querer Python pra ML pipelines, e a identidade genérica de dev Python mascara uma incompatibilidade real entre o que ele sabe fazer e o que o mercado paga.
O que de fato transfere entre ecossistemas são os fundamentos que a linguagem implementa, independentemente da sintaxe de superfície: estruturas de dados, modelos de concorrência, sistemas de tipos, gerenciamento de memória. Um engenheiro que entende como uma hash table funciona vai operar com dicionários em Python, HashMaps em Java, maps em Go e HashMaps em Rust com a mesma fluência conceitual. A capacidade de raciocinar sobre colisões, fatores de carga e complexidade amortizada não pertence a nenhuma linguagem, pertence ao engenheiro.
Já entrevistei centenas de engenheiros em 35 anos, e os melhores raramente eram os que tinham mais tempo na linguagem do time. Uma engenheira com background em Haskell entrou pra um time de Go e, na terceira semana, já escrevia Go idiomático. No terceiro mês tinha redesenhado o sistema de tipos de uma camada de domínio de forma que nenhum engenheiro com cinco anos de Go tinha articulado, até porque a exposição a várias implementações do mesmo conceito força a separação entre conceito e implementação.
O contra-argumento previsível é que especialização profunda tem valor, e tem. Quem conhece o GC sob pressão e sabe como o JIT otimiza hot paths resolve problemas que generalistas não conseguem. Pra mim a questão não é se especialização tem valor, mas se ela deve definir a identidade. Saber como a JVM funciona é uma competência. Definir-se como dev Java é uma limitação. Em liderança técnica a diferença é maior: a escolha de linguagem deveria ser função dos requisitos do sistema, e um líder que se identifica com a stack tende a escolhê-la por default mesmo quando os requisitos apontam pra outra direção, fazendo o time pagar em atrito operacional e limitações de performance evitáveis.
O mercado em 2025 opera com uma contradição. O skills-based hiring ganha tração e empregadores avaliam portfólios em vez de anos em linguagem X, mas os filtros de ATS continuam operando por keyword matching, então um currículo sem a palavra Kotlin não passa pelo filtro da vaga que pede Kotlin. Profissionais que definem carreira por linguagem passam pelos filtros antigos e perdem nas avaliações novas, e os de repertório amplo passam nas avaliações novas mas são filtrados antes de chegar nelas.
A saída passa por construir profundidade em mais de uma dimensão. Um engenheiro de TypeScript pode investir em Rust pra entender ownership e lifetime sem GC, e o exercício não precisa virar produção, o valor está na expansão do modelo mental. A identidade profissional deveria estar ancorada em capacidades que não depreciam com ciclos de adoção. Quem construiu identidade sobre fundamentos transportáveis olha pra uma linguagem nova e vê sintaxe pra aprender em semanas. Quem construiu identidade sobre uma stack vê ameaça.
A diferença está no enquadramento, e enquadramento se muda por decisão.