Programação em par - A Amizade Que Tornou o Google Enorme

Certo dia, em março de 2000, seis dos melhores engenheiros do Google se reuniram em uma sala de guerra improvisada. A empresa estava em meio a uma emergência sem precedentes. Em outubro, seus sistemas principais, que rastreiam a Web para criar um “índice” dela, pararam de funcionar. Embora os usuários ainda pudessem fazer consultas em google.com, os resultados recebidos estavam cinco meses desatualizados. Mais coisa estava em jogo do que os engenheiros perceberam. Os cofundadores do Google, Larry Page e Sergey Brin, estavam negociando um acordo para fornecer um mecanismo de busca para o Yahoo, e eles prometeram fornecer um índice dez vezes maior do que o que tinham na época - um índice capaz de acompanhar a World Wide Web, que dobrou de tamanho no ano anterior. Se eles falhassem, o google.com continuaria sendo uma cápsula do tempo, o acordo com o Yahoo provavelmente entraria em colapso e a empresa correria o risco de queimar seu financiamento até o esquecimento.

Em uma sala de reuniões ao lado de uma escada, os engenheiros colocaram portas sobre cavaletes e instalaram seus computadores. Craig Silverstein, um jovem de 27 anos com um corpo pequeno e uma voz aguda, estava sentado na parede oposta. Silverstein foi o primeiro funcionário do Google: ele ingressou na empresa quando seus escritórios ficavam na sala de Brin e ele mesmo reescreveu grande parte do código. Depois de quatro dias e noites, ele e um engenheiro de sistemas romeno chamado Bogdan Cocosel não chegaram a lugar nenhum. “Nenhuma das análises que estávamos fazendo fazia sentido”, lembrou Silverstein. “Tudo estava quebrado e não sabíamos por quê.”

Silverstein mal havia registrado a presença, por cima do ombro esquerdo, de Sanjay Ghemawat, um homem quieto de 33 anos graduado no M.I.T. com sobrancelhas grossas e cabelos pretos grisalhos. Sanjay havia entrado na empresa apenas alguns meses antes, em dezembro. Ele havia seguido um colega dele — um homem de trinta e um anos esguio e enérgico chamado Jeff Dean — da Digital Equipment Corporation. Jeff havia deixado D.E.C. dez meses antes de Sanjay. Eles eram extraordinariamente próximos e preferiam escrever códigos em conjunto. Na sala de guerra, Jeff rolou a cadeira até a mesa de Sanjay, deixando a sua vazia. Sanjay trabalhava no teclado enquanto Jeff se reclinava ao lado dele, corrigindo e bajulando como um produtor no ouvido de um âncora de notícias.

Jeff e Sanjay começaram a examinar o índice parado. Eles descobriram que algumas palavras estavam faltando – eles pesquisavam por “caixa de correio” e não obtinham resultados – e que outras estavam listadas fora de ordem. Durante dias, eles procuraram falhas no código, mergulhando em sua lógica. Seção por seção, tudo verificado. Eles não conseguiram encontrar o bug.

Às vezes, os programadores conceituam seu software como uma estrutura de camadas que vão desde a interface do usuário, no topo, até os estratos cada vez mais fundamentais. Aventurar-se no fundo dessa estrutura, onde o software encontra o hardware, é afastar-se da ordem platônica do código e se aproximar do universo elementar da eletricidade e do silício do qual depende. No quinto dia na sala de guerra, Jeff e Sanjay começaram a suspeitar que o problema que procuravam não era lógico, mas físico. Eles converteram o arquivo de índice confuso em sua forma mais bruta de representação: código binário. Eles queriam ver o que suas máquinas estavam vendo.

No monitor de Sanjay, uma coluna grossa de 1s e 0s apareceu, cada linha representando uma palavra indexada. Sanjay apontou: um dígito que deveria ser um 0 era um 1. Quando Jeff e Sanjay juntaram todas as palavras mal ordenadas, eles viram um padrão - o mesmo tipo de falha em cada palavra. Os chips de memória de suas máquinas foram corrompidos de alguma forma.

Sanjay olhou para Jeff. Durante meses, o Google experimentou um número crescente de falhas de hardware. O problema era que, à medida que o Google crescia, sua infraestrutura de computação também se expandia. O hardware do computador raramente falhava, até que você tivesse o suficiente - então falhava o tempo todo. Fios desgastados, discos rígidos quebrados, placas-mãe superaquecidas. Muitas máquinas nunca funcionaram em primeiro lugar; algumas ficariam inexplicavelmente mais devagar. Fatores ambientais estranhos entraram em jogo. Quando uma supernova explode, a onda de explosão cria partículas de alta energia que se espalham em todas as direções; os cientistas acreditam que há uma pequena chance de que uma das partículas errantes, conhecidas como raios cósmicos, possa atingir um chip de computador na Terra, transformando um 0 em um 1. Os sistemas de computador mais robustos do mundo, na Nasa, empresas financeiras e o como, hardware especial usado que poderia tolerar bit-flips únicos. Mas o Google, que ainda funcionava como uma startup, comprou computadores mais baratos que não tinham esse recurso. A empresa havia chegado a um ponto de inflexão. Seu cluster de computação havia crescido tanto que até falhas improváveis de hardware eram inevitáveis.

Juntos, Jeff e Sanjay escreveram códigos para compensar as máquinas ofensivas. Pouco depois, o novo índice foi concluído e a sala de guerra dissolvida. Silverstein estava confuso. Ele era um bom depurador; a chave para encontrar bugs era chegar ao fundo das coisas. Jeff e Sanjay foram mais fundo.

