Pergunte a um engenheiro o que ele fez essa semana e muito pouco da resposta vai ser digitar lógica nova em um arquivo vazio.
Para onde o tempo realmente vai
A imagem pública do cargo é composição. A realidade se parece mais com arqueologia, negociação e reparo.
Ler código existente para entender o que faz. Reproduzir uma falha relatada. Revisar a mudança de outra pessoa. Integrar com um sistema cuja documentação está desatualizada. Esperar um build. Discutir uma abordagem. Fazer deploy. Investigar por que o deploy se comportou diferente do ambiente de teste. Consertar algo que funcionou por dois anos e parou.
Escrever código novo de fato é uma parte genuína do trabalho, e não é a maior parte, e raramente é a parte que determina se o projeto tem sucesso.
A restrição na maioria das equipes de software é compreensão e coordenação, não velocidade de digitação.
Isso tem uma implicação direta para o treinamento. Um programa de desenvolvimento focado inteiramente em linguagens e frameworks está treinando para a metade menor do trabalho. As habilidades que decidem o resultado, ler sistemas desconhecidos, revisar bem, projetar pensando em mudança, comunicar uma decisão técnica, são ensináveis e costumam ficar por conta da absorção espontânea.
O que a trilha cobre
O escopo: arquitetura, código, testes, interfaces de programação de aplicações, controle de versão, implantação e trabalho em equipe.
Quatro áreas.
Construção. Linguagens, design, interfaces e o ofício de escrever código que outras pessoas conseguem mudar.
Verificação. Testes em todos os níveis, revisão, e a disciplina de saber o que de fato foi verificado.
Entrega. Controle de versão, integração contínua, implantação e prática de lançamento.
Colaboração. Trabalhar em equipe em um sistema compartilhado, onde de fato mora a maior parte da dificuldade em software comercial.
O maior aumento de vagas de toda a tabela
Vale a pena declarar com precisão, porque a conversa pública sobre essa ocupação ficou confusa.
O US Bureau of Labor Statistics projeta que o emprego de desenvolvedores de software cresça 15,8% entre 2024 e 2034, um aumento de 267.700 vagas. No mesmo conjunto de projeções, esse é o maior aumento absoluto entre as ocupações de tecnologia acompanhadas, maior em números absolutos do que cientistas de dados e analistas de segurança da informação somados, mesmo que os dois cresçam em taxas percentuais maiores. O emprego total em todas as ocupações tem projeção de crescer 3,1% no mesmo período.
Duas ressalvas pertencem imediatamente ao lado desse número, e deixá-las de fora seria desonesto.
É uma projeção. Projeções são modelos construídos sobre suposições de adoção de tecnologia e crescimento setorial, e são revisadas. Esta incorpora uma suposição de que a inteligência artificial vai aumentar a produtividade, motivo pelo qual a mesma tabela mostra várias ocupações administrativas em declínio.
A contratação de nível iniciante tem sido difícil. Recém-formados e pessoas em transição de carreira enfrentaram um mercado mais apertado do que o número de crescimento geral sugere, e um crescimento agregado de dez anos não diz nada sobre quão fácil é conseguir um primeiro emprego em um determinado ano.
A conciliação é que boa parte das vagas projetadas vem de reposição, não de expansão, e que a demanda pende para quem consegue trabalhar com sistemas já existentes. Isso é uma afirmação sobre qual treinamento compensa, não um argumento de que o crescimento é fictício.
Revisão é a habilidade que escala uma equipe
A habilidade ensinável de maior alavancagem em engenharia de software, e uma das que quase nenhuma organização ensina de forma deliberada.
Revisão de código é onde defeitos são pegos antes de custarem qualquer coisa, onde o conhecimento se espalha pela equipe, onde padrões se tornam reais em vez de apenas documentados, e onde engenheiros juniores aprendem mais rápido. Também é onde muito tempo é desperdiçado e onde uma quantidade surpreendente de conflito no trabalho tem origem.
Quatro coisas que separam uma revisão útil de um ritual.
Saber o que procurar. Correção, tratamento de erros, segurança, comportamento em escala, e se isso vai ser compreensível daqui a um ano. Formatação é algo que uma ferramenta deveria tratar, e é nisso que revisores inexperientes gastam a atenção.
Revisar o design, não o diff. O comentário mais valioso costuma ser que a mudança não deveria existir nessa forma, e esse comentário é muito mais barato antes de o trabalho estar pronto.
Separar o que precisa mudar do que você teria feito diferente. Confundir preferência com exigência é a maior fonte de atrito em revisões, e ensina as pessoas a parar de perguntar.
Tornar isso seguro. Uma cultura de revisão em que as pessoas temem ser criticadas produz mudanças menores, mais tardias e menos honestas, e esconde problemas até ficarem caros.
Nada disso é difícil de ensinar. Simplesmente se presume que é aprendido por exposição, e as pessoas aprendem o que quer que sua primeira equipe fizesse.
Onde isso se encaixa no domínio
Engenharia de software é a segunda de oito trilhas no domínio de IA, dados e computação da Astra Trainer, e é a maior em número de pessoas em quase todas as organizações parceiras. Apoia-se em ciência da computação para o modelo de base e se conecta com computação em nuvem e DevOps, onde hoje mora a metade de entrega do trabalho.
Também se conecta com cibersegurança, já que boa parte das vulnerabilidades são defeitos comuns de software, e com inteligência artificial e machine learning, onde os sistemas ao redor de um modelo são engenharia de software convencional. Você pode ver as oito trilhas aqui.
Manutenção é o trabalho, não o pós-jogo
Software não está pronto quando é lançado. A maior parte do dinheiro gasto em um sistema ao longo de sua vida é gasta depois do primeiro lançamento, e a maioria dos engenheiros passa a maior parte da carreira trabalhando em código que já existe.
Ainda assim, quase toda a formação técnica usa exercícios do zero. As pessoas são ensinadas a construir algo novo, isoladamente, com requisitos limpos e sem histórico, e depois contratadas para um sistema com quinze anos de decisões acumuladas, migrações parciais e comentários descrevendo um comportamento que mudou há muito tempo.
As habilidades que essa lacuna exige são específicas e ensináveis.
Ler código desconhecido. Encontrar o ponto de entrada, rastrear um caminho, construir um modelo mental funcional sem ler tudo.
Mudar código com segurança. Adicionar testes a código não testado antes de modificá-lo, fazer mudanças pequenas e reversíveis, e usar tipos e contratos para limitar o efeito de uma edição.
Entender por que algo é do jeito que é. Boa parte do que parece irracional em código legado era uma resposta correta a uma restrição que não existe mais ou a um bug que já ninguém lembra. Apagar sem saber qual dos dois é como os apagões acontecem.
Gerenciar dívida técnica com honestidade. Distinguir decisões que foram trocas razoáveis de negligência acumulada, e tornar o custo de cada uma visível para quem decide prioridades.
Migrar de forma incremental. Quase toda grande reescrita tentada como uma substituição única é uma história de cautela. Migração incremental é uma habilidade com padrões conhecidos e raramente é ensinada.
As funções, nomeadas
Engenheiros de software, em front end, back end e full stack.
Engenheiros de plataforma, construindo as ferramentas internas das quais outras equipes dependem.
Engenheiros mobile.
Engenheiros de qualidade e teste, incluindo automação.
Engenheiros de confiabilidade de site, onde engenharia de software encontra operações.
Arquitetos técnicos.
Gerentes de engenharia e líderes técnicos, onde a restrição costuma ser julgamento, não capacidade de programar.
Engenheiros de developer experience, uma especialidade em crescimento voltada para o gargalo de compreensão e coordenação.
Engenheiros de integração, conectando sistemas que não foram projetados para se encontrar.
Quem pode ser treinado para isso
Analistas de qualidade e engenheiros de teste. A conversão interna mais forte. Já conhecem o produto, sabem como ele falha e conhecem a base de código de fora.
Engenheiros de suporte e operações. Para desenvolvimento, trazendo conhecimento de produção que as equipes de desenvolvimento não têm e com frequência precisam.
Analistas de dados. Já escrevendo código, precisando de prática de engenharia: controle de versão, testes, revisão e design pensando em mudança.
Analistas de negócio e equipe de produto com inclinação técnica, para funções adjacentes à engenharia onde o entendimento de domínio é a metade escassa.
Engenheiros de outras disciplinas. Engenheiros mecânicos, elétricos e civis convertem bem, trazendo método sistemático.
Cientistas e pesquisadores que já escrevem código para o próprio trabalho, precisando de prática colaborativa, não de programação.
Desenvolvedores experientes em tecnologias envelhecidas. Frequentemente esquecidos, com conhecimento profundo de sistemas e precisando de um conjunto de ferramentas atual, não de uma mudança de carreira.
Sobre código gerado e responsabilidade. Código produzido por ferramentas de geração é responsabilidade da organização que o lança, e pode carregar defeitos, vulnerabilidades de segurança, implicações de licenciamento ou comportamento que ninguém na equipe consegue explicar. As obrigações de revisão, teste e proveniência não se transferem para a ferramenta. Setores com software regulamentado, incluindo sistemas médicos, automotivos, de aviação e financeiros, têm requisitos específicos de processo de desenvolvimento e rastreabilidade que se aplicam independentemente de como o código foi produzido.
O que levar disso
Produzir código novo é a menor parte do trabalho, e treinamento que cobre só linguagens e frameworks trata da metade menor.
Desenvolvedores de software têm projeção de somar 267.700 vagas até 2034, o maior aumento absoluto entre as ocupações de tecnologia acompanhadas pelo BLS, e isso é uma projeção que convive com um mercado de nível iniciante genuinamente difícil.
Revisão de código é a habilidade ensinável de maior alavancagem em uma equipe e quase universalmente é deixada por conta da absorção espontânea.
Manutenção e trabalho em código legado é onde as carreiras de fato se passam, e a formação treina de forma esmagadora para projetos do zero.
E os melhores candidatos internos costumam estar em teste, suporte e operações, já com o conhecimento que novas contratações levam um ano para adquirir.
No que os engenheiros de software realmente gastam o tempo?
Ler código existente, reproduzir falhas, revisar mudanças, integrar com sistemas cuja documentação está desatualizada, fazer deploy e investigar diferenças entre ambientes. Escrever código novo é real, mas não é a maior parte.
O desenvolvimento de software ainda está crescendo como ocupação?
O BLS projeta 15,8% de crescimento de 2024 a 2034, um aumento de 267.700 vagas, o maior aumento absoluto entre as ocupações de tecnologia que acompanha. Isso é uma projeção, não uma observação, e convive com um mercado de contratação de nível iniciante difícil.
Por que a revisão de código importa tanto?
Porque pega defeitos antes de custarem qualquer coisa, espalha conhecimento pela equipe, torna os padrões reais e ensina engenheiros juniores mais rápido do que qualquer outra coisa. Também é onde mais atrito técnico se origina quando feita mal.
Por que o trabalho com código legado é pouco treinado?
Porque a formação técnica usa exercícios do zero com requisitos limpos, enquanto a maioria dos engenheiros passa a maior parte da carreira mudando sistemas com anos de história acumulada, migrações parciais e motivos não documentados.
Quem converte bem para engenharia de software?
Engenheiros de teste e qualidade primeiro, depois equipe de suporte e operações, analistas de dados que já escrevem código, engenheiros de outras disciplinas, e desenvolvedores experientes em tecnologias envelhecidas que precisam de um conjunto de ferramentas atual, não de uma mudança de carreira.