Escrever um programa não é difícil, mas a dificuldade reside em lidar com “pessoas” e “complexidade”. Engenheiros veteranos da Google partilham 14 anos de experiência, desde o pensamento do utilizador ao trabalho em equipa; estas 21 regras de ouro podem ajudá-lo a alcançar uma carreira mais profunda.
(Sinopse: O Google Real-time Translate inaugura oficialmente todas as marcas de auscultadores: 70+ línguas estão online, e os telemóveis Android nos Estados Unidos, México e Índia serão lançados primeiro)
(Suplemento de contexto: A Google lançou oficialmente o “Gemini 3”!) Quais são os destaques de alcançar o topo do modelo de IA mais inteligente do mundo? ）

Índice deste artigo

• 1. Os melhores engenheiros são obcecados em resolver problemas dos utilizadores
• 2. “Provar que tens razão” não vale nada, e a chave é alcançarem juntos o objetivo certo
• 3. Orientado para a ação. Vai ao vivo! Podes editar uma página má, mas não podes editar uma página em branco
• 4. A antiguidade reflete-se na clareza, e a inteligência reflete-se no fardo
• 5. “Novidade” é usura emprestada da manutenção, recrutamento e carga cognitiva
• 6. O código não fala por ti, as pessoas falam
• 7. O melhor código é a linha que nunca escreveste
• 8. Quando é suficientemente grande, até o teu bug tem utilizadores
• 9. A maioria das equipas “lentas” são, na verdade, equipas “fora de foco”
• 10. Foca-te no que podes controlar e ignora o que não consegues
• 11. A abstração não elimina a complexidade, apenas a transfere
• 12. Escrever é compulsivo e claro, e ensinar é a forma mais rápida de aprender
• 13. O trabalho que torna outros empregos possíveis é inestimável, mas invisível
• 14. Se ganhar todas as discussões, pode estar a acumular resistência silenciosa
• 15. Quando um indicador se torna um objetivo, deixa de ser um bom indicador
• 16. Admitir “não sei” cria mais uma sensação de segurança do que fingir compreender
• 17. O teu contexto dura mais do que qualquer trabalho que já fizeste
• 18. A maioria dos ganhos de desempenho resulta de “remover trabalho” em vez de “algoritmos inteligentes”
• 19. Existem processos para reduzir a incerteza, não para criar papelada
• 20. No fim, o tempo valerá mais do que o dinheiro, aja em conformidade
• 21. Não há atalhos, mas existe um efeito de juros compostos

• Um pouco de reflexão

Addy Osmani, Diretora de IA do Google Cloud, é uma experiente engenheira de software e pensadora que tem sido Chefe de Experiência para Desenvolvedores na Chrome durante quase 14 anos, trabalhando em projetos como DevTools, Lighthouse e Core Web Vitals. Atualmente, coordena o trabalho entre o Google DeepMind, engenharia, produto e equipas de relações com programadores.

Publicou um artigo aprofundado sobre experiências no local de trabalho no seu blogue pessoal no dia 3. Combinando os seus anos de experiência profissional na Google com o seu profissionalismo, resumiu 21 sugestões valiosas sobre comunicação, escolha tecnológica e planeamento de carreira, compiladas e organizadas da seguinte forma:

Quando entrei na Google há cerca de 14 anos, pensei que tudo se resumia a escrever o código perfeito. Só estava parcialmente certo. Quanto mais tempo fiquei, mais percebi que os engenheiros que se destacam não são necessariamente os melhores a programar, mas sim aqueles que aprendem a fazê-loNavega por tudo para além do códigoPessoas: incluindo relações interpessoais, política no local de trabalho, alinhamento consensual e incerteza.

Estas experiências são coisas que gostaria de ter compreendido mais cedo. Alguns pouparam-me meses de frustração, enquanto outros demoraram anos a perceber verdadeiramente. Nada disto tem a ver com tecnologia específica: a tecnologia muda demasiado depressa e não importa. São sobre padrões que se repetem em diferentes projetos e equipas.

Partilho isto porque beneficiei imenso de engenheiros dispostos a elevar a geração mais jovem. Este é o meu pequeno pensamento.

1. Os melhores engenheiros são obcecados em resolver problemas dos utilizadores

É muito tentador apaixonar-se por uma certa tecnologia e procurar cenários de aplicação. Eu já o fiz, toda a gente já o fez. Mas os engenheiros que criam mais valor trabalham “ao contrário”: estão obcecados em compreender profundamente o problema do utilizador e deixam que a solução surja naturalmente dessa compreensão.