Até o desastre do índice de março, os sistemas do Google estavam enraizados no código que seus fundadores escreveram na pós-graduação, em Stanford. Page e Brin não eram engenheiros de software profissionais. Eles eram acadêmicos conduzindo um experimento em tecnologia de busca. Quando o rastreador da Web caiu, não houve nenhuma mensagem informativa de diagnóstico - apenas a frase "Uau, cavalinho!" Os primeiros funcionários se referiam ao BigFiles, um software que Page e Brin escreveram, como BugFiles. Seu importantíssimo código de indexação levava dias para ser concluído e, se encontrasse algum problema, tinha de recomeçar desde o início. No jargão do Vale do Silício, o Google não era “escalável”.

Dizemos que “pesquisamos na Web”, mas não o fazemos, na verdade; nossos mecanismos de busca percorrem um índice da Web — um mapa. Quando o Google ainda se chamava BackRub, em 1996, seu mapa era pequeno o suficiente para caber nos computadores instalados no dormitório de Page. Em março de 2000, não havia supercomputador grande o suficiente para processá-lo. A única maneira de o Google conseguir acompanhar era comprando máquinas de consumo e conectando-as em uma frota. Como metade do custo desses computadores estava em peças que o Google considerava inúteis - unidades de disquete, chassis de metal -, a empresa encomendava placas-mãe e discos rígidos originais e os unia. O Google tinha mil e quinhentos desses dispositivos empilhados em torres de quase dois metros de altura, em um prédio em Santa Clara, Califórnia; por causa de falhas de hardware, apenas mil e duzentos funcionaram. Falhas, que ocorreram aparentemente ao acaso, continuaram quebrando o sistema. Para sobreviver, o Google teria de unir seus computadores em um todo contínuo e resiliente.

Lado a lado, Jeff e Sanjay se encarregaram desse esforço. Wayne Rosing, que havia trabalhado na Apple no precursor do Macintosh, ingressou no Google em novembro de 2000 para comandar sua equipe de engenharia de cem pessoas. “Eles eram os líderes”, disse ele. Trabalhando noventa horas por semana, eles escreveram códigos para que um único disco rígido pudesse falhar sem derrubar todo o sistema. Eles adicionaram pontos de verificação ao processo de rastreamento para que ele pudesse ser reiniciado no meio do caminho. Ao desenvolver novos esquemas de codificação e compressão, eles efetivamente dobraram a capacidade do sistema. Eles eram otimizadores implacáveis. Quando um carro faz uma curva, mais terreno deve ser percorrido pelas rodas externas; da mesma forma, a borda externa de um disco rígido giratório se move mais rapidamente do que a interna. O Google moveu os dados acessados com mais frequência para o exterior, para que os bits pudessem fluir mais rapidamente sob o cabeçote de leitura, mas deixou a metade interna vazia; Jeff e Sanjay usaram o espaço para armazenar dados pré-processados para consultas de pesquisa comuns. Durante quatro dias em 2001, eles provaram que o índice do Google poderia ser armazenado usando memória rápida de acesso aleatório em vez de discos rígidos relativamente lentos; a descoberta reformulou a economia da empresa. Page e Brin sabiam que os usuários iriam migrar para um serviço que entregasse respostas instantaneamente. O problema era que a velocidade exigia poder de computação, e o poder de computação custava dinheiro. Jeff e Sanjay enfiaram a agulha com software.

Alan Eustace tornou-se o chefe da equipe de engenharia após a saída de Rosing, em 2005. “Para resolver problemas em escala, paradoxalmente, é preciso conhecer os mínimos detalhes”, disse Eustace. Jeff e Sanjay entendiam os computadores no nível dos bits. Certa vez, Jeff circulou uma lista de “números de latência que todo programador deveria saber”. Na verdade, é uma lista de números que quase nenhum programador conhece: que uma referência de cache L1 geralmente leva meio nanossegundo, ou que ler um megabyte sequencialmente da memória leva duzentos e cinquenta microssegundos. Esses números estão programados nos cérebros de Jeff e Sanjay. Como eles ajudaram a liderar várias reescritas do software principal do Google, a capacidade do sistema aumentou em ordens de magnitude. Enquanto isso, nos vastos data centers da empresa, os técnicos agora caminhavam em rotas sinuosas, seguindo instruções geradas por software para substituir discos rígidos, fontes de alimentação e cartões de memória. Mesmo quando suas peças se desgastaram e morreram, o sistema prosperou.

Hoje, os engenheiros do Google existem em uma "Grande Cadeia do Ser" que começa no Nível 1. Na parte inferior estão os departamentos de TI. equipe de suporte. Os alunos do nível 2 são recém-saídos da faculdade; Os nível 3 geralmente têm mestrado. Chegar ao nível 4 leva vários anos, ou um Ph.D. A maior parte da progressão para no nível 5. Os engenheiros de nível 6 - os dez por cento melhores - são tão capazes que podem ser considerados a razão do sucesso de um projeto; Nível 7 são Nível 6 com um longo histórico. Os Engenheiros Principais, os de Nível 8, estão associados a um produto importante ou peça de infraestrutura. Distinguished Engineers, os Level 9s, são mencionados com reverência. Tornar-se um Google Fellow, nível 10, é ganhar uma honra que o acompanhará por toda a vida. Os Google Fellows geralmente são os maiores especialistas do mundo em suas áreas. Jeff e Sanjay são Google Senior Fellows — os primeiros e únicos nível 11 da empresa.

