Cada escolha uma renúncia: os dilemas diários de quem constrói e de quem lidera

Sexta à tarde. A PR está aberta há três dias. O código funciona, os testes passam, mas você sabe que aquela abstração que criou vai ficar estranha assim que o próximo caso de uso chegar, e dois já estão no roadmap. Você tem duas opções: dar merge agora e voltar na próxima sprint, ou reabrir tudo, repensar a API e empurrar a feature pra semana que vem.

Não existe resposta certa. Existe a resposta que você escolhe viver com.

Trabalhar com software é, no fundo, escolher constantemente o que não fazer. A parte fácil, mas que ninguém fala, é que a maior parte dessas escolhas não é entre “bom” e “ruim”. É entre dois caminhos razoáveis com custos diferentes, pagos em momentos diferentes, por pessoas possivelmente diferentes.

Photo by Einar Storsul on Unsplash

O trabalho do engenheiro é escolher

Quando eu era júnior, achava que engenharia era sobre saber a resposta certa. Que existia um jeito “certo” de modelar aquele domínio, um padrão “certo” de dividir aquele módulo, uma arquitetura “certa” pra aquele serviço. Hoje sei que isso é quase sempre uma ilusão confortável. E que quanto mais sênior você fica, mais tempo passa parado na frente do teclado tentando decidir, não implementando.

Alguns dos tradeoffs que aparecem todo santo dia:

Abstração vs duplicação. O famoso DRY vendeu a ideia de que duplicar código é pecado. Mas abstração errada custa mais caro do que duplicação honesta. Porque duplicação você vê, abstração errada você sente meses depois, quando precisa adicionar um parâmetro que não se encaixa em lugar nenhum. A regra “abstraia na terceira repetição” é boa, mas só funciona se você souber o que é realmente a mesma coisa. Dois trechos idênticos hoje podem ser duas coisas que acontecem (o tão conhecido “por acaso”) de ser iguais e vão divergir amanhã.

Consistência vs solução ótima. Seu time tem um padrão pra lidar com erros de domínio. Num caso específico, outra abordagem seria claramente melhor. O que você faz? Quebrar o padrão significa que o próximo dev vai precisar entender duas formas de fazer a mesma coisa. Seguir o padrão significa aceitar uma solução subótima por coesão. Na maioria das vezes eu escolho consistência. O custo cognitivo de manter o sistema legível é mais alto do que os 10% de elegância que você perde.

Shipping vs polimento. Funciona, mas não tá bonito. Tem um edge case que vai acontecer uma vez a cada dez mil requests. Tem um nome de variável que você mudaria. Você fecha a PR ou gasta mais duas horas? A resposta honesta é: depende do que isso trava pra frente. Polimento com o time esperando é egoísmo disfarçado de qualidade.

Compatibilidade vs código limpo. Você quer mudar a assinatura daquela função, mas ela é chamada em 40 lugares, alguns em serviços que outro time mantém. Você faz a mudança “certa” e assume o custo de alinhar, ou cria uma camada de compatibilidade e aceita um pouco de feiura? Normalmente a camada de compatibilidade é a escolha certa. O que as pessoas esquecem é de remover ela depois.

O que esses casos têm em comum: não tem ninguém do outro lado pra discordar. Você decide, você paga, você aprende. O feedback loop é o código em si, funcionando ou quebrando na sua cara.

Quando a escolha começa a envolver gente

O pulo pra engineering manager é tratado como uma transição de carreira, mas o que muda de fato é a natureza do custo. Você continua fazendo tradeoffs o dia inteiro. Só que agora a variável de ajuste não é mais performance, legibilidade ou tempo de build. É a carreira, a motivação e, às vezes, a saúde mental de outra pessoa.

Alguns exemplos dos que eu acho mais difíceis:

Quem pega o projeto bom? Tem um projeto crítico, visibilidade alta, chance de promoção. Tem uma pessoa sênior que entrega com baixo risco e um pleno que precisa desse projeto pra crescer. Se você dá pro sênior, o pleno estagna e eventualmente sai. Se você dá pro pleno, aumenta o risco do projeto e talvez queime a confiança do stakeholder. Não existe escolha sem custo. A diferença é que uma opção é cômoda pra você, a outra exige que você defenda a decisão depois.

