- Desenvolvedores sêniores e não desenvolvedores recebem a mesma frase — que agentes de IA vão substituir desenvolvedores — com critérios diferentes: estabilidade e aprendizado de mercado
- Organizações de negócios querem lançar rápido para obter feedback e reduzir a incerteza, enquanto desenvolvedores sêniores alertam para o aumento de complexidade que pode quebrar o sistema
- Depois que surgem clientes, dois ciclos passam a rodar ao mesmo tempo: exploração de mercado e continuidade do serviço; a principal responsabilidade do desenvolvedor sênior muda para a gestão da complexidade
- Persuadir não termina em dizer “complexidade é um problema”; isso só funciona quando se atende ao desejo de velocidade da outra parte com experimentos mais rápidos, como Google Forms ou botões em uma UI já existente
- A IA acelera o lançamento, mas pode prejudicar a capacidade de entender, modificar e depurar o sistema, e não assume responsabilidade; por isso, desenvolvedores sêniores podem separar Speed e Scale
Por que a mesma frase é ouvida com critérios diferentes
- Desenvolvedores sêniores e não desenvolvedores interpretam de forma diferente a mesma frase: “agentes de IA são o futuro do desenvolvimento de software e desenvolvedores deixarão de ser necessários”
- Em copywriting, a mensagem precisa ser adequada ao público; a mesma frase assume significados diferentes dependendo de quem a ouve
- A razão pela qual a intuição de desenvolvedores sêniores se afasta do otimismo com IA é que a definição do problema muda conforme o foco do trabalho esteja em aprendizado de mercado ou em estabilidade do serviço
O que desenvolvedores sêniores veem com cautela
- Entre desenvolvedores sêniores, há o tipo que tenta introduzir algo com base em novas ferramentas, práticas de outras empresas ou boas práticas vistas no Hacker News
- O tipo de sênior mais valorizado pergunta primeiro: “isso é realmente necessário?”, “o que acontece se não fizermos isso?” e “dá para segurar agora e revisar depois se isso se tornar mais importante?”
- Esse tipo tenta evitar desenvolvimento ao máximo, reduzir e reutilizar
- No desenvolvimento profissional de software, o que desenvolvedores sêniores mais vigiam é a complexidade
- Casos especiais, condicionais, novas tabelas no banco de dados e novos componentes adicionam complexidade ao sistema
- Quem é responsável por um sistema em produção acaba inevitavelmente temendo o aumento da complexidade
- Mesmo desenvolvedores sêniores muito bons em criar designs novos e criativos passam a ter cautela com a complexidade quando assumem um sistema em funcionamento
O que as organizações de negócios veem com cautela
- Marketers, vendedores, product managers e CEOs estão dentro de um ciclo em que colocam algo no mercado e recebem feedback para aprender se aquilo tem valor
- O objetivo desse ciclo é o aprendizado, e sua maior ameaça é a incerteza
- Como nenhuma estratégia vem com garantia de sucesso, a incerteza atua de forma dura
- Quando remuneração de marketing e vendas, salário do fundador e métricas do product manager se combinam com o tempo, parece que a única forma de reduzir a incerteza antes do prazo é colocar algo no mercado o mais rápido possível
- Quanto mais se coloca no mercado, mais feedback se obtém e, potencialmente, mais se reduz a incerteza
- Toda empresa começa nesse ciclo, que gira em torno de velocidade pura
O segundo ciclo depois que chegam os clientes
- Quando clientes começam a pagar, surge um segundo ciclo cujo objetivo é a continuidade e a garantia do serviço
- O sistema precisa continuar funcionando, ser compreensível, depurável, modificável, ensinável e estável
- Desenvolvedores sêniores valorizam a estabilidade porque recebem a responsabilidade de negócio de continuar atendendo os clientes
- O que ameaça tudo isso é, novamente, a complexidade
- A complexidade torna o sistema menos compreensível, menos depurável, menos modificável, mais difícil de ensinar e, no fim, menos estável
- Quando a complexidade sobe, a estabilidade cai; o desenvolvedor sênior deixa de cumprir sua responsabilidade e podem surgir problemas como interrupção de pagamentos
- Se o objetivo do primeiro ciclo é reduzir a incerteza, o objetivo do segundo é a gestão da complexidade
Onde a comunicação falha
- Depois que surgem clientes, os dois ciclos — exploração de mercado e continuidade do serviço — passam a rodar ao mesmo tempo
- A empresa precisa explorar possibilidades e, ao mesmo tempo, continuar prestando serviço aos clientes
- O mesmo problema parece diferente dependendo de qual ciclo recebe o tempo e a atenção
- A organização de negócios quer construir e lançar mais rápido para reduzir a incerteza
- Desenvolvedores sêniores, por sua vez, à medida que os pedidos aumentam, se preocupam com complexidade, custo de manutenção, compreensibilidade, velocidade contínua de desenvolvimento e produtividade ao longo do tempo
- Mas a linguagem da gestão da complexidade, sozinha, dificilmente resolve o desejo de redução da incerteza de outras áreas
- Para persuadir, é preciso apresentar a solução do desenvolvedor sênior também como solução para o problema da outra parte
- A comunicação falha quando o problema é descrito do ponto de vista da gestão da complexidade, mas a solução não é apresentada do ponto de vista da redução da incerteza
A força prática do desenvolvedor sênior
- A habilidade mais útil de um desenvolvedor sênior está em não construir o que é desnecessário e em encontrar oportunidades de reutilizar o que já foi feito
- Se é preciso coletar dados por formulário, pode-se usar Google Forms
- Em vez de criar toda uma nova funcionalidade para testar algo, é possível colocar um botão na UI existente e ver se as pessoas clicam
- Antes de adotar um novo serviço de analytics, pode-se perguntar primeiro qual é a decisão mais importante que exige análise e começar com uma decisão, um gráfico, uma métrica
- É como colocar uma vela num sanduíche em vez de assar um bolo de aniversário inteiro
- Desenvolvedores sêniores aprendem a usar software existente para entregar o que as pessoas querem
- Uma frase curta para transmitir isso é: “Can we try something quicker?”
- “quicker” reconhece a velocidade que a outra parte realmente quer
- “something” sugere que existe outra forma de alcançar o objetivo
- “try” carrega a possibilidade de algo imperfeito, mas bom o suficiente
- Essa frase reconhece a velocidade de redução de incerteza que a empresa quer, ao mesmo tempo que abre espaço para o desenvolvedor sênior exercer sua expertise de reduzir, reutilizar e, quando possível, evitar
A pressão que a IA muda e a responsabilidade que permanece
- Como a IA consegue criar muita coisa em pouco tempo, a postura de reduzir, reutilizar e evitar pode parecer sem sentido
- Mas a IA ainda não consegue fazer uma coisa que desenvolvedores sêniores fazem: assumir responsabilidade
- Desenvolvedores sêniores valorizam a compreensibilidade do sistema porque, quando surge um problema, precisam conseguir corrigi-lo
- A compreensibilidade também permite escalar o sistema com inteligência quando ele precisa crescer e continuar prestando serviço estável a clientes pagantes
- A IA aumenta muito a velocidade de colocar algo no mercado, mas também afeta o ciclo de estabilidade pelo qual o desenvolvedor sênior responde
- Quando agentes de IA, desenvolvedores juniores, não desenvolvedores, investidores e pessoas ao redor deles adicionam código ao sistema, o sistema passa a recompensar velocidade em excesso e sacrificar estabilidade
- A IA pode piorar a compreensibilidade, a modificabilidade, a depurabilidade, a capacidade de ensinar e a capacidade de garantir o comportamento do sistema
- A IA pode tornar o sistema instável, mas não assume a responsabilidade por isso
- Esse é o ponto central da preocupação do desenvolvedor sênior
O desenvolvedor sênior como editor, mais do que como autor
- Uma abordagem que desenvolvedores sêniores podem usar é o desacoplamento (decoupling)
- Durante muito tempo, apenas desenvolvedores de software podiam criar software, então eles respondiam ao mesmo tempo pelos dois ciclos: aprendizado de mercado e estabilidade do serviço
- Um único sistema sustentava os dois objetivos ao mesmo tempo
- Se cada objetivo tiver um sistema diferente, velocidade e estabilidade podem ser separadas
- É parecido com um romancista que termina rapidamente um primeiro rascunho e depois passa por um processo de edição para extrair o que funciona e descartar o que não funciona
- O trabalho do editor é pegar os fragmentos que funcionam bem e refiná-los até formar um todo coeso
- A versão Speed é um sistema voltado para velocidade, um espaço em que agentes de IA, código gerado sem revisão, desenvolvedores juniores e marketing podem transformar ideias em algo concreto rapidamente
- A versão Speed não busca compreensibilidade, e sim estar boa o bastante para obter feedback do mercado
- A versão Scale é um sistema voltado para estabilidade, projetado por desenvolvedores sêniores para ser estável, compreensível e escalável
- A versão Speed permite que a empresa continue aprendendo com o mercado, e o desenvolvedor sênior vem em seguida construindo um sistema bem revisado e compreensível
- O design da versão Scale é influenciado pelo que funcionou e pelo que não funcionou na versão Speed
- Funcionalidades são criadas em Speed e depois estabilizadas em Scale
- A forma concreta de implementação pode não ser clara, mas o ponto principal é separar explicitamente o trabalho de buscar velocidade do trabalho de buscar estabilidade
- Ao receber um pedido ambicioso, é possível dizer: “a versão Speed fica pronta em 3 dias, e a versão Scale em cerca de 6 semanas”
- A outra parte ganha velocidade e impulso, e o desenvolvedor sênior ganha tempo para observar e projetar
- Sob essa perspectiva, o desenvolvedor sênior pode se tornar menos um “escritor sênior de software” e mais um editor sênior de software
1 comentários
Comentários do Hacker News
A parte mais importante da expertise vem de um modelo de mundo interno, e isso não pode ser separado dela
Em geral, acredita-se que qualquer coisa pode ser expressa em palavras e que, se as palavras forem transmitidas, quem ouve entenderá exatamente o que a outra pessoa quis dizer; é dessa crença que surge a exigência de que a expertise de um desenvolvedor seja “transferida” para outra pessoa
Na prática, conhecimento é transmitido razoavelmente bem por palavras, mas o modelo de mundo consolidado por todas as conexões entre esses conhecimentos não é. A IA pode saber muito mais fatos, mas ainda não usa esse conhecimento de uma forma que produza insights surpreendentemente corretos com tanta frequência
Transferir expertise, na verdade, está mais para dar pistas sobre para onde ir e o que aprender, e a pessoa que recebe isso precisa internalizar com esforço e adquirir a mesma expertise por meio de projetos adequados
Dá para distinguir quem entende e aplica as “leis da física” do software de quem só vai escrevendo procedimentos sem tentar entender a essência de cada etapa
Isso fica especialmente evidente ao ensinar programação funcional para alguém acostumado com orientação a objetos: para alguns, o modelo desmorona; outros rapidamente percebem que é relativamente fácil traduzir do mundo das variáveis para o mundo das mônadas
Trabalhei por quase 30 anos principalmente em uma grande empresa e passo um bom tempo toda semana respondendo aos problemas que as pessoas novas enfrentam. Muitas vezes, só de ouvir a pergunta, já fica claro que a raiz do problema é que o modelo de mundo delas, a Theory de que Naur fala, está incompleto ou distorcido, o que dificulta o raciocínio
O desafio é converter a própria teoria em representações simbólicas como texto e diagramas, de modo que alguém com experiência e inteligência suficientes consiga formar um modelo mental parecido. Em outras palavras, quereríamos instalar a minha teoria na cabeça de outra pessoa
A teoria no sentido de Naur não pode ser transplantada diretamente, mas vejo o trabalho do desenvolvedor sênior, seja em sala de aula ou no dia a dia, como encontrar formas de trazer experiências que permitam reproduzir esse tipo de teoria. Por isso, habilidade de comunicação é importante, e é preciso passar repetidas vezes pelo processo de receber teorias operacionais de outras pessoas para desenvolver instintos eficazes
Hoje isso se tornou a parte mais gratificante do trabalho, e enquanto eu sentir que desempenho essa função de forma significativa, não quero me apressar para me aposentar
Ao treinar e orientar juniores, tento mostrar o que é possível e quais padrões levam ao fracasso, mas esse treinamento costuma ser fragmentado e incompleto
Sempre que posso explico por que fazemos assim, mas raramente digo de forma categórica o que não deve ser feito. Muitas vezes me surpreendo com a forma como as pessoas que ensinei resolvem problemas, e eu também aprendo bastante
O treinamento costuma ter menos sucesso com quem não se importa com a própria contribuição e vê o trabalho apenas como fonte de salário. Isso não quer dizer que essa visão esteja errada, mas, quando a visão de mundo sobre o trabalho é moldada pela indiferença, fica difícil internalizar o aprendizado
https://andymatuschak.org/books/
Como desenvolvedor sênior, eu realmente odeio generalizações absolutas
Já vi fracassos causados por atitudes como “isso é mesmo necessário?”, “o que acontece se a gente não fizer?”, “dá para empurrar com a barriga e voltar nisso depois se ficar mais importante?”, tanto quanto já vi fracassos causados por gente que quer experimentar tudo
Cada sistema é diferente, cada produto é diferente. Se você está fazendo firmware de um tomógrafo, sua postura diante de novidades precisa ser diferente da de um CRUD SaaS com 100 clientes
Sem dúvida existem sêniors entusiasmados e excessivamente abertos que empurram o sistema para cantos dos quais é difícil sair, mas também existe gente dizendo que PHP5 já basta
Um bom sênior precisa saber reconhecer esse momento
Aí isso vira a ideia de que, ao tomar decisões técnicas, deve-se ouvir o vice-presidente e usar Elasticsearch
Claro que às vezes é preciso agir, mas hoje em dia o equilíbrio está inclinado demais para complicar tudo além do necessário
Não quer dizer que não se devam criar novos produtos e serviços, e sim que, ao criá-los, devemos buscar o caminho de menor entropia total. Isso também vale para operações e redução de dívida técnica
Otimização prematura é a raiz de todo mal
Se é uma startup ou uma grande empresa já com forte geração de caixa, o julgamento ao mexer em funcionalidades centrais do produto será diferente
Gostei de ler o texto, e concordo com a mensagem central de se comunicar melhor de acordo com o público
Mas o enquadramento parece começar no caminho certo e depois desviar um pouco
Os dois loops apresentados se beneficiam de serem mais densos e mais rápidos. Um leva o sistema rapidamente a um ponto de ajuste “estável” e de fácil manutenção; o outro lida com incerteza
A ideia adicional de dividir sistemas para se adaptar melhor à IA também é algo que eu já explicava com spikes muito antes de a IA virar mainstream
Descobri que a vontade de comunicar e compartilhar minha expertise normalmente não encontra demanda entre desenvolvedores juniores
Em geral, desenvolvedores não têm interesse em procurar um mentor. Nem olham meu perfil no LinkedIn, nem me veem como uma possível fonte de conhecimento e expertise
Não é que, depois de 30 anos de experiência no setor, eu não tenha nada para compartilhar; é que não há com quem compartilhar
Um desenvolvedor menos experiente sugeriu substituir um validador de URL por mágica de IA, e eu me opus propondo uma solução de fuzzy matching com cache pré-preenchido por IA, mas ninguém ligou. Agora o modelo de IA caiu de repente e o sistema quebrou. Temos de validar o sistema inteiro de novo
Um desenvolvedor mais jovem que foi promovido antes de mim estava escrevendo um documento sobre como consertar isso e disse: “Dan, você pode me ajudar com isso?”. Ele foi promovido porque a forma de avançar ali não é trabalhar de maneira racional, e sim escrever documentos e fazer reuniões; agora ele quer usar o meu trabalho para provar liderança
Quanto melhores são as soluções que proponho, mais ameaçadoras elas parecem para desenvolvedores menos experientes, e como em geral as coisas acabam funcionando, os gerentes também não ligam. Talvez eu pudesse ter lidado melhor com isso, mas é cansativo demais brigar com besteira e eu só quero escrever código bom
Já os juniores querem conversar, almoçar e compartilhar o que estão fazendo. Os sêniors ficam na defensiva e isolados
Talvez seja só no nosso trabalho, mas o escritório importa
Alguns desenvolvedores sêniors de lá ficavam irritados quando um júnior fazia perguntas. Já era preciso coragem só para perguntar algo a alguém com 20 anos de casa, e havia 50% de chance de a pessoa ser grosseira
Foi uma boa experiência de aprendizado, e hoje eu me esforço deliberadamente para fazer mentoria
Fiz mentoria de forma intermitente ao longo das últimas décadas e tive a sorte de encontrar excelentes mentorados. Alguns acompanho há quase 10 anos e hoje estão indo muito bem
Não tenho algo mais útil para dizer sobre como encontrá-los, mas essas pessoas existem
Mas logo depois de eu chegar ele avisou que estava saindo porque já tinha encontrado um sucessor, e no fim isso não deu muito certo para mim
A maioria das provas de conceito que vi acabou virando produção quando ganhou tração
Já houve algumas vezes em que todos prometeram “se isso decolar, reescrevemos do zero”, mas isso nunca aconteceu
O texto toca em responsabilidade e prestação de contas, mas quem assume riscos não tem nada disso. Solta ideias malucas às pressas, lucra torcendo para que clientes mordam a isca. Como fazer aquilo funcionar e escalar, e sem que o custo operacional fique maior do que o preço de venda, não é problema dessa pessoa
Existem empresas que levaram o loop da direita ao extremo, e duas delas são muito famosas hoje em dia. Lançam algo rápido, escalam só de forma linear e então saem para captar dinheiro. São empresas bem-sucedidas, têm incontáveis usuários e alguns até pagam. Qualquer desenvolvedor sênior ou pessoa razoável que pergunte “isso é sustentável, qual é a saída?” é demitido, e só ficam os fiéis
Quando engenheiros apenas obedecem em silêncio ao que stakeholders não técnicos mandam, surge um vácuo de responsabilidade, e um dia isso explode como um desastre; depois, a culpa recai sobre quem pior consegue se defender
Por outro lado, se a perspectiva for ampla o suficiente e se forem feitas perguntas suficientes sobre o “porquê”, quase qualquer problema de negócio pode ser resolvido de um jeito sensato que não empurre o sistema para uma terrível porta de sentido único
Nem todo lugar dá esse poder à engenharia, mas os lugares que não dão não conseguem reter sêniors que querem ter seu julgamento respeitado. Às vezes dívida técnica é a escolha correta para o negócio, mas um engenheiro suficientemente sênior sempre consegue deixar uma rota de saída
Só que não dá para colocar a pureza do sistema acima do problema de negócio. Quem paga o custo do sistema é o negócio, e esquecer isso também faz você perder a base da sua influência
A conclusão do texto é, no fundo, o velho conselho: “construa um para jogar fora”. Eu também li The Mythical Man-Month, mas a questão é como convencer quem toma as decisões
Se o resultado não atendesse às expectativas, a funcionalidade era desativada ou removida; caso contrário, depois de revisão, era devidamente refatorada
A autonomia do time era alta e quase não havia reclamações sobre cronograma, porque na maior parte do tempo os outros departamentos é que estavam atrasados. Só o marketing sempre tinha “ideias”
O fato de ser um protótipo ou prova de conceito não é, em si, importante, a menos que você consiga listar quais são os problemas reais
Vejo vários times reclamando que estão atolados em dívida técnica, que há grande risco e que isso reduz a velocidade, mas no histórico de incidentes quase não há ocorrências e não há nada que pareça ter sido causado por rodar código arriscado em produção. No registro de riscos também não há itens como “este código é velho, horrível e tem dependências sem suporte”, e nenhum time consegue explicar como e quanto a dívida técnica os torna mais lentos
Por outro lado, também vi times passarem meses refatorando antes do lançamento porque achavam que podiam tornar melhor o app que eles próprios haviam escrito. Toda a entrega de valor foi atrasada, a liderança ficou obviamente irritada e quase não sobrou confiança
É preciso haver uma boa conversa sobre entrega entre o time e os stakeholders para que todos fiquem satisfeitos, mas, quando isso não existe, os stakeholders sempre vencem
Você está deixando passar o problema fundamental dos incentivos. O que a “empresa” quer não importa; importa o que querem as pessoas específicas que tomam decisões
Há pessoas cujo emprego depende apenas de lançar uma funcionalidade nova ou um app e fazer isso aparecer em algum indicador da empresa. Mesmo que um desenvolvedor sênior diga que é uma má ideia, essas pessoas não vão ouvir ou não vão se importar, porque o próprio emprego delas está em jogo
Mas, quando se trata de produto, é preciso alinhar funcionalidades às demandas dos clientes, então é preciso dizer ao pesquisador para parar de empurrar isso goela abaixo
Um sênior realmente competente entende qual é a cultura dominante da empresa atual e o que será necessário dali a 5 anos, e então se adapta a isso
Uma startup de 5 pessoas pode não precisar de complexidade adicional que reduz a runway. Uma empresa de 500 pessoas pode precisar dessa complexidade para mitigar os efeitos de segunda ordem de toda decisão de negócio
Não é uma lógica em preto e branco de “sempre evite complexidade”, e sim “adicione complexidade quando fizer sentido”, e até essa pergunta se torna muito sutil quando a empresa precisa sobreviver por mais alguns meses
Se faltam duas horas para a tempestade chegar, você deixa de pensar em arquitetura e passa a perguntar: “a água vai subir tanto que não vamos conseguir escoar?”
O problema que eu vejo é a gerência fazer jogo e não dizer quanto dinheiro realmente resta nem qual é o cronograma real. Eles têm medo de que os contribuidores saiam antes da hora crítica, e aí as pessoas continuam tomando decisões idiotas dentro daquele contexto até que no fim todos vão procurar outro emprego
Há alguns dias eu estava tentando transmitir ao time um sentimento quase idêntico, inclusive com uma frase quase igual: “precisamos mesmo construir e testar uma funcionalidade nova inteira? Já tentamos colocar um botão na UI existente para ver se as pessoas clicam?”
Parece que os engenheiros estão sofrendo coletivamente agora que o pessoal de produto decidiu que não precisa mais usar as próprias faculdades mentais. A lógica é: constrói primeiro, e a utilidade e as personas de usuário a gente descobre depois, ou talvez nunca
Antes se gastava tempo para entender o domínio, os usuários e em que processo o produto se encaixava, mas agora simplesmente se lança o que se imagina que usuários imaginários querem e se experimenta até dar certo
Surge exatamente o problema que o texto original descreve. Cada funcionalidade aleatória feita com vibe coding vira uma fonte de instabilidade e risco, e como ninguém tem um modelo mental funcional daquele objeto, a manutenção só pode ser feita com mais vibe coding
Mesmo que se pudesse reduzir complexidade a uma única dimensão de medição, ela ainda seria apenas um dos vários elementos no espaço de soluções
Há outras propriedades como manutenibilidade, escalabilidade, confiabilidade, resiliência, antifragilidade, expansibilidade, generalidade, durabilidade e componibilidade, e nem todas se aplicam sempre
Acho que a capacidade de falar disso não como dimensão única, mas como trade-offs no espaço de soluções, é o que separa desenvolvedores sêniors e Staff+
Já se ela for entendida como um fator que tornará o desenvolvimento desse sistema mais fácil e rápido pelos próximos 10 anos-pessoa, então significa escolher contornar lateralmente aquilo que uma abordagem ingênua tentaria enfrentar de frente
Como na fábula da lebre e da tartaruga, é difícil entender o fluxo em que se queimam as primeiras duas semanas correndo atrás de frutos baixos, ganhos visíveis e MVP, enquanto a velocidade continua caindo por causa de um design imaturo e da manutenção durante o desenvolvimento. Parecia “rápido” por algumas semanas, mas no fim o cronograma atrasou 6 meses
Um programador, cedo ou tarde, precisa perceber que todo aspecto possível de um design é um trade-off