Os utilizadores são obcecadosSignifica passar tempo a pesquisar tickets de atendimento ao cliente, falar com os utilizadores, observar os seus dilemas operacionais e perguntar constantemente “porquê” até chegarem ao núcleo. Engenheiros que compreendem verdadeiramente o problema muitas vezes descobrem que as soluções elegantes são muitas vezes mais simples do que o esperado.Engenheiros que partem de uma solução frequentemente acrescentam complexidade desnecessária para racionalizar as suas próprias soluções.

2. “Provar que tens razão” não vale nada, e a chave é alcançarem juntos o objetivo certo

Podes ganhar todos os debates técnicos e perder todo o projeto. Já vi engenheiros inteligentes acumularem ressentimento silencioso porque querem sempre ser a pessoa mais inteligente na sala. Este custo manifestar-se-á então como “problemas misteriosos de execução” ou “resistência inexplicável”.

A competência não reside em estar “certo”, mas em participar em discussões para alinhar problemas, criar espaço para os outros e duvidar da própria certeza. Assertividade forte, mente aberta– Isto não é por falta de fé, mas porque as decisões tomadas em situações incertas não devem estar ligadas à tua autoestima.

3. Orientado para a ação. Vai ao vivo! Podes editar uma página má, mas não podes editar uma página em branco

A busca pela perfeição pode levar à paralisia. Já vi engenheiros passarem semanas a discutir a arquitetura ideal para algo que nunca construíram. O esquema perfeito raramente surge do pensamento puro – surge de uma colisão com a realidade. A IA pode ajudar de várias formas.

**Faz primeiro, depois faz bem e, finalmente, faz melhor.**Apresentar protótipos feios aos utilizadores. Escreve o primeiro rascunho de um documento de design desarrumado. Publica aquele MVP que te faz sentir um pouco envergonhado. Podes aprender mais com uma semana de feedback real do que com um mês de argumentos teóricos.O momento traz clareza, enquanto a paralisia por análise não leva a nada.

4. A antiguidade reflete-se na clareza, e a inteligência reflete-se no fardo

O instinto de escrever código “inteligente” é quase universal para os engenheiros, e parece uma prova de competência. Mas a engenharia de software é uma reação química de “tempo” mais “outros programadores”. Neste ambiente, a clareza não é uma preferência de estilo;Reduzir o risco operacional。

O teu código é um memorando estratégico para estranhos que possam estar a corrigir uma falha às duas da manhã. Otimiza a compreensão deles, não o teu sentido de graça. Os engenheiros seniores que mais admiro escolhem sempre trocar “inteligente” por “limpo”.

5. “Novidade” é usura emprestada da manutenção, recrutamento e carga cognitiva

Pense nas suas escolhas tecnológicas como uma empresa de “token de inovação” com orçamento limitado. Sempre que usar tecnologia substancialmente não convencional, gaste uma. Não podes pagar muito. A questão não é “nunca inovar”, mas "Inove apenas onde recebe um salário único」。

Tudo o resto deveria ser “aborrecido” porque o tédio significa que o seu modo de lapso é conhecido. A “melhor ferramenta para o trabalho” é muitas vezes a “ferramenta que tem melhor desempenho em múltiplas tarefas”- Porque gerir um zoo técnico vai tornar-se um verdadeiro fardo.

6. O código não fala por ti, as pessoas falam

No início da minha carreira, pensei que um bom trabalho falaria por si. Eu estava enganado. O código fica silencioso no armazém. Se o teu supervisor te menciona nas reuniões e se os teus colegas recomendam que participes no projeto é o que importa.

Em grandes organizações, as decisões são tomadas numa reunião para a qual não foste convidado, por alguém que só teve cinco minutos para trabalhar em doze prioridades, com base num resumo que não escreveste. Se ninguém te pode dizer a tua influência quando não estás presente, então a tua influência é dispensável. Não é propriamente autopromoção, trata-se deTornar a cadeia de valor visível para todos, incluindo para ti próprio。

7. O melhor código é a linha que nunca escreveste

A cultura de engenharia celebra a criação. Ninguém é promovido ao apagar código, embora apagar normalmente otimize melhor o sistema do que aumentá-lo. Cada linha de código que não escreves é algo que nunca precisas de depurar, manter ou explicar.

Antes de construir, faça a si próprio a pergunta cuidadosamente: "**O que acontece se não o fizermos de todo?**Por vezes, a resposta é “nada de mau”, e essa é a tua solução. O problema não é que os engenheiros não saibam escrever código ou não saibam escrever com IA, mas sim que somos tão bons a escrever que nos esquecemos de perguntar “devo escrever?”

8. Quando é suficientemente grande, até o teu bug tem utilizadores