Feedback agora ou feedback depois? Alguém no time fez uma escolha técnica questionável numa reunião com o PM presente. Você corrige na hora (e arrisca enfraquecer a pessoa na frente do stakeholder) ou espera o 1:1 na próxima terça (e deixa o PM sair com uma informação errada)? A resposta “depende” é real aqui, mas o padrão do time se forma pelas suas microdecisões, não pelo que você escreve no handbook.

Proteger vs confrontar. Uma pessoa do time está performando abaixo do esperado. Você pode ajustar a carga, dar projetos mais fáceis e esperar ela melhorar, ou ter a conversa desconfortável de “isso não está funcionando”. Proteger parece gentileza e é, no curto prazo. No médio, é covardia, porque você está tomando por ela uma decisão que ela tem direito de tomar com informação completa.

Senioridade vs mistura. Time com muitos sêniores entrega rápido, mas não forma gente e tende a brigar por escopo interessante. Time com mix maior forma gente, mas tem mais retrabalho e precisa de mais investimento em mentoria. Nenhum é “melhor”. Depende do que a empresa precisa e do que você tem energia pra conduzir.

Dizer não ao produto. Time de produto quer a feature X pra próxima sprint. Você sabe que o time está com débito técnico acumulado e que mais uma entrega apressada vai quebrar algo. Ceder é fácil no curto prazo: você vira parceiro, entrega, todo mundo feliz. Segurar é impopular e exige que você explique, em termos de negócio, por que esperar é melhor. A maioria dos EMs que eu vi falhar não falhou por incompetência técnica. Falhou por não saber dizer não.

Repara uma coisa: nenhuma dessas decisões tem testes automatizados. Não tem CI pra te avisar se você escolheu errado. Você descobre seis meses depois, num all-hands, numa retrospectiva, ou num Slack de sexta à noite dizendo que alguém vai sair.

O peso que importa

Aqui está a parte que eu acho que poucos artigos sobre o tema chegam a dizer: a diferença entre o tradeoff técnico e o tradeoff humano não é a dificuldade, é a reversibilidade.

Uma escolha ruim de arquitetura se refatora. Dói, custa sprint, atrapalha roadmap, mas volta. Uma escolha ruim de pessoas (quem você contratou, quem você promoveu, quem você deixou ir sem reter, quem você manteve no time quando já não deveria) essas não voltam. A pessoa não volta. A confiança que ela perdeu em você não volta. A cultura que se formou em volta daquela decisão leva anos pra mudar.

Isso tem uma implicação prática que vale reter: quando o custo é reversível, decida rápido; quando é irreversível, decida devagar. É contraintuitivo, porque a pressão por velocidade em geral vem nos dois casos com a mesma intensidade. Mas é ela que separa EMs que amadurecem dos que vão queimar o time em três anos.

O que eu tento lembrar

Três coisas que eu tento manter em mente, e falho constantemente nas três:

Primeiro, toda escolha é uma renúncia. Se você acha que encontrou uma opção sem custo, é porque não procurou o custo direito. Quando o custo não aparece na sua frente, em geral ele está sendo pago por alguém que não está na reunião.

Segundo, tradeoff não é desculpa pra omissão. Dizer “é um tradeoff” e não se posicionar é das piores formas de liderança técnica. Se você vê duas opções, fale qual você escolheria e por quê. As pessoas não precisam que você seja neutro. Precisam que você pense alto.

Terceiro, escolher errado faz parte. O problema não é errar. O problema é errar sem aprender, ou errar e não corrigir porque admitir o erro machuca o ego. O engenheiro sênior e o EM que eu respeito têm em comum uma coisa: eles mudam de ideia quando a informação muda. Não é fraqueza. É o único jeito de ficar bom nisso.

No fim, escolher é o trabalho. E viver com a escolha é a outra metade dele.