O campus do Google, situado ao lado de uma rodovia a poucos minutos do centro de Mountain View, é uma série de prédios baixos e pouco atraentes com janelas escuras. Em uma segunda-feira no verão passado, depois de uma manhã programando juntos, Jeff e Sanjay foram almoçar em uma lanchonete do campus chamada Big Table, cujo nome vem de um sistema que eles ajudaram a desenvolver, em 2005, por tratar inúmeros computadores como se fossem um banco de dados único. Sanjay, que é alto e magro, usava um velho Henley marrom, calça cinza e pequenos óculos de armação de arame. Ele espiou uma mesa do lado de fora e caminhou rapidamente para reclamá-la, abrindo o guarda-chuva e sentando-se à sombra. Ele moveu outra cadeira para o sol para Jeff, que chegou um minuto depois, ombros largos em uma camisa de manga curta e tênis elegantes.

Como um casal, Jeff e Sanjay contam histórias juntos, contribuindo com partes do quadro total. Eles começaram a relembrar seus primeiros projetos.

“Estávamos escrevendo as coisas à mão”, disse Sanjay. Seus óculos escureceram com o sol. “Nós reescrevemos e foi tipo, 'Oh, isso parece próximo do que escrevemos no mês passado.'”

“Ou uma passagem ligeiramente diferente em nossos dados de indexação”, acrescentou Jeff.

“Ou um pouco diferente”, disse Sanjay. “E é assim que descobrimos—”

"Esta é a essência", disse Jeff.

“—este é o padrão comum”, disse Sanjay, concluindo o pensamento.

Jeff deu uma mordida na pizza que pegou. Ele tem os dedos de um marinheiro, nodosos e duros; Sanjay, que parece quase delicado em comparação, se perguntou como eles acabaram como um par. “Não sei bem como decidimos que seria melhor”, disse ele.

“Fazemos isso desde antes do Google”, disse Jeff.

“Mas não sei por que decidimos que era melhor fazer isso na frente de um computador em vez de dois”, disse Sanjay.

“Eu andaria do meu D.E.C. laboratório de pesquisa a dois quarteirões de seu D.E.C. laboratório de pesquisa — disse Jeff. “Havia uma sorveteria no meio.”

“Então é a sorveteria!” Sanjay disse, encantado.

Sanjay, que é solteiro, junta-se a Jeff, suas duas filhas e sua esposa, Heidi, nas férias. As filhas de Jeff o chamam de tio Sanjay, e as cinco costumam jantar às sextas-feiras. Sanjay e Victoria, a mais velha de Jeff, começaram a cozinhar. “Eu vi as filhas dele crescerem”, disse Sanjay com orgulho. Após o I.P.O. do Google, em 2004, eles se mudaram para casas distantes seis quilômetros uma da outra. Sanjay mora em um modesto apartamento de três quartos em Old Mountain View; Jeff projetou sua casa, perto do centro de Palo Alto, ele mesmo, instalando um trampolim no porão. Enquanto trabalhava na casa, ele descobriu que, embora gostasse de projetar espaços, não tinha paciência para o que chama de “aspectos orientados para Sanjay” da arquitetura: os detalhes de vigas, parafusos e cargas que impedem o grande projeto de caindo aos pedaços.

“Não sei por que mais pessoas não fazem isso”, disse Sanjay, sobre programar com um parceiro.

“Você precisa encontrar alguém com quem vai programar em dupla e que seja compatível com sua maneira de pensar, para que vocês dois sejam uma força complementar”, disse Jeff.

Eles se afastaram da mesa e partiram em busca de um saque suave, passeando pela Big Table e seus googlers à deriva. Dos dois, Jeff está mais ansioso para expor e, enquanto caminhavam, ele compartilhou sua estratégia de saque suave. “Eu faço o squish. Acho que a abordagem de flexão adiciona estabilidade ”, disse ele. Sanjay, satisfeito e concentrado, colocou uma mistura de chocolate e baunilha em sua casquinha.

Em seu livro “Collaborative Circles: Friendship Dynamics and Creative Work”, de 2001, o sociólogo Michael P. Farrell fez um estudo de grupos criativos próximos – os impressionistas franceses, Sigmund Freud e seus contemporâneos. “A maioria das ideias frágeis que lançaram as bases de uma nova visão surgiu não quando todo o grupo estava junto, e não quando os membros trabalhavam sozinhos, mas quando eles colaboraram e responderam uns aos outros em pares”, escreveu ele. Foi preciso Monet e Renoir, trabalhando lado a lado no verão de 1869, para desenvolver o estilo que se tornou o impressionismo; durante a colaboração de seis anos que deu origem ao cubismo, Pablo Picasso e Georges Braque costumavam assinar apenas o verso de suas telas, para ocultar qual deles havia concluído cada pintura. (“Uma tela não estava terminada até que nós dois sentíssemos que estava”, relembrou Picasso mais tarde.) Em “Poderes de Dois: Encontrando a Essência da Inovação em Pares Criativos”, o escritor Joshua Wolf Shenk cita uma entrevista de 1971 na qual John Lennon explicou que ele ou Paul McCartney iria "escrever a parte boa, a parte fácil, como 'eu li as notícias hoje' ou o que quer que fosse." Um deles ficaria preso até que o outro chegasse - então, disse Lennon, "eu cantaria a metade e ele seria inspirado a escrever a próxima parte e vice-versa". Todo mundo cai em rotinas criativas, mas duas pessoas raramente o fazem ao mesmo tempo.