Quando há utilizadores suficientes, qualquer comportamento observável torna-se uma dependência – independentemente do que prometeste originalmente (Lei de Hiram). Alguém está a extrair a tua API, a automatizar as tuas funcionalidades avançadas e a guardar em cache os teus bugs.

Isto resulta numa perspetiva profissional: não se pode pensar no trabalho de compatibilidade como “manutenção” e nas novas funcionalidades como “trabalho real”.A compatibilidade é o próprio produto. Ao desenhar um cenário de depreciação, pense nele como um processo de migração com tempo, ferramentas e empatia. A maior parte do “design de APIs” é na verdade “aposentamento de API”.

9. A maioria das equipas “lentas” são, na verdade, equipas “fora de foco”

Quando um projeto estagna, o instinto é culpar a execução: falta de mão-de-obra, escolha tecnológica errada. Normalmente, estas não são as questões centrais. Numa empresa grande, a equipa é a sua unidade de concorrência, mas o custo da coordenação aumenta exponencialmente à medida que a equipa aumenta. Na verdade, a maioria é lentaFalha no alinhamento— As pessoas estão a construir a coisa errada, ou a construir a coisa certa de forma incompatível. Os engenheiros seniores passam mais tempo a clarificar direções, interfaces e prioridades do que a “escrever código mais depressa”, porque é aí que está o verdadeiro gargalo.

10. Foca-te no que podes controlar e ignora o que não consegues

Nas grandes empresas, existem inúmeras variáveis que não se podem controlar—reestruturação organizacional, decisões de gestão, mudanças de mercado, mudanças de produto. Preocupar-me com isto causa ansiedade, mas não ajuda. Engenheiros que se mantêm sãos e eficientes vão focar-se nelesCírculo de influência。

Não podes controlar a reestruturação, mas podes controlar a qualidade do teu trabalho, as tuas reações e o que aprendes. Quando confrontado com a incerteza, analise o problema e encontre ações específicas que possa tomar. Não se trata de aceitação passiva, trata-se de foco estratégico. A energia gasta em coisas que não podem ser mudadas é roubada do que podes mudar.

11. A abstração não elimina a complexidade, apenas a transfere

Cada abstração é uma aposta, apostando que não precisa de compreender os princípios subjacentes. Às vezes ganhas, mas a abstração acaba sempre por escapar. Quando falha, precisas de saber o que se passa por baixo. Os engenheiros seniores continuam a aprender conhecimento “de baixo para cima” mesmo à medida que a pilha tecnológica cresce cada vez mais. Isto não é por nostalgia, mas por respeito ao momento do fracasso abstrato.Usa a tua pilha de ferramentas, mas domina o modelo mental do seu modo de falha subjacente.

12. Escrever é compulsivo e claro, e ensinar é a forma mais rápida de aprender

Escrever obriga-te a pensar. Quando explico um conceito a outros — seja em documentação, discursos, comentários de revisão de código ou até mesmo a conversar com IA — encontro lacunas na minha compreensão.

O processo de tornar o conteúdo claro para os outros também o torna mais claro para mim. Não se trata apenas de partilhar conhecimento generosamente, trata-se deTécnicas de estudo egoístas。 Se achas que percebes algo, tenta explicar de forma simples. Onde ficas preso, é onde percebes superficialmente.O tutorial está a depurar o teu próprio modelo mental.

13. O trabalho que torna outros empregos possíveis é inestimável, mas invisível

O “trabalho de cola” – documentação, integração, coordenação entre equipas, melhoria de processos – é crucial. Mas se o fizeres sem pensar, pode prejudicar o teu crescimento técnico e esgotar-te. A armadilha é vê-la como “útil” em vez de comoContribuições conscientes, de limites, visíveis。 Limitar o tempo, rodar a execução, convertê-la em saída (documentos, templates, ferramentas de automação).

Que seja visto como influência, não como traço de personalidade.

14. Se ganhar todas as discussões, pode estar a acumular resistência silenciosa

Aprendi a duvidar da minha certeza. Quando “ganho” demasiado facilmente, normalmente algo corre mal. As pessoas deixam de argumentar não porque estejam convencidas por si mesmas, mas porque desistem de tentar — vão expressar essa objeção na execução, não em reuniões. O alinhamento verdadeiro demora mais tempo.

Tens de realmente compreender as perspetivas dos outros, incorporar feedback e, por vezes, até mudar de opinião abertamente. A emoção de ganhar uma discussão a curto prazo é muito menos valiosa do que trabalhar com um parceiro que está feliz e convencido durante muito tempo.

15. Quando um indicador se torna um objetivo, deixa de ser um bom indicador

