- Engenheiros excepcionais não são os melhores programadores, e sim as pessoas que aprenderam a navegar pelas pessoas, pela política, pelo alinhamento e pela ambiguidade ao redor do código
- O foco está menos na tecnologia em si e mais nos padrões que aparecem repetidamente em projetos e equipes, cobrindo resolução de problemas dos usuários, colaboração em equipe, qualidade de código e gestão de carreira
- Clareza é a principal qualidade de um engenheiro sênior, e esperteza é apenas overhead; há também a percepção paradoxal de que o melhor código é o código que você não precisou escrever
- Em organizações grandes, falhas de alinhamento são a principal causa da perda de velocidade, e quando métricas viram metas, elas se distorcem — uma armadilha clássica de operação organizacional
- No longo prazo, tempo se torna um recurso mais valioso que dinheiro, e sua rede dura mais do que qualquer emprego, então é preciso desenhar a carreira de forma intencional
1. Os melhores engenheiros são obcecados por resolver problemas dos usuários
- É tentador se apaixonar primeiro por uma tecnologia e depois procurar onde aplicá-la, mas os engenheiros que criam mais valor fazem o caminho inverso: entendem profundamente o problema do usuário e derivam a solução a partir dele
- Obcecar-se pelo usuário significa investir tempo em tickets de suporte, conversar com usuários, observar suas dificuldades e continuar perguntando "por quê" até chegar à raiz
- Engenheiros que realmente entendem o problema muitas vezes descobrem que a solução elegante é mais simples do que imaginavam
- Engenheiros que começam pela solução tendem a construir complexidade para justificar a própria solução
2. Estar certo é fácil; o verdadeiro trabalho é chegar ao certo juntos
- Dá para vencer todos os debates técnicos e ainda assim perder o projeto; já vi engenheiros brilhantes que sempre eram a pessoa mais inteligente da sala, enquanto acumulavam ressentimento silencioso
- O custo aparece depois, como "problemas misteriosos de execução" e "resistência estranha"
- A habilidade central não é estar certo, mas participar da discussão para construir alinhamento sobre o problema, abrir espaço para os outros e manter uma postura cética em relação às próprias convicções
- Opiniões fortes, apego fraco — não por falta de convicção, mas porque decisões sob incerteza não devem ser acopladas à identidade
3. Lance com viés para a ação. Uma página ruim pode ser editada, uma página em branco não
- A busca pela perfeição leva à paralisia; já vi engenheiros passarem semanas debatendo a arquitetura ideal de algo que nunca chegaram a construir
- A solução perfeita não surge só do pensamento, mas do contato com a realidade, e a IA pode ajudar de várias formas
- A ordem é: faça primeiro, faça direito depois, faça melhor por último — coloque um protótipo feio diante do usuário, escreva um rascunho bagunçado do design doc, lance um MVP que dá até um pouco de vergonha
- Uma semana de feedback real ensina mais do que um mês de debate teórico; impulso gera clareza, enquanto paralisia por análise não cria nada
4. Clareza é sinal de senioridade; esperteza é overhead
- O impulso de escrever código esperto é quase universal entre engenheiros e parece uma prova de competência
- Engenharia de software acontece quando você adiciona tempo e outros programadores; nesse contexto, clareza não é preferência de estilo, e sim redução de risco operacional
- Código é um memorando estratégico para desconhecidos que vão mantê-lo às 2 da manhã durante uma falha; então, em vez de otimizar elegância, é preciso otimizar a compreensão deles
- Os engenheiros sêniores mais respeitados aprendem a trocar esperteza por clareza, todas as vezes
5. Novidade é uma dívida paga em incidentes, contratação e overhead cognitivo
- Trate escolhas tecnológicas como se a organização tivesse um pequeno orçamento de "tokens de inovação"; cada vez que adota algo realmente fora do padrão, você gasta um deles — e não dá para sustentar muitos
- O ponto não é "nunca inove", mas "inove apenas onde você é recompensado de forma única por inovar"; no resto, o padrão deveria ser o tédio
- O tédio é valioso porque já conhecemos seus modos de falha
- A "melhor ferramenta para o trabalho" muitas vezes significa "a ferramenta menos pior para muitos trabalhos", porque operar um zoológico de tecnologias cobra imposto de verdade
6. O código não defende você; as pessoas, sim
- No começo da carreira, eu acreditava que um ótimo trabalho falaria por si só, mas isso era um erro; código só fica quieto no repositório
- Seu gerente menciona você em reuniões — ou não. Um colega recomenda você para um projeto — ou recomenda outra pessoa
- Em organizações grandes, decisões são tomadas em reuniões para as quais você não foi convidado, com resumos que você não escreveu, por pessoas com 5 minutos e 12 prioridades
- Se ninguém consegue explicar seu impacto nas salas em que você não está, esse impacto se torna, na prática, opcional; isso não é autopromoção, e sim tornar a cadeia de valor legível para todos, inclusive para você mesmo
7. O melhor código é o código que não precisou ser escrito
- A cultura de engenharia celebra criação, mas muitas vezes apagar código melhora mais o sistema do que adicionar código, embora ninguém seja promovido por deletar linhas
- Cada linha de código que você não escreve é uma linha que não precisa ser depurada, mantida ou explicada
- Antes de construir, é preciso esgotar a pergunta: "E se a gente simplesmente... não fizer isso?" — às vezes a resposta é "nada ruim acontece", e essa passa a ser a solução
- O problema não é que engenheiros não consigam escrever código ou gerá-lo com IA, mas sim que escrevem tão bem que esquecem de perguntar se ele realmente precisa existir
8. Em escala, até bug tem usuários
- Quando há usuários suficientes, todo comportamento observável vira uma dependência, independentemente da intenção — alguém faz scraping da API, automatiza a bizarrice e coloca o bug em cache
- Isso leva a um insight de nível de carreira: não dá para tratar trabalho de compatibilidade como "manutenção" e funcionalidade nova como "trabalho de verdade"; compatibilidade é o produto
- É preciso projetar descontinuações como migrações, com tempo, ferramentas e empatia
- A maior parte do "design de API" é, na prática, "aposentadoria de API"
9. A maioria das equipes "lentas" está, na verdade, desalinhada
- Quando um projeto atrasa, o instinto é culpar a execução — as pessoas não estão se esforçando o suficiente, a tecnologia está errada, faltam engenheiros — mas, na maioria das vezes, esse não é o problema real
- Em empresas grandes, equipes são a unidade de concorrência, mas o custo de coordenação cresce geometricamente à medida que o número de equipes aumenta
- A maior parte da lentidão é, na verdade, falha de alinhamento — construir a coisa errada ou construir a coisa certa de formas incompatíveis
- Engenheiros sêniores gastam mais tempo esclarecendo direção, interfaces e prioridades do que "escrevendo código mais rápido", porque é aí que está o gargalo de verdade
10. Foque no que você controla e ignore o que é impossível controlar
- Em empresas grandes, inúmeras variáveis estão fora do seu controle — mudanças organizacionais, decisões da gestão, mudanças de mercado, pivôs de produto — e fixar-se nisso cria ansiedade sem agência
- Engenheiros eficazes e mentalmente estáveis focam no seu círculo de influência — você não controla se haverá uma reorganização, mas controla a qualidade do seu trabalho, sua resposta e o que aprende
- Diante da incerteza, é preciso quebrar o problema em partes e identificar ações concretas que estão ao seu alcance
- Isso não é aceitação passiva, e sim foco estratégico; energia gasta no que não pode ser mudado é energia roubada do que pode
11. Abstração não remove complexidade; só a transfere para quando você estiver de plantão
- Toda abstração é uma aposta de que você não vai precisar entender o que existe por baixo, e às vezes essa aposta funciona
- Mas sempre há algum vazamento, e quando ele acontece você precisa saber sobre o que está pisando
- Engenheiros sêniores continuam aprendendo as coisas "de baixo nível" conforme a stack cresce — não por nostalgia, mas por respeito ao momento em que a abstração falha e você fica sozinho com o sistema às 3 da manhã
- Use a stack, mas mantenha um modelo operacional dos seus modos básicos de falha
12. Escrever força clareza. A forma mais rápida de aprender melhor algo é tentar ensinar
- Escrever força clareza; ao explicar um conceito para outra pessoa — em documentação, apresentações, comentários de code review ou até em conversa com IA — você descobre lacunas na própria compreensão
- O ato de tornar algo legível para outra pessoa também o torna mais legível para você mesmo
- Isso não quer dizer que você aprende a ser cirurgião ensinando a operar, mas a premissa é amplamente verdadeira no universo da engenharia de software
- Não é só generosidade ao compartilhar conhecimento; também é um hack egoísta de aprendizado — se você acha que entendeu algo, tente explicá-lo de forma simples; onde você travar, sua compreensão é rasa
- Ensinar é depurar seu próprio modelo mental
13. O trabalho que viabiliza outro trabalho é valioso, mas invisível
- Trabalho de cola — documentação, onboarding, coordenação entre equipes, melhoria de processos — é essencial, mas, se feito de forma inconsciente, pode estagnar sua trajetória técnica e levar ao burnout
- A armadilha é tratá-lo apenas como algo "prestativo", em vez de algo intencional, com limites e com impacto visível
- É preciso limitar no tempo, rotacionar e transformar em entregáveis: documentação, templates, automação — e tornar isso legível como impacto, não como traço de personalidade
- Ser valioso e invisível ao mesmo tempo é uma combinação perigosa para a carreira
14. Se você vence toda discussão, provavelmente está acumulando resistência silenciosa
- Aprendi a desconfiar das minhas próprias convicções, e quando é fácil demais "vencer", geralmente há algo errado
- As pessoas podem parar de discutir com você não porque foram convencidas, mas porque desistiram, e então expressam o desalinhamento na execução, não na reunião
- Alinhamento real leva mais tempo — exige compreender de verdade outras perspectivas, incorporar feedback e, às vezes, mudar de ideia em público
- A sensação de curto prazo de estar certo vale muito menos do que a realidade de longo prazo de construir algo com colegas dispostos a colaborar
15. Quando a medição vira meta, ela deixa de medir
- Toda métrica exposta à gestão acaba sendo manipulada, não por malícia, mas porque seres humanos otimizam aquilo que é medido
- Se você mede linhas de código, ganha mais linhas; se mede velocidade, ganha estimativas infladas
- O movimento de sênior é responder a cada pedido de métrica em par — uma para velocidade, outra para qualidade ou risco — e então defender a interpretação de tendências, não a adoração de limiares
- O objetivo é insight, não vigilância
16. Admitir o que você não sabe cria mais segurança do que fingir que sabe
- Um engenheiro sênior que diz "não sei" não está demonstrando fraqueza; está criando permissão
- Quando a liderança admite incerteza, sinaliza que os outros também podem fazer o mesmo; a alternativa é uma cultura em que todos fingem entender até o problema explodir
- Já vi equipes em que a pessoa mais sênior não admitia confusão, e o estrago disso: perguntas não surgem, suposições não são desafiadas, e engenheiros júnior ficam em silêncio porque presumem que todos os demais entenderam
- Modelar curiosidade faz surgir equipes que realmente aprendem
17. Sua rede dura mais do que qualquer emprego que você terá
- No início da carreira, foquei no trabalho e negligenciei networking; olhando para trás, foi um erro
- Colegas que investiram em relacionamentos — dentro e fora da empresa — colheram benefícios por décadas
- Eles souberam de oportunidades primeiro, conseguiram construir pontes mais rápido, foram indicados para cargos e cofundaram ventures com pessoas em quem vinham construindo confiança ao longo dos anos
- Empregos não duram para sempre, mas sua rede dura mais do que cada um deles — e ela deve ser cultivada com curiosidade e generosidade, não com correria transacional
- Quando chega a hora de sair, muitas vezes são os relacionamentos que abrem as portas
18. A maior parte dos ganhos de performance vem de remover trabalho, não de adicionar esperteza
- Quando um sistema fica lento, o instinto é adicionar coisas — camada de cache, paralelismo, algoritmos mais inteligentes — e às vezes isso está certo, mas os maiores ganhos costumam vir de perguntar: "o que não precisa ser computado?"
- Remover trabalho desnecessário quase sempre tem mais impacto do que acelerar o trabalho necessário; o código mais rápido é o que não roda
- Antes de otimizar, questione se o trabalho precisa existir
19. Processo existe para reduzir incerteza, não para criar trilha de papel
- Os melhores processos tornam a coordenação mais fácil e as falhas mais baratas; os piores são teatro burocrático — existem não para ajudar, mas para apontar culpados quando algo dá errado
- Se você não consegue explicar como um processo reduz risco ou aumenta clareza, provavelmente ele é só overhead
- Se as pessoas estão gastando mais tempo documentando o trabalho do que fazendo o trabalho, há algo seriamente errado
20. Em algum momento, tempo passa a valer mais do que dinheiro — aja de acordo
- No início da carreira, você troca tempo por dinheiro, e tudo bem; mas em algum momento a conta se inverte — você começa a perceber que tempo é um recurso não renovável
- Já vi engenheiros sêniores entrarem em burnout perseguindo o próximo nível de promoção e otimizando mais alguns pontos percentuais de remuneração
- Alguns conseguiram o que queriam, mas a maioria depois se perguntou se valeu a pena o que abriu mão
- A resposta não é "não trabalhe duro", e sim "saiba o que está trocando e faça essa troca de forma intencional"
21. Não há atalho, mas há juros compostos
- Maestria vem de prática deliberada — forçar-se um pouco além da habilidade atual, refletir e repetir, ao longo de anos — não existe versão comprimida disso
- A parte esperançosa é que o aprendizado rende juros compostos quando cria novas opções, não apenas pequenos blocos de conhecimento novo
- Escreva — não para engajamento, mas para clareza —, construa componentes reutilizáveis e transforme cicatrizes em playbooks
- Engenheiros que tratam a carreira como juros compostos tendem a ir muito mais longe do que aqueles que a tratam como bilhete de loteria
Considerações finais
- Essas 21 lições parecem muitas, mas no fim se resumem a algumas ideias centrais: mantenha a curiosidade, mantenha a humildade e lembre que o trabalho é sempre sobre pessoas — os usuários para quem você constrói e a equipe com quem você constrói
- Uma carreira em engenharia é longa o bastante para você cometer muitos erros e ainda assim avançar; os engenheiros que mais respeito não são os que acertaram tudo, mas os que aprenderam com o que deu errado, compartilharam o que descobriram e continuaram aparecendo
- Se você está no começo da jornada, saiba que isso enriquece com o tempo; se já está em profundidade nela, espero que parte disso ressoe com você
5 comentários
Comentários do Hacker News
Isso me fez lembrar da frase: quando algo escala, até bug ganha usuário
No meu primeiro emprego, quando reduzimos o tempo de carregamento de 5 minutos para 30 segundos, os clientes reclamaram bastante
Era porque aquele tempo em que deixavam o computador ligado, iam tomar café e bater papo tinha desaparecido
A lição dessa história não é simplesmente “não melhore nada”, mas sim não esquecer que software existe dentro dos hábitos e interações de pessoas reais
O trabalho de um engenheiro não é fechar tickets, e sim resolver problemas reais dos usuários
Quanto mais a eficiência aumentava, mais trabalho físico os funcionários tinham de fazer, e isso acabou gerando insatisfação
No fim, eu parecia “a pessoa que estragou um sistema bom”
Há uma frase que diz: “com usuários suficientes, todo comportamento observável de um sistema passa a ser uma dependência para alguém”
Toda vez eu pensava “agora eles vão corrigir”, mas como não foi corrigido por 10 anos, isso acabou sustentando o negócio
Os três entendem o problema de formas diferentes
O significado do código não muda por intenção ou desejo; ele só funciona dentro das restrições do mundo real
Texto relacionado: Laws of Software Evolution
Mas nem toda empresa pensa assim
É importante entender com clareza as expectativas na entrevista
Ao ver esse texto escrito por Addy Osmani, senti um pouco de hipocrisia
No passado ele plagiou meu código e depois publicou um pedido de desculpas, mas não o compartilhou nas redes sociais
Se o pedido fosse realmente sincero, acho que ele também deveria ter sido tornado público para os seguidores
As três primeiras lições me tocaram especialmente
O problema é que, na formação, ensina-se linguagem e framework, mas não o próprio problema
O consenso se constrói no processo criativo, e poder deve ser usado em momentos de crise
Muitas vezes se perde tempo discutindo por medo de falhar
Foi no ensaio “Boring Technology” que aprendi pela primeira vez o conceito de “innovation tokens”
É um texto do boringtechnology.club e ainda hoje continua sendo um dos meus textos favoritos sobre arquitetura
A frase “abstração não remove complexidade, ela apenas a transfere para quando você estiver de plantão” me lembra a Law of Leaky Abstractions de Joel Spolsky
Durante 15 anos de liderança, operei sistemas bilionários numa grande empresa de varejo
Mas, no fim, o que importava era política e relações humanas
Pessoas mais inteligentes também deixavam de ser promovidas por não saberem lidar com política
A conclusão amarga é que talvez seja preciso ensinar aos filhos a “aprender política e bajulação”
Concordo profundamente com a frase “Clareza é senioridade”
Clareza é o núcleo da manutenibilidade e da escalabilidade
Escrevi o livro Elements of Code para ensinar isso
Abstração não é algo ruim em si; o problema está na clareza do propósito
É como um engenheiro civil construindo uma ponte dentro de um galpão sem olhar o terreno
O problema não é culpar a abstração em si, mas entender o que se está tentando modelar
Uma abstração errada prejudica a clareza e produz complexidade desnecessária
Acho até melhor uma abstração insuficiente do que uma abstração errada
O verdadeiro valor de listas como essa está em escrevê-las você mesmo
Só ler faz esquecer rápido; isso só ganha sentido quando você organiza as ideias olhando para a própria carreira
Esse texto não representa os valores oficiais do Google, e sim lições pessoais aprendidas trabalhando no Google
Não são coisas ensinadas pela organização, mas descobertas por conta própria ao longo da experiência
O ponto principal é que essas continuam sendo dificuldades reais mesmo em grandes empresas
A frase “quando algo escala, até bug ganha usuário” se parece com o fenômeno de ossification (enrijecimento)
Isso vale não só para protocolos de rede, mas para qualquer sistema
O motivo do design criptografado de HTTP/3 e QUIC também é impedir que dispositivos intermediários façam suposições erradas
O mesmo vale para APIs: elas não devem expor estado interno
A frase “Bias towards action” me marcou bastante
Por melhor que seja um conselho, ele não ajuda uma página em branco
É preciso construir alguma coisa primeiro para então receber feedback
No momento em que você digita a primeira letra, começam a aparecer problemas inesperados
Quanto maior a organização, mais esses gargalos invisíveis existem
“Ship fast” não quer dizer “publique algo malfeito”
Acho até melhor um produto mínimo viável bem-acabado
A distância entre ideal e realidade é grande, e o autor ironiza dizendo que “o Kool Aid estava gostoso”
Senão, isso é interpretado como algo “nas coxas” e, quando dá problema, alguém vira bode expiatório
Que texto bacana. Foi uma oportunidade de relembrar a ideia de que o crescimento na carreira inclui também o amadurecimento pessoal. Gostei muito da leitura.
Palavras certíssimas, do começo ao fim.
A lição nº 1 já é importantíssima desde o começo.
Ultimamente tenho sentido isso profundamente rs
Havia conteúdo bom demais e muitas frases cheias de insight, a ponto de eu soltar exclamações de admiração. Gostei ainda mais por terem destacado as principais frases em negrito.
"Estar certo, como sensação de curto prazo, vale muito menos do que a realidade de longo prazo de construir algo junto com colegas dispostos a colaborar."
"É preciso ter foco estratégico, e a energia gasta naquilo que não pode ser mudado é energia roubada daquilo que pode ser mudado."
Havia muitos pontos bons para aplicar não só ao trabalho, mas também à vida. Obrigado pelo ótimo texto.
"Código é uma nota estratégica para pessoas desconhecidas que vão fazer manutenção às 2 da manhã durante uma falha, por isso deve ser possível otimizar a compreensão."
"Momentum cria clareza, e paralisia por análise não constrói nada."