Quando percebeste que seguir apenas a carreira técnica não tinha futuro?

Este artigo #BCGame @bcgame patrocínio exclusivo

Muitos jovens que acabam de entrar na área, incluindo eu na altura, acreditam numa ideia fixa: Desde que eu tenha uma técnica incrível, serei insubstituível.

Por isso, nos esforçamos ao máximo. Aprendemos Java, Go, Rust, analisamos código-fonte, estudamos algoritmos, trabalhamos com microserviços, exploramos cloud native. Hoje ainda estamos a mexer com Spring Cloud, amanhã temos que aprender Service Mesh, depois de amanhã, com o sucesso dos grandes modelos de IA, temos que correr para aprender Prompt Engineering.

Achamos que isso é progresso, mas na verdade é uma corrida sem fim.

Você pensa que está a construir uma barreira técnica, mas na realidade está a ajudar o seu chefe a validar a viabilidade de novas tecnologias.

Na indústria da internet, a depreciação tecnológica acontece mais rápido do que a queda de um imóvel comprado na planta. Você dedicou três anos ao seu framework, e de repente o Google ou o Facebook lança uma nova versão, ou muda a filosofia de arquitetura, e toda a sua técnica de mestre, que tanto se orgulhava, vira papel de embrulho.

Mas isso não quer dizer que aprender seja inútil, apenas que o seu foco pode estar errado. Em vez de perseguir frameworks que ficam obsoletos em três anos, é melhor focar na lógica fundamental que não muda em uma década. Por exemplo, enquanto você ainda está indeciso entre usar Spring Cloud ou K8s, os verdadeiros mestres pensam na consistência de dados em sistemas distribuídos. Se quer sair do ciclo de frameworks, recomendo que leia aquele que é considerado a bíblia do backend, o 《Design de Sistemas de Aplicações Orientadas a Dados》 (versão com leitura guiada do DDIA). Ele explica a essência de sistemas distribuídos, bancos de dados e design de sistemas. Entendendo isso, não importa qual framework esteja na moda amanhã, você vai enxergar além da superfície.

Lembra-se dos caras que trabalhavam com Flash? Ou dos experts que programavam para Symbian?

Eles não se esforçavam? Não eram inteligentes?

Quando a era passa, ela nem sequer diz adeus.

O mais assustador é que a nossa orgulho de aprender rápido, na verdade, é uma das características que o capital mais valoriza como recurso consumível.

Porque você aprende rápido, você é barato.

Antigamente, um médico tradicional mais velho valia mais, pois sua experiência não podia ser copiada. Agora? Um programador de 35 anos, que pede um salário alto, é considerado de baixo custo-benefício. Um recém-formado de 23 anos, com duas ou três manuais, consegue copiar e modificar código no Github e estar pronto em um mês.

E aí você pensa: Eu tenho experiência, posso evitar problemas.

Brincadeira. Na maioria das tarefas CRUD, não é preciso tanta profundidade técnica. E se o código estiver meio ruim? É só colocar mais dois servidores, não é? E se houver vazamento de memória? Reinicia o servidor de madrugada, resolve.

Para o chefe, o que importa é que funcione.

Seu código elegante, seus padrões de projeto, sua arquitetura, na visão do chefe, valem menos do que aquele puxa-saco que consegue beber com ele, fazer promessas grandiosas, e montar slides que brilham.

Isso é a lei do mercado: a moeda ruim expulsa a boa.

Quando você percebe que o engenheiro de PPT do lado, que fica o dia todo falando em empoderamento, pontos de ação, ciclos fechados, granularidade, sobe na carreira mais rápido do que você, é hora de acordar.

A maior tristeza do técnico é que estamos sempre longe do dinheiro.

Somos a força produtiva, mas não somos os principais na relação de produção.

Você criou um algoritmo de recomendação incrível, aumentou a retenção de usuários. Quem leva o mérito? É o marketing, o produto, até o time de vendas que negociou parcerias.

Por quê?

Porque, na lógica de negócios, a tecnologia é apenas uma ferramenta.

É como construir uma casa: você é aquele que levanta os tijolos. Por mais retas que sejam as paredes, por mais rápido que transporte os tijolos, quem realmente lucra com a venda do imóvel é o construtor, a corretora, até os especuladores, e você, que só levanta tijolos, fica de fora.

Além disso, a tecnologia costuma ser a culpada.

Se o sistema falha, você leva a culpa. Se o lançamento atrasar, você leva a culpa. Se há bugs, você leva a culpa.

Mas e se o negócio não decolar?

O gerente de produto dirá: Eu também quero que dê certo, mas a tecnologia não apoia, não dá para implementar essa funcionalidade, o cronograma é longo.

Vê? Um ciclo perfeito.