Mais 14 lições aprendidas em 14 anos no Google
(addyo.substack.com)1. Os melhores engenheiros escolhem os problemas certos
Não dá para dedicar o máximo de energia a tudo.
2. Se você não sabe o que precisa pedir, você não está pronto para a reunião
Aprovação, escolha, desbloqueio (unblock), compartilhamento de informação (inform) — se você não consegue escolher um desses, a reunião provavelmente será uma perda de tempo.
3. "Temos que fazer" não é um plano. "Vou fazer na terça-feira" é um plano.
Definir uma data concreta cria impulso.
4. Código lento é só um sintoma; decisões lentas são a causa real.
Se levar semanas, e não horas, para decidir algo, vale investigar o motivo.
5. Trate confiabilidade (Reliability) como uma funcionalidade do produto
Assim como você não lança uma funcionalidade sem revisar o produto, também não deve implantar um sistema sem discutir confiabilidade.
6. Se a interface entre equipes é ruim, a comunicação não pode ser boa
Limites ambíguos e contratos (Contract) pouco claros geram mais reuniões e mais canais no Slack. É preciso deixar claro quem é responsável por quê e como as dependências funcionam entre as partes.
7. A melhor escalada vem acompanhada de uma proposta.
Tanto quem levanta o problema quanto quem o resolve entenderam a questão, mas só um dos lados conquista confiança e autonomia.
8. Construa sistemas que não precisem de heróis
Se uma pessoa está constantemente salvando a empresa ou a equipe, isso não é glória — é um sinal de que algo está desmoronando.
9. Trate observabilidade (Observability) como parte da funcionalidade
Considere o trabalho concluído apenas quando for possível confirmar que "o código está funcionando bem".
10. PRs pequenos são um gesto de consideração. Especialmente se foram gerados por IA.
PRs pequenos permitem pensar de forma incremental, acumulando conhecimento aos poucos.
11. Ao adicionar uma nova equipe, você adiciona não só nós (Node), mas também arestas (Edge)
Se você não reduzir intencionalmente os pontos de conexão, adicionar uma nova equipe não muda o resultado.
12. Migração nunca é apenas migração
As migrações que realmente se concluem têm três pontos em comum: um patrocinador (Sponsor) que permanece envolvido, uma equipe que de fato lidera a migração e uma data final clara em que todos confiam. Se esses três elementos não estiverem presentes, a migração ficará para sempre em um estado de "quase concluída", e você ficará responsável por dois sistemas para sempre.
13. A IA facilita criar rascunhos, e o bom gosto (Taste) está ficando cada vez mais raro.
Os engenheiros capazes de selecionar o que há de melhor serão os melhores desta era.
14. Confiança é otimização de latência
Cada vez que você cumpre uma promessa, admite um erro com honestidade ou facilita a vida dos outros, você está fazendo um depósito. Já vi engenheiros com habilidades técnicas medianas alcançarem resultados extraordinários simplesmente porque todos confiavam neles.
Este é um texto de continuação de https://pt.news.hada.io/topic?id=24909.
2 comentários
Recomendo ler o texto original.
Há muitas expressões e palavras cheias de insight, então em vários momentos ele me fez refletir com base na experiência.
O conteúdo é longo e pode parecer pesado, mas são textos realmente excelentes, a ponto de eu sentir que não há nada aqui que devesse ser enxugado nem cortado por excesso.
5 e 9 eu conheço, mas são fáceis de deixar passar
12, 13 e 14 são impressionantes