Na fase de “construção de teoria” de uma nova ciência ou arte, é importante explorar amplamente sem cair em becos sem saída. François Jacob, que, com Jacques Monod, foi pioneiro no estudo da regulação de genes, observou que, em meados do século XX, a maior parte da pesquisa no crescente campo da biologia molecular era resultado de duplas. “Dois são melhores do que um para inventar teorias e construir modelos”, escreveu Jacob. “Pois com duas mentes trabalhando em um problema, as ideias voam mais densas e mais rápidas. Eles são saltados de parceiro para parceiro. Eles são enxertados uns nos outros, como galhos de uma árvore. E no processo, as ilusões são cortadas pela raiz. Nos últimos 35 anos, cerca de metade dos Prêmios Nobel de Fisiologia ou Medicina foram para parcerias científicas.

Depois de anos compartilhando suas vidas profissionais, as duplas às vezes desenvolvem uma linguagem particular, como os gêmeos. Eles imitam as roupas e os hábitos uns dos outros. Um senso de humor osmose de um para o outro. A repartição do crédito entre eles torna-se impossível. Mas parcerias dessa intensidade são incomuns no desenvolvimento de software. Embora os desenvolvedores às vezes falam sobre “programação em par” – dois programadores compartilhando um único computador, um “dirigindo” e o outro “navegando” – eles geralmente concebem essas parcerias em termos de redundância, como se o par fosse co-piloto no mesmo voo. Jeff e Sanjay, ao contrário, às vezes parecem ser duas metades de uma única mente. Alguns de seus trabalhos mais conhecidos têm até uma dúzia de coautores. Ainda assim, Bill Coughran, um de seus gerentes, lembrou: “Eles eram tão prolíficos e tão eficazes trabalhando como um par que muitas vezes construímos equipes em torno deles”.

Em 1966, pesquisadores da System Development Corporation descobriram que os melhores programadores eram mais de dez vezes mais eficazes do que os piores. A existência do chamado “programador 10x” tem sido controversa desde então. A ideia venera o indivíduo, quando os projetos de software costumam ser vastos e coletivos. Na programação, poucas conquistas existem isoladamente. Mesmo assim - e talvez ironicamente - muitos programadores veem o trabalho feito por Jeff e Sanjay, juntos, como prova de que o programador 10x existe.

Jeff nasceu no Havaí, em julho de 1968. Seu pai, Andy, era um pesquisador de doenças tropicais; sua mãe, Virginia Lee, era uma médica antropóloga que falava meia dúzia de idiomas. Para se divertir, pai e filho programaram um computador kit IMSAI 8080. Eles fizeram atualizações na máquina, aprendendo cada parte dela.

Jeff e seus pais se mudavam com frequência. Aos treze anos, ele pulou os últimos três meses da oitava série para ajudá-los em um campo de refugiados no oeste da Somália. Mais tarde, no ensino médio, ele começou a escrever um programa de coleta de dados para epidemiologistas chamado Epi Info; tornou-se uma ferramenta padrão para o trabalho de campo e, eventualmente, centenas de milhares de cópias foram distribuídas, em mais de uma dúzia de idiomas. (Um site mantido pelos Centros de Controle e Prevenção de Doenças, “The Epi Info Story”, inclui uma foto de Jeff em sua formatura do ensino médio.) Heidi, que Jeff conheceu na faculdade, na Universidade de Minnesota, soube da importância do programa apenas anos depois. “Ele não se gabava de nada disso”, disse ela. “Você teve que arrancar isso dele.” O primeiro encontro deles foi em um jogo de basquete feminino; Jeff estava com uma fantasia de esquilo, líder de torcida.

Ph.D. de Jeff focado em compiladores, o software que transforma código escrito por pessoas em instruções de linguagem de máquina otimizadas para computadores. “Em termos de sensualidade, os compiladores são muito chatos”, disse Alan Eustace; por outro lado, eles o colocam “muito perto da máquina”. Descrevendo Jeff, Sanjay girou o dedo indicador na têmpora. “Ele tem um modelo em andamento enquanto você escreve o código”, disse ele. “'Qual será o desempenho deste código?' Ele pensará em todos os casos de canto quase de forma semiautomática.”

Sanjay não tocou em um computador até ir para Cornell, aos dezessete anos. Ele nasceu em West Lafayette, Indiana, em 1966, mas cresceu em Kota, uma cidade industrial no norte da Índia. Seu pai, Mahipal, era professor de botânica; sua mãe, Shanta, cuidou de Sanjay e de seus dois irmãos mais velhos. Eles eram uma família estudiosa: seu tio, Ashok Mehta, lembra-se de ter comprado um exemplar de “O Dia do Chacal”, de Frederick Forsyth, com a encadernação muito gasta, e de ter visto as crianças Ghemawat lerem juntas o livro quebrado, passando as páginas enquanto passavam. finalizado. O irmão de Sanjay, Pankaj, tornou-se o membro mais jovem do corpo docente já premiado com a Harvard Business School. (Ele agora é professor na NYU Stern.) Pankaj estudou na mesma escola que Sanjay e tinha a reputação de homem da Renascença. “Eu meio que vivi na sombra do meu irmão”, disse Sanjay. Quando adulto, ele mantém um talento para a auto-aprimoramento. Em 2016, quando foi introduzido na Academia Americana de Artes e Ciências, ele não contou aos pais; seu vizinho teve que lhes dar a notícia.