Cada métrica que mostrar à gestão acabará por ser “manipulada”. Isto não se deve a malícia, mas sim ao facto de os humanos otimizarem para o que é medido (lei de Goodhardt). Se acompanhares linhas de código, vais obter mais linhas. Se acompanhares a taxa, obténs uma estimativa da inflação.

Abordagem comprovada: Forneça um par de métricas para cada pedido de métrica. Um olha para a velocidade, o outro para a qualidade ou o risco. PersistênciaInterpretar tendências, não o limiar de adoração. O objetivo é a perceção, não a vigilância.

16. Admitir “não sei” cria mais uma sensação de segurança do que fingir compreender

Engenheiros seniores que dizem “Não sei” não mostram fraquezas, mas criam “permissões”. Quando um líder reconhece a incerteza, isso liberta um sinal de que a sala é segura para os outros também. Já vi equipas séniores que nunca admitem confusão, e isso dói muito: ninguém faz perguntas, assume que ninguém os desafia, e engenheiros juniores ficam calados porque acham que são os únicos que não percebem. Demonstre curiosidade e terá uma equipa que realmente aprenderá.

17. O teu contexto dura mais do que qualquer trabalho que já fizeste

No início da minha carreira, foquei-me no trabalho e negligenciei as minhas ligações. Olhando para trás, isto foi um erro. Colegas que investem em relações (dentro e fora da empresa) beneficiaram imenso durante décadas. São os primeiros a ouvir falar de oportunidades, a construir pontes mais rapidamente, a receber recomendações de emprego e a iniciar um negócio com pessoas em quem conquistou há anos de confiança. O trabalho não é para sempre, mas as ligações são. Constrói relações com curiosidade e generosidade em vez de uma mentalidade transacional.

18. A maioria dos ganhos de desempenho resulta de “remover trabalho” em vez de “algoritmos inteligentes”

Quando o sistema abranda, o instinto é aumentar: camada de cache, processamento paralelo, algoritmos mais inteligentes. Por vezes isso é verdade, mas já vi ganhos de desempenho mais ao perguntar: "**O que calculámos e não precisávamos?**Eliminar trabalho desnecessário é quase sempre mais impactante do que fazer o trabalho necessário mais rapidamente. O código mais rápido é aquele que nunca corre.

19. Existem processos para reduzir a incerteza, não para criar papelada

Os melhores processos facilitam a coordenação e reduzem o custo de falhas. O pior processo é um “drama burocrático” – não existe para ajudar, mas para fugir à responsabilidade quando algo acontece. Se não conseguir explicar como um processo reduz o risco ou aumenta a clareza, pode ser apenas um peso. Se as pessoas passam mais tempo a registar trabalho do que a fazê-lo, há um grande problema.

20. No fim, o tempo valerá mais do que o dinheiro, aja em conformidade

No início da carreira, trocas tempo por dinheiro, e isso está bem. Mas, a certa altura, o cálculo é invertido. Vai perceber que o tempo é um recurso não renovável. Já vi engenheiros seniores esgotados a tentar alcançar o próximo grau e otimizar esses poucos pontos percentuais de salário. Algumas pessoas compraram, mas a maioria depois duvidou se valia o preço que pagaram. A resposta não é “não trabalhes arduamente”, mas "Saiba o que está a negociar e negocie de forma consciente」。

21. Não há atalhos, mas existe um efeito de juros compostos

A especialização vem da prática deliberada — um pouco além do seu conjunto atual de competências, refletir, repetir, durante anos. Não existe uma versão reduzida. Mas a esperança está em:Quando aprender cria novas escolhas em vez de apenas conhecimento fragmentado, gera juros compostos. Escrever (para maior clareza), construir grupos reutilizáveis de Raw e recolher lições dolorosas num manual de jogadas. Os engenheiros que veem as suas carreiras como “juros compostos” em vez de “lotaria” costumam ir muito mais longe.

Um último pensamento

Estes 21 parecem muitos, mas na verdade só há algumas ideias centrais:Mantém a curiosidade, mantém-te humilde e lembra-te que o trabalho é sempre sobre pessoas- Incluindo os utilizadores para quem constrói produtos, bem como colegas de equipa que constroem produtos consigo.

Os engenheiros têm carreiras longas, suficientemente longas para cometer muitos erros e ainda assim ter sucesso. Os engenheiros que mais admiro não são aqueles que nunca cometem erros, mas sim aqueles que aprendem com eles, partilham as suas descobertas e perseveram.

Se está a começar esta jornada, saiba que vai ficar mais emocionante com o tempo. Se tens trabalhado nisto há anos, espero que alguns deles ressoem contigo.