O engenheiro que simplesmente diz “não” era um fenômeno da ZIRP
(seangoedecke.com)- O engenheiro que simplesmente diz “não” é um arquétipo sênior cujo papel é, em essência, bloquear mudanças no código, atrasar funcionalidades complexas e fazer com que se escreva o mínimo possível de código
- No período da ZIRP, graças aos juros baixos e à expansão das contratações, a perda de produtividade importava menos, e barrar propostas técnicas radicais era útil para as empresas
- Após a alta dos juros, empresas de tecnologia demitiram 5% a 20% dos engenheiros e passaram a priorizar receita em vez de preço das ações, reduzindo a proteção que sustentava o “não pode”
- Os LLMs aumentaram a pressão com PRs gerados por IA e código suficientemente utilizável, mas a mudança central não é a IA, e sim os incentivos econômicos alterados pelo fim da ZIRP
- Esse papel não vai desaparecer, mas se encaixa melhor em áreas de engenharia pura e precisa aceitar um escopo mais limitado e menor visibilidade do que nos anos 2010
O papel do “engenheiro que simplesmente diz não”
- O engenheiro que simplesmente diz “não” é um arquétipo situado entre engenheiros sênior e staff, mais próximo de um papel que atrasa o desenvolvimento de funcionalidades, bloqueia mudanças que aumentam a complexidade e faz com que se escreva o mínimo possível de código
- No lado oposto, o engenheiro que simplesmente diz “sim” prioriza velocidade, aprova mudanças no código por padrão, valoriza mais o MTTR do que o MTBF e tende a colocar muito código em produção
- A maioria dos engenheiros fica entre esses dois extremos, mas o foco aqui está nos que se identificam fortemente com o papel de dizer “não”
- Na era da IA, é preciso rejeitar em massa não só PRs de engenheiros juniores, mas também código gerado por IA, e às vezes há situações em que o código foi feito por um gerente ou VP, o que torna a rejeição politicamente difícil
- Pela primeira vez na carreira, há forte pressão para baixar o padrão e dizer “sim”, mas a causa principal está menos na IA em si e mais no fim da ZIRP
O ambiente criado pela ZIRP
- ZIRP significa “política de juros zero” e se refere à era do desenvolvimento de software entre 2008 e 2022, quando bancos emprestavam dinheiro a empresas com juros próximos de zero
- Investidores colocavam esse dinheiro emprestado em quase qualquer coisa, e empresas de tecnologia tinham forte incentivo para continuar contratando engenheiros para projetos de baixo risco e alta recompensa esperada
- Empresas bem-sucedidas ampliaram seus quadros de algumas dezenas para milhares de engenheiros e os colocaram em projetos como open source periférico, migrações técnicas sem fim e reescritas em outras linguagens
- Foi um período em que engenheiros de software tinham grande poder de barganha e podiam receber alta remuneração praticamente independentemente do tipo de trabalho
- A liderança via equipes crescendo rápido demais para acompanhar os detalhes, e como o simples aumento do número de engenheiros ajudava o preço das ações, muitas atividades não eram tratadas como grandes problemas
- Se engenheiros demais se movessem livremente, os sistemas poderiam se tornar impossíveis de administrar, e foi aí que o “engenheiro que simplesmente diz não” se tornou útil para as empresas
Por que dizer “não” tinha valor na era da ZIRP
- Como a perda de produtividade não era um grande problema, as empresas conseguiam tolerar um ciclo em que metade dos engenheiros propunha mudanças e era rejeitada
- Esse modo de operar também tinha o efeito de impedir que engenheiros impactassem sistemas centrais do negócio
- Também ajudava a controlar os 5% dos engenheiros que, embriagados pela liberdade técnica, faziam propostas radicais como migrar para um banco de dados artesanal
- A reputação de ser uma empresa com padrões técnicos muito altos ajudava nas contratações, e na era da ZIRP todas as empresas de tecnologia estavam sempre contratando
- A frase “júnior cria muito código, sênior cria pouco, staff remove código” é atraente por sugerir que especialistas quase não precisam se mover, mas não corresponde à realidade: engenheiros staff também precisam ser capazes de produzir rapidamente muito código funcional quando necessário
As mudanças após o fim da ZIRP
- Quando os bancos elevaram os juros, quase todas as empresas de tecnologia demitiram imediatamente 5% a 20% dos engenheiros
- Manter organizações de engenharia inchadas para sustentar o preço das ações deixou de ser rentável, e as empresas passaram a precisar ganhar dinheiro de fato
- Aqui, “ganhar dinheiro” não significa necessariamente ter lucro, mas pelo menos gerar receita
- Admitir publicamente que centenas de engenheiros estavam ocupados com trabalho sem retorno não era uma boa explicação para as demissões
- Como o fim da ZIRP coincidiu aproximadamente com a ascensão do ChatGPT, as empresas puderam explicar as demissões como resultado do poder da IA
- A mensagem de que “graças a essa tecnologia transformadora, podemos entregar 10 vezes mais valor com metade dos engenheiros” soa forte, mas, se fosse realmente verdade, surgiria a pergunta de por que não manter os engenheiros e entregar 20 vezes mais valor
Empresas mais focadas e proteção reduzida
- As empresas de tecnologia estão mais focadas do que em qualquer outro momento dos últimos 20 anos e agora perseguem desesperadamente novas capacidades e funcionalidades que possam gerar dinheiro, em vez de fazer muitas coisas aleatórias
- Esse novo ambiente é ativamente desfavorável ao engenheiro que simplesmente diz “não”
- Antes, esse tipo de engenheiro tinha apoio implícito da liderança, e mesmo que alguém reclamasse, a resposta podia ser algo como: “sabemos o que esse engenheiro faz; se ele disse não, confiamos nisso”
- Agora esse apoio desapareceu, e o mesmo comportamento vem sendo criticado pela liderança ou ativamente revertido
- Passa a haver cobranças para ser mais colaborativo, encontrar formas de dizer sim ou até deixar de ser consultado em decisões importantes
- Comportamentos que eram recompensados antes de 2022 agora levam a avaliações ruins, e mudanças culturais podem seguir com alguns anos de atraso após mudanças nos incentivos econômicos
- Essa mudança não depende da IA: mesmo que os LLMs não tivessem surgido nesta década, as empresas ainda assim teriam demitido engenheiros, e os responsáveis pelo “não” continuariam confusos sobre por que o mesmo comportamento passou a ser punido
O impacto adicional da IA
- Se a ZIRP não tivesse acabado, os LLMs poderiam ter dado um forte argumento a favor do “engenheiro que simplesmente diz não”
- Empresas que não pudessem desconfiar abertamente ou internamente da programação assistida por IA teriam dependido muito desses engenheiros para impedir que um tsunami de código de IA atingisse a empresa
- Na prática, os LLMs estão acrescentando insulto à ferida já existente
- Agora é preciso assistir à fusão de PRs gerados por IA que antes teriam sido bloqueados, além de receber exigências para usar essas ferramentas também
- O pior é que, em geral, as ferramentas de IA funcionam
- Elas ainda não parecem estar causando nenhum tipo de desastre, e embora o código seja um pouco menos limpo e um pouco menos compreendido, ele é suficientemente utilizável
- Isso vale especialmente em empresas que tentam muitas coisas novas e descartam o que falha, onde código “bom o suficiente” funciona
- Mesmo que alguém veja aumento recente de incidentes, pode estar enganado, ou outros fatores do fim da ZIRP — como aumento de velocidade e demissões — podem ser causas mais importantes
- O engenheiro que simplesmente diz “não” enfrenta não só uma ameaça ao sustento, mas também à própria identidade
- Ele passa a ter de aceitar que seu papel técnico dependia de um ambiente econômico muito específico da indústria de tecnologia, ou continuar afirmando que o fim está logo ali
Engenharia pura e engenharia impura
- O “engenheiro que simplesmente diz não” não vai desaparecer, mas já não se encaixa tão bem em todas as empresas de tecnologia
- Em Pure and impure software engineering, a engenharia pura é definida como um trabalho de escopo bem delimitado e objetivos principalmente técnicos, como compiladores ou runtimes de linguagem
- A engenharia impura é um trabalho com escopo pouco claro e objetivos guiados pelo cliente, como tentar criar novas funcionalidades cujo sucesso é incerto
- Na era da ZIRP, empresas de tecnologia faziam muito mais trabalho puro, como React), e havia uma tendência de tratar até trabalho impuro como se fosse puro
- O “engenheiro que simplesmente diz não” se encaixa muito bem em trabalho puro
- Isso porque codebases puras exigem padrões de qualidade muito mais altos e conseguem tolerar ciclos de desenvolvimento mais lentos
- A maioria das empresas de tecnologia ainda faz algum tipo de trabalho puro em áreas como infraestrutura central
- Esse trabalho é essencial, mas não exige equipes gigantes de engenharia, e raramente recebe os holofotes
- Se alguém quiser continuar sendo um “engenheiro que simplesmente diz não”, deve migrar para esse tipo de função, aceitando um escopo mais limitado do que nos anos 2010
Debate e pontos de vista complementares
- Em lobste.rs e no Reddit, houve críticas de que é cedo demais para afirmar que código de IA “em geral funciona”, porque seus efeitos só aparecerão com o tempo
- A objeção de que “ainda é cedo para dizer” é difícil de refutar, mas parece claro que o código de IA não é imediatamente catastrófico
- Também houve o contra-argumento de que o arquétipo do “engenheiro que simplesmente diz não” já existia nas décadas anteriores à ZIRP, com Linus Torvalds citado como exemplo
- A ideia aqui não é que esse arquétipo tenha sido criado pela ZIRP, mas que a ZIRP ampliou artificialmente o nicho desse papel, que agora voltou a encolher
- Houve ainda o argumento de que o uso de linguagens dinâmicas e ferramentas imaturas de observabilidade e feature flags criou o nicho desse papel
- No Hacker News, várias pessoas defenderam que essa teoria precisa de evidências mais sólidas
- Essa visão se baseia em uma pequena janela de experiência pessoal, e generalizações sobre como era a indústria antes e depois da ZIRP podem variar de pessoa para pessoa
- Para testar isso, seria possível pesquisar centenas de engenheiros sênior ou acima em 2010 e em 2026, perguntando quantas vezes por semana disseram “não” e com que frequência essas recusas foram revertidas
- Dizer “não” continua sendo essencial antes e depois da ZIRP, mas após a ZIRP a diferença é que a liderança passou a desenvolver rapidamente essa capacidade por conta própria, reduzindo a necessidade de um grupo de engenheiros que dissesse isso em seu lugar
1 comentários
Comentários do Hacker News
Código é dívida. Quando um engenheiro diz “não”, não é por uma fixação subjetiva com a qualidade do código, mas por querer reduzir a complexidade
Hoje em dia, a gestão muitas vezes entende mal a palavra “qualidade”. Qualidade significa a quantidade adequada de esforço para construir o produto o mais rápido possível e com o menor custo possível, levando em conta também que a equipe de engenharia consiga adicionar e modificar código com facilidade
Há uma explicação melhor aqui: https://www.nair.sh/guides-and-opinions/communicating-your-e...
Qualquer tentativa de transformar em regras rígidas o que essa pessoa fez e por quê está fadada ao fracasso
O problema desse tipo de economia de mesa de bar é que dá para construir argumento para os dois lados
Também daria para chamar isso de “o fim da era de juros zero e a ascensão do engenheiro que só diz não”. Como o custo do capital ficou mais caro, a empresa precisa gastar esse dinheiro com mais sabedoria, e passa a precisar mais do julgamento de engenheiros que dizem não para não desperdiçá-lo com coisas desnecessárias
Quanto mais eu lia, mais pensava: “tem todos os termos que soam bem, fala de era ZIRP e de engenheiro que só diz não, parece ter insight, mas quando você aprofunda, não bate em nada com a minha experiência na engenharia de software daquela época, nem diagnostica direito a enorme transformação acontecendo agora com IA”. Ou seja, soou como baboseira de buzzword, e fico feliz que a comunidade tenha apontado isso, já que não existe botão de downvote no texto em si
Mesmo que projetos de IA fracassem, tudo bem desde que fracassem rápido o suficiente para permitir partir para outra coisa. Fazer certo desde o começo só volta a importar em projetos de longo prazo com investimento inicial alto
Dizer que “estava tudo perfeitamente bem mesmo que metade dos engenheiros da empresa estivesse presa num loop interminável de propor mudanças e ser rejeitada. Afinal, não precisava ser produtiva, e desse jeito não afetava os sistemas centrais do negócio” é, bem, uma visão possível. Bastante cínica
Em retrospecto isso soa cínico, mas na época as pessoas explicavam o mesmo conjunto de fatos de outras maneiras que machucavam menos os sentimentos de todo mundo
Só depois fica claro se a pessoa no Facebook trabalhando no Metaverse era alguém essencial prototipando um novo modelo de negócio, ou só estava fazendo trabalho para parecer ocupada
É uma interpretação bem extrema. Se o ZIRP acabou e o foco aumentou, a conclusão natural não seria rejeitar mais, e não menos?
Para sustentar que o ZIRP criou todo tipo de trabalho falso, e até camadas para controlar esse trabalho falso, é preciso se contorcer bastante para forçar a tese
Gosto da distinção entre “engenheiro que só diz sim” e “engenheiro que só diz não”, e da visão de priorizar MTTR em vez de MTBF
Eu claramente sou mais do time do “só diz sim”, mas há a ressalva de que escolhas ruins de arquitetura podem ser extremamente dolorosas de corrigir depois, e funcionalidades são muito mais difíceis de consertar depois que já têm usuários do que antes do lançamento. Então também sou um pouco do time do “só diz não”, ou pelo menos do “vamos pensar um pouco antes”
O equilíbrio entre “só dizer sim” e “só dizer não” depende muito do projeto. Em finanças ou saúde, talvez seja melhor que o padrão seja “não”, mas numa ideia maluca de startup, é YOLO
Pedir tempo para arrumar a casa é, na prática, o mesmo que dizer não. A liderança de engenharia precisa ter essa autoridade e realmente usá-la. Se nunca usa, na prática é como se não a tivesse
Você não pode virar um engenheiro que só diz “não” sem oferecer alternativa. Isso não é ser um bom engenheiro; é ser preguiçoso tentando parecer competente
Muitas vezes engenheiros apresentam soluções necessárias, ainda que não ideais, por causa do legado. E não, não dá para reescrever o sistema inteiro e fazer “do jeito certo”. Só dizer “não” ou apontar que a solução não é ideal não faz de ninguém um gênio superinteligente
Nas reuniões com o pessoal de negócio, era intimidador por saber programar, e o pior era que, quando discordava de uma proposta, não apresentava alternativa nenhuma. Era difícil trabalhar com ele
Fiquei pensando se a pessoa ZIRP de que este texto fala seria esse cara
Se LLMs e agentes têm limitações, existe uma corrente vendendo a ideia de que, em vez de esperar melhorias, deveríamos baixar o padrão. Algo na linha de “foque no MTTR”
O código está ruim? Não leia, não revise, tire da rodada a pessoa que é o gargalo. Esse tipo de narrativa está se espalhando por todo lado
Como essa tecnologia é bastante útil, eu gostaria que, em vez de só tratar os sintomas, houvesse mais foco em como trabalhar melhor com as ferramentas e em melhorar os processos de acordo com isso
Não faltam coisas que podem ser feitas, mas a questão é como dividir o tempo entre usar isso em projetos reais e investir nessas melhorias
Dizem que “quanto mais engenheiros, melhor para a ação… quando os bancos elevaram os juros… manter uma organização de engenharia inchada para inflar a ação deixou de ser lucrativo”, mas existe algum mecanismo conhecido que ligue número de engenheiros de software e preço da ação? Ou isso é só um fenômeno observado empiricamente?
“Antes bastava dizer não a um PR escrito manualmente por um engenheiro júnior, mas agora está vindo uma enxurrada de código gerado por IA, e parte dele foi feita por gerentes e VPs cuja rejeição é politicamente difícil”, meu Deus
Trabalhei em big tech, mas saí do setor antes de surgirem o InstructGPT e afins, então nunca vivi geração de código por LLM internamente. Isso está mesmo acontecendo? Gerentes seniores e VPs estão propondo mudanças de código feitas com LLM? Acho que eu não aguentaria
O peso político também é real. Você não pode simplesmente dizer “não pode”, mas é bem difícil revisar de forma significativa um PR de 25 mil linhas enviado por alguém que mal sabe o que está fazendo e nem consegue responder às perguntas
Para ser justo, ele construiu pessoalmente o liquid e boa parte da Shopify no começo da empresa, então não é alguém sem experiência, mas ainda assim
Parece uma hipótese difícil de verificar. Se uma empresa está tentando construir algo, não faz todo sentido ter alguém que ajude a definir prioridades mostrando quais decisões geram custos de longo prazo?