Na pós-graduação, no M.I.T., Sanjay encontrou um grupo muito unido de amigos. Ainda assim, ele nunca namorou e o faz apenas “muito, muito raramente” agora. Ele diz que não decidiu não ter uma família - apenas se desenrolou dessa maneira. Seus amigos íntimos aprenderam a não incomodá-lo com isso, e seus pais há muito aceitaram que seu filho seria solteiro. Talvez por ser tão reservado, um ar de mistério o envolve no Google. Ele é conhecido por ser quieto, mas profundo - alguém que pensa profundamente e com uma clareza incomum. Em sua escrivaninha, ele mantém uma pilha de cadernos de composição de Mead que remontam a quase vinte anos, cheios de listas e diagramas organizados. Ele escreve a caneta e em letra cursiva. Ele raramente faz referência a um caderno antigo, mas escreve para pensar. No M.I.T., seu orientador graduado foi Barbara Liskov, uma influente cientista da computação que estudou, entre outras coisas, o gerenciamento de bases de código complexas. Na visão dela, o melhor código é como um bom texto. Precisa de uma estrutura cuidadosamente realizada; cada palavra deve funcionar. Programar desta forma requer empatia com os leitores. Também significa ver o código não apenas como um meio para um fim, mas como um artefato em si. “Acho que ele é melhor em projetar sistemas”, disse Craig Silverstein. “Se você está apenas olhando para um arquivo de código que Sanjay escreveu, é lindo da mesma forma que uma escultura bem proporcionada é linda.”

No Google, Jeff é muito mais conhecido. Existem memes de Jeff Dean, inspirados nos de Chuck Norris. (“Chuck Norris contou até o infinito... duas vezes”; “O currículo de Jeff Dean lista as coisas que ele não fez — é mais curto assim.”) Mas, para quem conhece os dois, Sanjay tem o mesmo talento. “Jeff é ótimo em apresentar novas ideias e fazer protótipos de coisas”, disse Wilson Hsieh, seu colega de longa data. “Sanjay foi quem construiu coisas para durar.” Na vida, Jeff é mais extrovertido, Sanjay mais introvertido. No código, é o inverso. A programação de Jeff é deslumbrante - ele pode esboçar rapidamente ideias surpreendentes - mas, como é feito rapidamente, com espírito de descoberta, pode deixar os leitores para trás. O código de Sanjay é social.

“Algumas pessoas”, disse Silverstein, “seu código é muito vago. Uma tela de código tem muito pouca informação. Você está sempre rolando para frente e para trás para descobrir o que está acontecendo.” Outros escrevem códigos muito densos: “Você olha para isso e fica tipo, ‘Ugh. Não estou ansioso para ler isso.' Sanjay de alguma forma se dividiu no meio. Você olha para o código dele e pensa: 'OK, posso descobrir isso' e, ainda assim, você obtém muito em uma única página. Silverstein continuou: “Sempre que quero adicionar uma nova funcionalidade ao código de Sanjay, parece que os ganchos já estão lá. Eu me sinto como Salieri. Eu entendo a grandeza. Eu não entendo como isso é feito.”

Em uma segunda-feira de manhã nesta primavera, Jeff e Sanjay estavam na cozinha do Edifício 40, que abriga grande parte da divisão de inteligência artificial do Google. Atrás deles, um quadro branco estava cheio de álgebra matricial; um artigo sobre redes adversárias não supervisionadas estava sobre uma mesa. Jeff, vestindo uma camiseta desbotada e jeans, parecia um vagabundo de praia reformado; Sanjay usava um suéter e calça cinza. As janelas iluminadas revelavam um grupo de pinheiros altos e, além dele, um campo. Onde quer que Jeff trabalhe no Google, as máquinas de café expresso o seguem. No balcão da cozinha, um La Marzocco de um metro de largura zumbia. “Estamos atrasados”, disse Sanjay, sobre um moedor de café. Eram oito e trinta e dois.

Depois dos cappuccinos, eles caminharam até seus computadores. Jeff empurrou uma cadeira de sua própria mesa, que estava bagunçada, para a de Sanjay, que estava impecável. Ele apoiou um pé em um arquivo, recostando-se, enquanto Sanjay examinava a tela à sua frente. Havia quatro janelas abertas: à esquerda, um navegador da Web e um terminal, para rodar ferramentas de análise; à direita, dois documentos no editor de texto Emacs, um uma combinação de lista de tarefas e caderno, o outro preenchido com código colorido. Um dos cadernos de redação de Sanjay estava ao lado do computador.

"Tudo bem, o que estávamos fazendo?" Sanjay perguntou.

“Acho que estávamos analisando os tamanhos de código do TensorFlow Lite”, disse Jeff.

Este era um novo projeto de software importante relacionado ao aprendizado de máquina, e Jeff e Sanjay estavam preocupados com o fato de estar inchado; como editores de livros, eles estavam procurando cortes. Para essa tarefa, eles construíram uma nova ferramenta que precisava ser otimizada.

“Então, eu estava tentando descobrir o quão lento é”, disse Sanjay.

"É muito lento", disse Jeff. Ele se inclinou para frente, ainda relaxado.

“Então aquele tinha cento e vinte kilobytes”, disse Sanjay, “e era, tipo, oito segundos.”

“Cento e vinte mil chamadas de pilha”, disse Jeff, “não kilobytes.”

"Bem, kilobytes de texto, sim - sobre", disse Sanjay.

"Oh, sim, desculpe", disse Jeff.

“Não sei bem qual limite devemos escolher para o tamanho de uma unidade”, disse Sanjay. “Meio meg?”

"Parece bom", disse Jeff. Sanjay começou a digitar e Jeff foi atraído para a tela. “Então você está apenas dizendo, se for maior do que isso, vamos apenas mostrar. . .” Ele deixou o resto por dizer; Sanjay respondeu em código.

Quando Sanjay dirige, ele coloca as mãos em dez e dois e olha atentamente para a frente. Ele é da mesma forma no teclado. Com os pés afastados na largura dos ombros, ele parecia estar trabalhando em sua postura. Seus dedos finos moviam-se suavemente pelas teclas. Alguns programadores mais jovens começaram a aparecer.

Logo eles atingiram um marco menor e Sanjay digitou um comando para testar seu progresso. Parecendo exausto, ele checou seu e-mail enquanto executava. O teste terminou. Ele não percebeu.

"Ei", disse Jeff. Ele estalou os dedos e apontou para a tela. Embora nas conversas ele ouça piadas e trocadilhos com o pai, ele pode se tornar obstinado, brusco e desaprovador quando se senta em um computador com Sanjay. Sanjay leva isso na esportiva. Quando ele acha que Jeff está indo rápido demais, ele levanta as mãos do teclado e abre os dedos, como se dissesse: “Pare”. (Em geral, Jeff é o acelerador, Sanjay o freio.) Isso é o mais próximo que eles chegam de uma discussão: em vinte anos juntos, eles não conseguem se lembrar de levantar a voz.

Sanjay rolou a tela, exibindo uma nova seção de código. “Tipo, tudo isso pode virar rotina, não é?” Jeff disse.

“Mmm,” Sanjay concordou.

Jeff estalou os dedos. “Parece factível. Devemos fazer isso?

Sanjay estava cauteloso. “Não, eu—”

“Então vamos ignorar um problema?” Jeff disse indignado.

“Não, quero dizer, estamos apenas tentando ter uma ideia dos tipos de coisas que estão acontecendo. Então poderíamos fazer anotações sobre isso, certo?

"O.K.", Jeff disse alegremente, seu humor mudou. Eles ditaram uma nota juntos.

A hora do almoço se aproximava. Eles trabalharam por duas horas com um intervalo de dez minutos, conversando a maior parte do tempo. (Um programador menos experiente que os observasse ficaria impressionado, mais do que qualquer outra coisa, pelo fato de eles nunca pararem ou travarem.) É uma prática de engenharia padrão ter seu código revisado por outro codificador, mas Jeff e Sanjay pulam esta etapa, inserindo , em seu registro, um “lgtm” superficial, para “parece bom para mim”. Em certo sentido, eles foram ocupados por minúcias. Seu código, no entanto, é executado na escala do Google. Os kilobits e microssegundos com os quais eles se preocupam são multiplicados em até um bilhão em data centers em todo o mundo – prédios barulhentos, quentes, do tamanho de armazéns cujos intermináveis racks de processadores são resfriados por tanques de água. Em dias como esse, Jeff costuma chegar em casa e dizer às filhas: “Sanjay e eu aceleramos a Pesquisa do Google em dez por cento hoje”.

Jeff e Sanjay deram ao Google o que provavelmente foi sua maior atualização única ao longo de quatro meses em 2003. Eles fizeram isso com um software chamado MapReduce. A ideia surgiu na terceira vez que eles reescreveram o rastreador e o indexador do Google. Ocorreu-lhes que, a cada vez, eles haviam resolvido um problema importante: coordenar o trabalho em um grande número de computadores geograficamente distribuídos e individualmente não confiáveis. Generalizar sua solução significaria que eles poderiam evitar revisitar o problema repetidas vezes. Mas também criaria uma ferramenta que qualquer programador do Google poderia usar para manejar as máquinas em seus centros de dados como se fossem um único computador do tamanho de um planeta.

O MapReduce, que Jeff e Sanjay escreveram em um escritório de canto com vista para um lago com patos, impôs ordem a um processo que poderia ser incrivelmente complicado. Antes do MapReduce, cada programador tinha que descobrir como dividir e distribuir dados, atribuir trabalho e contabilizar falhas de hardware por conta própria. O MapReduce deu aos codificadores uma maneira estruturada de pensar sobre esses problemas. Assim como um chef mantém o mise en place — preparando os ingredientes antes de combiná-los —, o MapReduce pede aos programadores que dividam suas tarefas em dois estágios. Primeiro, um codificador diz a cada máquina como fazer o estágio de “mapa” de uma tarefa (digamos, contar quantas vezes uma palavra aparece em uma página da Web); em seguida, ela escreve instruções para “reduzir” todos os resultados das máquinas (por exemplo, somando-os). O MapReduce lida com os detalhes da distribuição e, ao fazer isso, os oculta.

No ano seguinte, Jeff e Sanjay reescreveram o sistema de rastreamento e indexação do Google em termos de tarefas MapReduce. Logo, quando outros engenheiros perceberam o quão poderoso era, começaram a usar o MapReduce para processar videos e renderizar os blocos no Google Maps. O MapReduce era tão simples que novas tarefas continuavam sugerindo a si mesmas. O Google tem o que é conhecido como “curva de uso diurno” – há mais tráfego durante o dia do que à noite – e as tarefas do MapReduce começaram a absorver a capacidade ociosa. Um cérebro sonhador processa suas experiências diurnas. Agora o Google processava seus dados.

Havia indícios, desde o início, de que o Google era uma I.A. empresa fingindo ser uma empresa de pesquisa. Em 2001, Noam Shazeer, que dividia um escritório com Jeff e Sanjay, ficou frustrado com o corretor ortográfico que o Google estava licenciando de outra empresa: ele continuava cometendo erros embaraçosos, como dizer aos usuários que digitaram “TurboTax” que eles provavelmente queriam dizer "turbot ax". (Um turbot é um peixe chato que vive no Atlântico Norte.) Um corretor ortográfico é tão bom quanto seu dicionário, e Shazeer percebeu que, na Web, o Google tinha acesso ao maior dicionário que já existiu. Ele escreveu um programa que usava as propriedades estatísticas do texto na Web para determinar quais palavras provavelmente continham erros ortográficos. O software descobriu que “pritany spears” e “brinsley spears” significava “Britney Spears”. Quando Shazeer demonstrou o programa no T.G.I.F. reunindo, os funcionários tentaram, mas falharam, enganá-lo. Em colaboração com Jeff e um engenheiro chamado Georges Harik, Shazeer aplicou técnicas semelhantes para associar anúncios a páginas da Web. A segmentação de anúncios tornou-se um rio de dinheiro que a empresa direcionou de volta para sua infraestrutura de computação. Era o início de um ciclo de feedback – a grandeza seria a fonte da inteligência do Google; inteligência a fonte de sua riqueza; e a riqueza a fonte de seu crescimento - isso tornaria a empresa extraordinariamente e perturbadoramente dominante.

Como os codificadores empreendedores usaram o MapReduce para obter insights dos dados do Google, tornou-se possível transcrever as mensagens de voz dos usuários, responder suas perguntas, preencher automaticamente suas consultas e traduzir entre mais de cem idiomas. Tais sistemas foram desenvolvidos usando algoritmos de aprendizado de máquina relativamente simples. Ainda assim, “técnicas muito simples, quando você tem muitos dados, funcionam incrivelmente bem”, disse Jeff. Como “dados, dados, dados”—armazenados e processados com BigTable, MapReduce e seus sucessores—tornaram-se a principal diretriz da empresa, a infraestrutura global do Google tornou-se mais integrada e flexível. A ideia de computação distribuída era antiga; conceitos como “computação em nuvem” e “big data” são anteriores à ascensão do Google. Mas, ao tornar intelectualmente gerenciável para codificadores comuns escrever programas distribuídos, Jeff e Sanjay deram ao Google um novo nível de domínio sobre essas tecnologias. Os usuários podem ter percebido que algo mudou: a nuvem do Google estava ficando mais inteligente.

Em 2004, porque Jeff e Sanjay pensaram que seria útil para astrônomos, geneticistas e outros cientistas com muitos dados para processar, eles escreveram um artigo, “MapReduce: Simplified Data Processing on Large Clusters”, e o tornaram público. O papel MapReduce chegou como um deus ex machina. O hardware barato e o crescimento dos serviços da Web e dos dispositivos conectados levaram a uma enxurrada de dados, mas poucas empresas tinham o software para processar as informações. Dois engenheiros que lutavam para escalar um pequeno mecanismo de busca chamado Nutch - Mike Cafarella e Doug Cutting - estavam tão convencidos da importância do MapReduce que decidiram construir um clone gratuito do sistema a partir do zero. Eles acabaram chamando seu projeto de Hadoop, em homenagem a um elefante de pelúcia amado pelo filho de Cutting. Com o amadurecimento do Hadoop, ele foi adotado por metade das empresas da Fortune 50. Tornou-se sinônimo de “Big Data”. O Facebook usou o “Hadoop MapReduce”, como é frequentemente conhecido, para armazenar e processar metadados do usuário – informações sobre o que foi clicado, o que foi curtido e quais anúncios foram visualizados. A certa altura, ele tinha o maior cluster Hadoop do mundo. O Hadoop MapReduce ajudou a fortalecer o LinkedIn e o Netflix. Randy Garrett, ex-diretor de tecnologia da Agência de Segurança Nacional, lembra-se de ter demonstrado a tecnologia ao diretor da agência, general Keith Alexander. O Hadoop executou uma tarefa de análise dezoito mil vezes mais rápido do que o sistema anterior. Tornou-se a base para uma nova abordagem de coleta de informações que alguns observadores chamam de “coletar tudo”.

Jeff tem uma natureza inquieta: um problema torna-se menos interessante para ele quando consegue ver a forma de sua solução. Em 2011, quando o mundo abraçou a nuvem, ele começou a colaborar com Andrew Ng, um professor de ciência da computação de Stanford que liderava um projeto secreto no Google para conduzir pesquisas sobre redes neurais – programas de software compostos de “neurônios” virtuais. Jeff havia encontrado redes neurais durante seus dias de graduação; naquela época, eles não tinham sido capazes de resolver problemas do mundo real. Ng disse a Jeff que isso estava mudando. Em Stanford, os pesquisadores alcançaram alguns resultados empolgantes quando as redes tiveram acesso a grandes quantidades de dados. Com a escala do Google, pensou Ng, as redes neurais poderiam se tornar não apenas úteis, mas também poderosas.

As redes neurais são profundamente diferentes dos programas de computador tradicionais. Seu comportamento não é especificado pelos codificadores da maneira usual; em vez disso, é “aprendido” usando entradas e feedback. O conhecimento de redes neurais de Jeff não havia avançado muito desde seus anos de graduação, e Heidi observou o banheiro deles se encher de livros didáticos. Jeff começou a dedicar cerca de um dia por semana ao projeto, que se chamava “Google Brain”. Muitos no Google duvidavam da tecnologia. “Que desperdício de talento”, Alan Eustace, seu empresário na época, lembra-se de ter pensado. Sanjay também não conseguiu entender o movimento de Jeff. “Você trabalha em infraestrutura”, pensou. "O que você está fazendo lá?"

Durante os sete anos seguintes, a equipe do Google Brain desenvolveu redes neurais que superaram o estado da arte em tradução automática e reconhecimento de fala e imagem. Por fim, eles substituíram os algoritmos mais importantes do Google para classificar resultados de pesquisa e segmentar anúncios, e o Google Brain se tornou uma das equipes de crescimento mais rápido da empresa. Claire Cui, uma engenheira que começou em 2001, disse que o envolvimento de Jeff marcou um ponto de virada para a IA. no Google: “Havia pessoas que acreditavam nisso e pessoas que não acreditavam. Jeff provou que pode funcionar.”

A.I. acabou por depender de escala, que Jeff, o engenheiro de sistemas, entregou. Como parte do esforço, ele liderou o desenvolvimento de um programa chamado TensorFlow – uma tentativa de criar algo como o MapReduce da I.A. O TensorFlow simplificou a tarefa de distribuir uma rede neural por uma frota de computadores, transformando-os em um grande cérebro. Em 2015, quando o TensorFlow foi lançado ao público, tornou-se a língua franca da IA. Recentemente, Sundar Pichai, C.E.O. do Google, declarou-o um “A.I. first” e fez de Jeff o chefe de sua I.A. iniciativas.

Jeff agora passa quatro dias por semana executando o Google Brain. Ele dirige o trabalho de três mil pessoas. Ele viaja para dar palestras, realiza uma reunião semanal para trabalhar em um novo chip de computador (a Tensor Processing Unit, projetada especificamente para redes neurais) e está ajudando no desenvolvimento do AutoML, um sistema que usa redes neurais para projetar outras redes neurais. . Ele tem tempo para programar com Sanjay apenas uma vez por semana.

Proezas de engenharia tendem a se apagar. Lembramo-nos dos grandes exploradores do século XVIII — James Cook, George Vancouver —, mas não de John Harrison, o carpinteiro de Yorkshire que, após décadas de trabalho, construiu um relógio confiável o bastante para medir a longitude no mar. Recentemente, Jeff e Sanjay estavam saboreando margaritas e enchiladas no Palo Alto Sol, um restaurante mexicano que eles frequentam, quando Jeff pegou o telefone. “Quando o Gmail foi lançado pela primeira vez?” ele perguntou. O telefone respondeu: “1º de abril de 2004”. Sanjay, que é sensível em situações sociais, parecia não gostar da distração na mesa de jantar, mas Jeff estava eufórico. O Google agora pode falar, ouvir e responder a perguntas, usando uma pilha de programas, perfeitamente integrados e praticamente invisíveis, estendendo-se de seu telefone a data centers em todo o mundo.

Hoje, seus papéis divergiram. No Google, Sanjay é conhecido como um “colaborador individual” – um programador que trabalha sozinho e não gerencia ninguém. Por isso, ele se sente grato. “Eu não gostaria do emprego de Jeff”, diz ele. Atualmente, ele está trabalhando em um software que torna mais fácil para os engenheiros combinar e controlar dezenas de programas – para buscar notícias, fotografias, preços – que começam a funcionar assim que o usuário insere um texto na caixa de pesquisa do Google. Uma vez por semana, ele se reúne com um grupo de “Area Tech Leads” – o conselho Jedi de engenharia do Google – para tomar decisões técnicas que afetam toda a empresa. Se o Google fosse uma casa, Jeff estaria construindo um anexo. Sanjay está escorando a estrutura, reforçando as vigas, apertando os parafusos.

Enquanto isso, durante as sessões de codificação de segunda-feira, eles começaram algo novo. É uma I.A. projeto: uma tentativa, diz Jeff, de treinar um modelo “gigante” de aprendizado de máquina para executar milhares ou milhões de tarefas diferentes. Jeff está pensando na ideia há anos; recentemente, ele decidiu que era possível. Ele e Sanjay planejam construir um protótipo em torno do qual uma equipe possa crescer. No mundo do software, a melhor forma de liderar é com código.

“Acho que eles sentem falta um do outro”, diz Heidi, esposa de Jeff. Foi quando a colaboração diminuiu que eles começaram a jantar nas sextas-feiras.

Em um domingo de março, Jeff e Sanjay se encontraram para uma caminhada nos arredores de Cupertino. O tempo estava claro e fresco, mas quente sob o sol. Jeff chegou ao início da trilha em um Tesla Roadster azul com um adesivo Bernie 2016. Sanjay, logo atrás, tinha seu próprio Tesla, um Modelo S vermelho. Sanjay passou a manhã lendo. Jeff tinha jogado futebol. (Um dispositivo preso a sua panturrilha lhe disse que ele havia corrido 11 quilômetros.) Duas décadas depois de construir o índice de março, Jeff parecia um atleta de resistência aposentado, com a pele desgastada pelo sol. Sanjay parecia mal ter envelhecido.

O caminho era um loop de seis milhas que subia por florestas densas. Jeff liderou o caminho. Na floresta, eles relembraram a rapidez com que o Google cresceu. Sanjay lembrou como, durante o primeiro surto de crescimento da empresa, um encanador instalou dois vasos sanitários em uma única cabine no banheiro masculino. “Lembro-me do comentário de Jeff”, disse ele. “'Duas cabeças pensam melhor do que uma!'” Ele riu.

Eles desceram da floresta para um terreno seco e exposto. Um abutre peru voou acima.

“As colinas aqui são mais íngremes do que eu pensava”, disse Jeff.

“Achei que alguém tinha dito que era uma caminhada bastante plana”, disse Sanjay.

“Acho que isso explica por que não há ciclovias naquele lado”, disse Jeff.

Eles subiram de volta para a floresta. Em um ziguezague, Jeff teve um vislumbre além das árvores. “Vamos ter uma boa vigia em algum momento”, disse ele.

A trilha se abria no topo de uma colina, alta e larga, sem árvores, com vistas panorâmicas. Havia uma névoa no horizonte. Ainda assim, eles podiam ver as montanhas de Santa Cruz ao sul e Mission Peak ao leste. “Sanjay, aí está o seu escritório!” Jeff disse. Eles ficaram juntos, olhando para o vale.

Artigo original: The Friendship That Made Google Huge