Programmant ensemble sur le même ordinateur, Jeff Dean et Sanjay Gemavat ont changé le cours de l'entreprise - et de l'Internet tout entier. Dans l'illustration: les meilleurs programmeurs Google semblent parfois être deux hémisphères du même cerveau. Dessin de David PlankertUn jour de mars 2000, six des meilleurs ingénieurs de Google se sont réunis dans une salle de conférence impromptue. Une situation d'urgence s'est produite: depuis octobre 1999, les chenilles se sont arrêtées. Bien que les utilisateurs reçoivent toujours des résultats de recherche, ils sont obsolètes depuis cinq mois. L'enjeu était plus important que ce que les ingénieurs attendaient. À l'heure actuelle, Larry Page et Sergey Brin négociaient la livraison de la recherche Google au plus grand portail Internet Yahoo et promettaient de décupler l'index de recherche pour suivre le World Wide Web, qui avait doublé de taille par rapport à l'année précédente. Si les robots ne sont pas réparés, google.com sera bloqué dans le passé, l'accord avec Yahoo pourrait échouer et l'entreprise risque de brûler son investissement et de tomber dans l'oubli.
Dans la salle de conférence, près des escaliers, les ingénieurs ont posé des portes sur le portique, construit des tables improvisées et installé des ordinateurs. Sur le mur du fond était assis un triste Craig Silverstein: un jeune mince de 27 ans avec une voix mince. Craig a été le premier employé de Google: il a rejoint l'entreprise lorsque son siège social était situé dans le salon de Brin, et il a personnellement réécrit la plupart du code des fondateurs. Après quatre jours et nuits de travail, ils n'ont rien obtenu avec un ingénieur système roumain nommé Bogdan Kokosel: «Aucun des tests effectués n'avait de sens», se souvient Silverstein. "Rien n'a fonctionné, et nous ne savions pas pourquoi."
Silverstein a à peine remarqué Sanjay Gemavat, une modeste brune de 33 ans aux sourcils épais et aux cheveux gris dans les tempes, diplômée du MIT. Sanjaya a été embauchée il y a quelques mois à peine, en décembre. Il est venu après son collègue, le doyen et énergique Jeff Dean de trente ans de Digital Equipment Corporation. Jeff a quitté DEC dix mois avant Sanjay. Ils étaient inhabituellement sympathiques et préféraient écrire du code ensemble. Dans la «salle de guerre», Jeff a tiré une chaise à la table de Sanjay, laissant la sienne vide. Sanjay tapa sur le clavier, et Jeff s'assit à côté de lui, corrigeant et dictant, comme un producteur sur un casque pour un annonceur de nouvelles.
Jeff et Sanjay ont commencé à étudier l'indice au point mort. Ils ont constaté que certains mots manquaient: ils ont entré une requête [boîte aux lettres] et n'ont pas reçu de résultats, tandis que d'autres étaient répertoriés dans le désordre. Pendant plusieurs jours, ils ont recherché une erreur, plongeant dans la logique du code. Section par section, nous avons tout vérifié. Pas de bugs.
Les programmeurs présentent parfois leur programme comme une structure de couches qui descend de l'interface utilisateur à des couches plus fondamentales. Au fond de cette structure, le logiciel rencontre le fer: une telle descente des abstractions du code platonique vers la physique de l'électricité et du silicium. Le cinquième jour de travail, Jeff et Sanjay ont commencé à soupçonner que le problème n'était pas dans la logique du code, mais avait une cause physique. Ils ont converti le fichier d'index en binaire. Ils voulaient voir ce qu'ils voyaient des voitures.
Une colonne épaisse avec des zéros et des uns est apparue sur le moniteur de Sanjay, chaque ligne représentant un mot indexé. Sanjay a fait remarquer: 0 est à la place de 1. Lorsque Jeff et Sanjay ont collecté tous les mots déformés, ils ont vu un modèle: le même problème dans chaque mot. Dommages aux puces de mémoire sur les serveurs.
Sanjay regarda Jeff. Pendant plusieurs mois, Google a connu de plus en plus de pannes matérielles. Le problème était qu'à mesure que Google se développait, l'infrastructure informatique s'est également développée. Le matériel informatique tombe rarement en panne, sauf si vous avez beaucoup d'ordinateurs - alors ils tombent en panne constamment. Les fils s'usent, les disques durs s'effondrent, les cartes mères surchauffent. De nombreuses voitures échouent immédiatement; d'autres commencent à travailler plus lentement. D'étranges facteurs naturels entrent en jeu. Dans une explosion de supernova dans l'espace, une onde de choc crée des particules de haute énergie qui se dispersent dans toutes les directions: les scientifiques pensent qu'il y a une chance non nulle qu'une des particules de rayonnement cosmique puisse pénétrer dans une puce d'ordinateur sur Terre et changer de 0 à 1. Les systèmes informatiques les plus fiables au monde , à la NASA, les sociétés financières et autres utilisent un équipement spécial qui protège contre les «flips» d'un bit. Mais Google a toujours travaillé en tant que startup et a acheté des ordinateurs bon marché qui ne disposaient pas d'une telle protection. L'entreprise a atteint un point d'inflexion. Le cluster informatique a atteint une taille telle que même des pannes matérielles improbables deviennent inévitables.
Ensemble, Jeff et Sanjay ont écrit du code pour compenser un dysfonctionnement sur des systèmes endommagés. Un nouvel index a rapidement été construit - et l'urgence a été résolue avec succès. Silverstein était confus. Il a vraiment débogué le code, mais ici, la réponse se cachait au niveau matériel. Jeff et Sanjay sont allés plus loin.
Avant le fiasco de mars, les systèmes Google travaillaient sur le code que les fondateurs de l'entreprise avaient écrit à Stanford. Page et Brin n'étaient pas des programmeurs professionnels. C'étaient des scientifiques menant une expérience dans la technologie de recherche. Lorsque le robot est tombé, il n'a affiché aucun message de diagnostic informatif, à l'exception de la phrase "Whoa, horse!"
Le système BigFiles, écrit par Page et Brin, a d'abord été appelé en plaisantant BugFiles par les premiers employés de l'entreprise. La procédure d'indexation extrêmement importante a pris plusieurs jours, et si j'ai rencontré un problème, elle a commencé dès le début. C'était un système totalement non évolutif.
Nous disons que nous recherchons sur Internet, mais en fait ce n'est pas le cas: nous travaillons avec l'index de recherche sur les serveurs de la société de recherche. Lorsque Google s'appelait encore BackRub en 1996, l'index entier était placé sur des ordinateurs installés dans le dortoir de Page. En mars 2000, aucun supercalculateur ne pouvait le gérer. La seule issue pour Google était d'acheter des ordinateurs ordinaires et de les ajouter à un cluster géant. Étant donné que la moitié du coût des ordinateurs conventionnels est ce que Google considère comme «indésirable» - lecteurs de disque, boîtiers métalliques - la société a commandé uniquement des cartes mères et des disques durs nus - et les a connectés. À ce moment-là, Google avait déjà connecté 1500 de ces serveurs faits maison à des racks de deux mètres dans un immeuble de Santa Clara, en Californie. En raison de pannes matérielles, seulement 1 200 ont fonctionné à un moment donné. Les pannes se sont produites de façon imprévisible et ont continué de perturber le système. Pour survivre, Google devait intégrer les ordinateurs dans un seul organisme viable et tolérant aux pannes.
Pour un couple de Jeff et Sanjay a repris ce travail. Wayne Rosing, qui a conçu le prédécesseur Macintosh chez Apple, a rejoint Google en novembre 2000, réunissant une équipe d'une centaine d'ingénieurs. Travaillant quatre-vingt-dix heures par semaine, ils ont écrit un code afin qu'aucune panne de disque dur ne perturbe le système. Ils ont ajouté des points d'arrêt au processus de traversée Web afin que l'analyse redémarre à partir du point d'échec et non dès le début. En développant de nouveaux schémas de codage et de compression, ils ont en fait doublé les capacités du système. C'étaient des optimiseurs implacables. Par exemple, Google a déplacé les données les plus fréquemment utilisées vers l'extérieur des disques durs, où la vitesse de rotation du disque est plus élevée et, par conséquent, la vitesse de lecture et d'écriture des informations plus élevée, et les zones internes des plaques sont vides. Jeff et Sanjay ont utilisé cet espace pour stocker des données prétraitées pour des requêtes de recherche générales. Pendant quatre jours en 2001, ils ont prouvé que l'index de Google peut être stocké dans une RAM rapide au lieu de disques durs lents. Cette découverte a complètement changé l'économie de l'entreprise. Page et Brin savaient que la foule se précipiterait vers un service qui répondrait instantanément. Le problème était que la vitesse exigeait de la puissance de traitement et que la puissance de traitement coûtait de l'argent. Jeff et Sanjay ont réussi à se faufiler dans le chas de l'aiguille en utilisant des optimisations logicielles.
Alan Eustace a dirigé l'équipe d'ingénierie après le départ de Rosing en 2005. «Paradoxalement, pour résoudre des tâches à grande échelle, vous devez connaître les moindres détails», a déclaré Eustace. Jeff et Sanjay ont compris le système au niveau du bit. Une fois que Jeff a distribué une liste de
"taux de retard que chaque programmeur devrait connaître" . En fait, c'est une liste de nombres à laquelle presque aucun programmeur ne pense, mais ces nombres sont littéralement intégrés dans le cerveau de Jeff et Sanjay: par exemple, que l'appel à partir du cache L1 prend 0,5 ns ou que la lecture séquentielle d'un mégaoctet de la mémoire prend 250 μs. Après une série d'optimisations logicielles clés, la puissance des systèmes Google a évolué par ordre de grandeur. Pendant ce temps, les techniciens ont commencé à emprunter des routes sinueuses dans de vastes centres de données, en suivant les instructions générées par logiciel pour remplacer les disques durs, les blocs d'alimentation et les modules de mémoire. Même lorsque les pièces se sont usées et ont échoué, le système a prospéré.
Aujourd'hui, les ingénieurs de Google ont un système de classification unifié qui commence au niveau 1, c'est le support technique. Niveau 2 - diplômés du collégial. Les employés de niveau 3 ont souvent une maîtrise. Obtenir le niveau 4 prend plusieurs années ou nécessite un doctorat. La carrière de la plupart des employés s'arrête au niveau 5. Les ingénieurs du 6e niveau sont les 10% les meilleurs du personnel, ils sont si talentueux que la réussite des projets en dépend. Le niveau 7 est attribué aux employés de niveau 6 ayant une longue expérience. Les ingénieurs en chef de niveau 8 sont responsables de produits ou de parties spécifiques de l'infrastructure. Des ingénieurs exceptionnels de niveau 9 sont respectés. Le titre de Google Fellow (niveau 10) est attribué à vie aux principaux experts mondiaux dans leurs domaines. Jeff et Sanjay sont Senior Google Fellows, les premiers et seuls employés de niveau 11.
Le campus Google, situé près de l'autoroute à quelques minutes du centre de Mountain View, est une série de bâtiments trapus et peu attrayants avec des fenêtres teintées. Un lundi matin à l'été 2017, après une séance de jumelage matinale, Jeff et Sanjay sont allés déjeuner à la cafétéria du campus appelée Big Table, du nom du système qu'ils ont aidé à développer en 2005 pour intégrer d'innombrables ordinateurs dans un appareil pratiquement unique. Grand et mince Sanjay dans un vieux t-shirt Henley bordeaux, un pantalon gris et de petits verres à monture métallique cherchait une table sur la terrasse et l'occupa rapidement, ouvrant un parapluie et s'accroupissant à l'ombre. À proximité, au soleil, il a installé une autre chaise pour Jeff, qui est arrivé une minute plus tard, un homme athlétique aux épaules larges dans une chemise à manches courtes et des baskets élégantes.
Comme les amoureux, Jeff et Sanjay racontent des histoires ensemble, complétant des morceaux de la grande image. Ils ont commencé à rappeler leurs premiers projets.
«Nous avons tout écrit à la main», explique Sanjay. Ses lunettes s'assombrirent au soleil. «Il a fallu réécrire le code, puis tout d'un coup:« Oh, ça ressemble à ce que nous avons écrit le mois dernier. »
"Ou un passage légèrement différent dans nos données d'indexation", a ajouté Jeff.
"Ou un peu différent", dit Sanjay. "Et donc nous avons découvert ..."
"C'est le point", a déclaré Jeff.
"... qu'il existe un schéma général", conclut Sanjay.
Jeff a pris une bouchée de pizza. Il a des doigts de marin, noueux et raides. Sanjay a l'air très tendre par rapport à lui. Il se demande comment ils ont commencé à pratiquer la programmation en binôme: "Je ne sais même pas comment nous avons décidé que ce serait mieux."
"Nous l'avons fait avant Google", a déclaré Jeff.
"Mais je ne sais pas pourquoi nous avons décidé qu'il valait mieux avoir un ordinateur, pas deux", explique Sanjay.
«Mon DEC était à deux pâtés de maisons de son laboratoire», explique Jeff. - Et entre eux est un magasin de crème glacée.
- C'est donc un magasin de glaces! - Sanjay est ravi.
Le célibataire Sanjay est en vacances avec Jeff, ses deux filles et sa femme Heidi. Les filles de Jeff l'appellent Oncle Sanjay, et les cinq dînent souvent le vendredi. Sanjay et Victoria, la fille aînée de Jeff, se sont mises à la pâtisserie. «Je les ai vus grandir», déclare fièrement Sanjay. Après l'introduction en bourse de Google en 2004, ils ont déménagé dans de nouveaux logements, distants de six kilomètres. Sanjay vit dans une modeste maison de trois chambres à Old Mountain View, et Jeff lui-même a conçu sa maison près du centre de Palo Alto, installant un trampoline au sous-sol. Tout en travaillant sur la maison, il a constaté qu'il aime concevoir l'espace, mais manque de patience pour les détails qu'il appelle les «aspects orientés Sanjay» de l'architecture: détails des poutres, luminaires, équilibrage de charge, qui empêchent une excellente conception de s'effondrer.
«Je ne sais pas pourquoi les autres ne fonctionnent pas de cette façon», explique Sanjay à propos de la programmation par paires.
«Nous devons trouver un partenaire qui soit compatible avec vous dans une manière de penser que vous vous complétez», a déclaré Jeff.
Ils se levèrent de table et allèrent chercher de la crème glacée molle, marchant le long de la Grande Table parmi les googleurs qui se précipitaient. Alors qu'ils marchaient, Jeff a décrit sa stratégie de crème glacée molle: «Je le fais tourner. Je pense que cette approche ajoute de la stabilité », a-t-il déclaré. Satisfait et déterminé, Sanjay roula le mélange chocolat-vanille dans son verre.
Dans le livre de 2001
«Cercles de coopération: la dynamique de l'amitié et de la créativité» , le sociologue Michael P. Farrell a étudié des groupes créatifs proches: les impressionnistes français, Sigmund Freud et ses contemporains. "La plupart des idées fragiles qui ont jeté les bases d'une nouvelle vision ne se posent pas lorsque l'ensemble du groupe est ensemble, et non pas lorsque tout le monde travaille seul, mais lorsqu'ils collaborent et interagissent en binôme", écrit-il. Monet et Renoir ont travaillé côte à côte à l'été 1869. Ils ont créé un style qui est devenu impressionnisme; six ans de collaboration ont donné naissance au cubisme, Pablo Picasso et Georges Braque n'ont souvent signé que le dos des toiles pour se cacher l'un à l'autre le fait que le travail était terminé («Le travail n'est pas terminé tant que nous ne le sentons pas tous les deux», se souvient plus tard Picasso). Dans le livre
"Double pouvoir: à la recherche de l'essence de l'innovation dans les couples créatifs", l' écrivain Joshua Wolf Schenck cite une interview en 1971 dans laquelle John Lennon a déclaré que lui ou Paul McCartney "ont écrit quelques notes légères, comme" J'ai lu les nouvelles aujourd'hui "ou des choses comme ça. "L'un de nous a été coincé jusqu'à ce que l'autre vienne", a déclaré Lennon, "je chanterai la moitié, et il a été inspiré pour écrire une autre partie, et vice versa." Tout le monde peut entrer dans une impasse créative, mais à peine deux personnes en même temps.
Au stade de la «construction théorique» d'une nouvelle science ou art, il est important d'élargir les horizons sans se retrouver dans une impasse. François Jacob, qui, avec Jacques Monod, a fait une percée dans l'étude de la fonction régulatrice des gènes, a noté qu'au milieu du XXe siècle, la plupart des recherches dans le domaine de la biologie moléculaire se faisaient par paires: `` Ensemble, il est plus facile que d'inventer des théories et de construire des modèles '', a écrit Jacob. - Lorsque deux esprits travaillent sur un problème, les idées apparaissent plus souvent et plus rapidement. Ils rebondissent de partenaire en partenaire. Ils se tordent comme des branches sur un arbre. Et les fausses illusions sont étouffées dans l'œuf. » Au cours des 35 dernières années, environ la moitié des prix Nobel dans le domaine de la physiologie et de la médecine ont été décernés à des paires de scientifiques.
Après de nombreuses années de collaboration, les partenaires développent parfois leur propre langage, comme le font les jumeaux. Ils s'imitent dans leurs habitudes et leurs vêtements, ils ont un sens de l'humour commun. Il devient impossible d'évaluer la contribution spécifique de chacun en collaboration. Mais ces partenariats étroits se rencontrent rarement dans le développement de logiciels. Bien que les développeurs parlent parfois de «programmation par paires», lorsque deux programmeurs partagent un ordinateur, l'un «derrière le volant» et l'autre «navigateur», ils ne représentent généralement qu'une relation de travail, comme les pilotes dans un avion. Jeff et Sanjay, en revanche, semblent parfois être deux hémisphères du même cerveau. Dans leurs articles scientifiques les plus célèbres, une dizaine de collaborateurs sont répertoriés. Cependant, Bill Cochran, l'un de leurs managers, se souvient: "Ils étaient si prolifiques et si efficaces en binôme que nous venions souvent de créer des équipes autour d'eux."
En 1966, des chercheurs de System Development Corporation ont découvert que les meilleurs programmeurs sont dix fois plus efficaces que les pires. Depuis lors, les différends sur l'existence du soi-disant «programmeur 10 fois». Cette idée met l'accent sur l'individualité, tandis que de grands projets logiciels sont créés par l'équipe. En programmation, peu de choses sont réalisées isolément. Ironiquement, de nombreux programmeurs considèrent les résultats de la collaboration de Jeff et Sanjay comme la preuve de l'existence d'un programmeur 10x.
Jeff est né à Hawaï en juillet 1968. Son père Andy était un explorateur des maladies tropicales; La mère de Virginia Lee est anthropologue médicale avec une demi-douzaine de langues. Pour le plaisir, le père et le fils ont assemblé un ordinateur à partir du kit IMSAI 8080. Ils ont soudé des pièces, en étudiant chaque pièce.
Jeff et ses parents ont souvent déménagé. À treize ans, il a raté les trois derniers mois de sa huitième année pour les aider dans un camp de réfugiés dans l'ouest de la Somalie. Au lycée, il a commencé à écrire un programme de collecte de données pour les épidémiologistes appelé Epi Info;
il est devenu un outil standard pour les chercheurs, traduit dans des dizaines de langues et vendu à des centaines de milliers d'exemplaires (sur le site Web du Center for Disease Control and Prevention a publié une photographie de Jeff de son diplôme). Heidi, que Jeff a rencontrée au University of Minnesota College, n'a appris l'importance de ce programme que des années plus tard. «Il ne s'est pas vanté de quelque chose comme ça», dit-elle. "Tout devait être retiré de lui." Leur premier rendez-vous était lors d'un match de basket-ball féminin, où Jeff a diverti le public dans un costume de gopher.La thèse de doctorat de Jeff se concentre sur les compilateurs. «Les compilateurs eux-mêmes sont assez ennuyeux», explique Alan Eustace, mais d'un autre côté, «c'est un niveau très bas, proche du matériel». Décrivant Jeff, Sanjay tourne un doigt vers sa tempe: «Lors de l'écriture de code, un certain modèle se forme dans sa tête. Quelles seront les performances de ce code? Il calcule presque automatiquement toutes les situations frontalières. »Sanjay s'est assis pour la première fois devant un ordinateur à l'âge de dix-sept ans lorsqu'il est allé à l'Université Cornell. Il est né à West Lafayette, Indiana, en 1966, mais a grandi à Kota, une ville industrielle du nord de l'Inde. Son père, Mahipal, était professeur de botanique; la mère de Shant s'occupait de Sanjay et de ses deux frères et sœurs aînés. La famille adorait les livres: son oncle Ashok Meta se souvient de la façon dont il a acheté «Jackal Day» pour les enfants .Frederick Forsyth avec une reliure déchirée, et les enfants lisent tous ensemble un livre en lambeaux, se passant des pages quand ils ont fini. Le frère de Sanjay, Pankaj, est devenu le plus jeune enseignant à recevoir un poste à la Harvard Business School (il est maintenant professeur à l'Université de New York). Pankaj a étudié dans la même école que Sanjay et était connu comme un homme de la Renaissance: «J'ai en quelque sorte vécu dans l'ombre de mon frère», explique Sanjay. Adulte, il a conservé cette modestie. En 2016, lorsqu'il a été présenté à l'Académie américaine des arts et des sciences, il n'en a même pas parlé à ses parents; ils ont appris la nouvelle d'un voisin.À la MIT Graduate School, Sanjay s'est fait des amis. Néanmoins, il n'y a jamais rencontré de filles, et maintenant il le fait «très, très rarement». Il dit qu'il n'a pas refusé de fonder une famille, c'est juste arrivé comme ça. Ses amis proches ont appris à ne pas le déranger à ce sujet, et ses parents avaient depuis longtemps compris que son fils resterait célibataire. Peut-être parce qu'il est si fermé, un halo de secret s'est développé autour de Google autour de Sanjay. Il est considéré comme un ingénieur silencieux mais solide - qui pense profondément et avec une clarté extraordinaire. Sur la table, il a une pile ordonnée de cahiers Mead depuis près de vingt ans, remplie de listes et de diagrammes soignés. Il prend toujours des notes à la main: il dit que ça aide à réfléchir. Au MIT, son superviseur était Barbara Liskov, une informaticienne influente,qui a étudié notamment la gestion de bases de code complexes. À son avis, le meilleur code est comme une bonne littérature. Il devrait avoir une structure soigneusement pensée et chaque mot devrait fonctionner. Une telle programmation nécessite de l'empathie avec les lecteurs. Et le code est considéré non seulement comme un moyen pour atteindre une fin, mais aussi comme un artefact précieux en soi. «Je pense qu'il conçoit le mieux les systèmes», déclare Craig Silverstein. "Il suffit de regarder son code: il est beau, comme une œuvre d'art, comme une sculpture aux proportions parfaites."«Je pense qu'il conçoit le mieux les systèmes», déclare Craig Silverstein. "Il suffit de regarder son code: il est beau, comme une œuvre d'art, comme une sculpture aux proportions parfaites."«Je pense qu'il conçoit le mieux les systèmes», déclare Craig Silverstein. "Il suffit de regarder son code: il est beau, comme une œuvre d'art, comme une sculpture aux proportions parfaites."Chez Google, Jeff est beaucoup plus célèbre. Ils créent des mèmes sur lui comme sur Chuck Norris. ("Chuck Norris a compté à l'infini ... deux fois"; "Le curriculum vitae de Jeff Dean résume des choses qu'il n'a pas faites: si courtes")."Quand Jeff Dean développe un programme, il crée d'abord un binaire puis écrit le code source comme documentation."
"Jeff Dean a une fois échoué au test de Turing parce qu'il a correctement réglé le 203ème numéro de Fibonacci en moins d'une seconde."
«Une fois en 2002, lorsque le moteur de recherche a été déconnecté, Jeff Dean a répondu manuellement aux questions des utilisateurs pendant deux heures. Pendant cette période, la qualité des résultats de recherche a augmenté de manière significative ...
De l'article "Jeff Dean de Google - c'est Chuck Norris de notre temps" - env. trans.
Mais pour ceux qui les connaissent tous les deux, Sanjay a autant de talent que lui. «Jeff est formidable pour proposer de nouvelles idées et prototypes fous», a déclaré Wilson Sie, leur collègue de longue date. "Sanjay construit des choses sur sa conscience." Dans la vie, Jeff est plus sociable, Sanjay plus réservé. Le code est le contraire. La programmation de Jeff est éblouissante: il peut livrer rapidement des idées surprenantes, mais comme il le fait rapidement, avec inspiration, il peut laisser les lecteurs derrière lui. Le code Sanjaya est plus compréhensible.
«Certaines personnes écrivent du code trop clairsemé», explique Silverstein. Il y a très peu d'informations sur un seul écran. Je dois le faire défiler d'avant en arrière pour comprendre. " D'autres écrivent du code trop dense: «Vous le regardez et pensez:« Wow. Je ne veux pas comprendre cela. " Sanjay parvient en quelque sorte à trouver un équilibre. Vous regardez son code et pensez: "D'accord, je peux le comprendre", et il y a toujours beaucoup d'informations sur une seule page. " Silverstein continue: «Chaque fois que je veux ajouter de nouvelles fonctionnalités au code de Sanjay, il semblait le prévoir. Je me sens comme Salieri. Je vois la grandeur, mais je ne comprends pas comment cela est possible. "
Lundi matin ce printemps, Jeff et Sanjay se tenaient dans la kitchenette du bâtiment 40, qui abrite la majeure partie de la division IA de Google. Derrière eux se trouve un tableau noir rempli de formules d'algèbre matricielle; sur la table est un article sur les réseaux compétitifs sans enseignant. Jeff dans un T-shirt et un jean délavés ressemble à un clochard de plage qui a pris le chemin de la correction. Sanjay dans un pull et un pantalon gris. Derrière les fenêtres lumineuses se trouvent de grands pins, derrière eux se trouve un champ. Partout où Jeff travaille pour Google, ils mettent toujours des machines à expresso. Le mètre La Marzocco bourdonne sur la table de la cuisine. "Nous sommes en retard", observe Sanjay par-dessus le moulin à café. À 8 h 32
Après le cappuccino, ils vont aux ordinateurs. Jeff fait rouler une chaise de sa table sale à la table impeccablement propre de Sanjay. Il pose son pied sur la table de chevet, se penchant en arrière pendant que Sanjay étudie l'écran. Quatre fenêtres sont ouvertes: à gauche - un navigateur et un terminal pour lancer les outils d'analyse; à droite se trouvent deux documents dans l'éditeur de texte Emacs: l'un a une liste de tâches dans le bloc-notes, l'autre est rempli de code coloré. Un des cahiers de Sanjay se trouve à côté d'un ordinateur.
- D'accord, qu'est-ce qu'on faisait? - demande Sanjay.
«Je pense que nous avons analysé la taille du code TensorFlow Lite», explique Jeff.
Il s'agit d'un nouveau projet majeur d'apprentissage automatique: Jeff et Sanjay s'inquiètent d'une base de code gonflée. Comme les éditeurs littéraires, ils recherchent des moyens de réduire le volume. Pour ce faire, ils ont créé un nouvel outil, qui en lui-même doit être optimisé.
"J'ai essayé de comprendre à quel point c'est lent", a déclaré Sanjay.
"Assez lent," Jeff se pencha en avant, toujours détendu.
"Celui-ci était de cent vingt kilo-octets", dit Sanjay, "et cela prend environ huit secondes."
"Cent vingt mille appels de pile, pas des kilo-octets."
"Eh bien, des kilo-octets de texte, eh bien ... à ce sujet."
- Oh oui, je suis désolé.
"Je ne sais pas quel seuil choisir pour la taille de l'unité", demande Sanjay. - un demi méga?
"Ça va," acquiesce Jeff. Sanjay commence à frapper au clavier et Jeff s'accroche à l'écran. "Donc, vous écrivez que si c'est plus que ce qui est spécifié, nous choisissons simplement ..." il fit une pause; Sanjay a répondu à la question avec un code.
Lorsque Sanjay conduit une voiture, il met ses mains sur dix et deux et regarde attentivement vers l'avant. La même discipline derrière le clavier. Largeur des épaules, jambes droites, comme s'il travaillait sur la posture. Des doigts fins courent doucement autour des touches. Les premiers programmeurs ont commencé à arriver au bureau.
Bientôt, ils ont atteint un petit jalon, et Sanjay a recruté une équipe pour exécuter le test. Il avait l'air épuisé et vérifia le courrier. Le test est terminé. Il ne s'en est pas aperçu.
- Hé! - Jeff claqua des doigts et désigna l'écran. Bien que dans la conversation, il reçoive des blagues et des jeux de mots, à l'ordinateur avec Sanjay, il peut devenir confiant, grossier et désapprobateur. Sanjay tient cela pour acquis. Quand il lui semble que Jeff va trop vite, il lève les mains du clavier et écarte les doigts, comme pour dire: «Stop». C'est le semblant le plus proche d'un différend: pendant vingt ans, ils ne se souviennent pas quand ils ont élevé la voix.
Sanjay a fait défiler la page, une nouvelle section de code est apparue à l'écran.
"Vous pouvez faire une routine avec ça, non?" Demanda Jeff.
- Mmm ...
Jeff a craqué ses articulations.
- Cela semble possible. Fera l'affaire?
Sanjay clôturé:
- Non, je ...
"Alors, ignorer le problème?" - Jeff demande avec indignation.
"Non, je veux dire, nous essayons juste de comprendre ce qui se passe." Pour prendre des notes à ce sujet, non?
"Bien." Jeff était clairement de bonne humeur. Ils ont dicté une note ensemble.
Le déjeuner approchait. Ils ont travaillé deux heures avec une pause de dix minutes, parlant la plupart du temps (le junior qui les regardait serait le plus impressionné par le fait qu'ils ne s'arrêtaient jamais et n'étaient pas coincés). La pratique d'ingénierie standard consiste à soumettre le code pour la révision, mais Jeff et Sanjay sautent cette étape en marquant lgtm (cela me semble bien). Dans un sens, ils sont occupés par de petites choses. Cependant, leur code fonctionne à l'échelle de Google. Les kilo-octets et les microsecondes dont ils se soucient se multiplient des milliards de fois dans les centres de données du monde entier - d'énormes centres de données bruyants où les racks de serveurs sans fin sont refroidis par des réservoirs d'eau. Ces jours-là, Jeff, comme vous le savez, rentre à la maison et dit à ses filles: "Aujourd'hui, Sanjay et moi avons accéléré la recherche de Google de 10%."
En 2003, en quatre mois, Jeff et Sanjay ont peut-être effectué la plus grande mise à jour de l'histoire de Google. Ils l'ont fait en utilisant le logiciel MapReduce. L'idée est venue lorsqu'ils ont réécrit le robot et indexeur Google pour la troisième fois. Ils ont réalisé qu'à chaque fois qu'ils résolvaient un problème important: la coordination du travail dans un grand nombre d'ordinateurs distribués géographiquement et peu fiables séparément. Si pour généraliser la solution, le problème sera résolu pour toujours. Cela fera apparaître un outil que tout programmeur sur Google peut utiliser pour contrôler les machines dans les centres de données, comme s'il s'agissait d'un seul ordinateur de la taille d'une planète.
Jeff et Sanjay ont peint MapReduce dans un coin bureau donnant sur un étang à canards. Cet outil a pour toujours rationalisé un processus d'une complexité à couper le souffle. Auparavant, chaque programmeur devait déterminer de manière indépendante comment partager et distribuer des données, affecter le travail et prendre en compte les pannes matérielles. MapReduce fournit un moyen structuré pour résoudre ces problèmes. Comme le chef prépare les ingrédients avant de commencer le travail culinaire, MapReduce divise les tâches en deux étapes. Premièrement, le programmeur donne à chaque machine une «carte» de la tâche (par exemple, en comptant le nombre de références à un mot sur une page); puis il écrit des instructions pour «réduire» les résultats de toutes les machines (par exemple, en sommant). MapReduce gère les détails de la distribution et les cache donc.
L'année suivante, Jeff et Sanjay ont réécrit le système d'exploration et d'indexation de Google en termes de tâches MapReduce. Bientôt, d'autres ingénieurs ont réalisé à quel point ce système était puissant - et ont commencé à utiliser MapReduce pour traiter la vidéo et rendre les vignettes sur Google Maps. MapReduce était si simple que de nouvelles tâches sont apparues d'elles-mêmes. Google a un cycle de chargement quotidien: pendant la journée, plus de trafic que la nuit, et les tâches MapReduce ont commencé à absorber la capacité inactive. Dans un rêve, le cerveau humain traite l'expérience quotidienne. Maintenant, Google a commencé à traiter ses données la nuit.
Les preuves ont fait surface depuis longtemps que Google est en fait une société d'intelligence artificielle qui prétend simplement être un moteur de recherche. En 2001, Noam Shazir, qui partageait le bureau avec Jeff et Sanjay, a décidé de refaire le système de vérification orthographique sous licence de Google d'une autre société. Ce système a continué de faire des erreurs maladroites. Par exemple, elle a proposé de remplacer le mot TurboTax par turbot hache (plie trouvée dans l'Atlantique Nord).
La qualité du correcteur orthographique dépend du dictionnaire. Shazir a réalisé que sur Internet, Google a accès au plus grand dictionnaire qui ait jamais existé dans l'histoire de l'humanité. Il a écrit un programme qui utilise les propriétés statistiques du texte sur Internet pour déterminer quels mots ont probablement été tapés par erreur. Le programme comprenait que «pritany spears» et «brinsley spears» signifiaient «Britney Spears». Lorsque Shazir a montré le programme lors de la réunion hebdomadaire, de nombreux employés ont tenté à plusieurs reprises de le tromper, mais en vain. Shazir, en collaboration avec Jeff Dean et un ingénieur nommé Georges Harik, a développé un système similaire de ciblage des publicités sur le contenu des pages Web. Ce ciblage a apporté une avalanche d'argent que l'entreprise a envoyé à son infrastructure informatique. Cela a marqué le début d'une boucle de rétroaction: la croissance de l'infrastructure améliore les capacités informatiques et l'intelligence de Google; Les compétences informatiques deviennent une source de profit, et le profit vous permet de construire des infrastructures. Cette boucle de rétroaction a apporté à l'entreprise une domination du marché extraordinaire et sans précédent.
Les programmeurs ingénieux ont utilisé MapReduce pour obtenir diverses informations à partir des données Google: il est devenu possible de transcrire les messages vocaux des utilisateurs, de répondre à leurs questions, de remplir automatiquement les requêtes et de traduire les textes dans plus de cent langues. Ces systèmes ont été développés à l'aide d'algorithmes d'apprentissage automatique relativement simples. Cependant, "lorsque vous avez beaucoup de données, les méthodes très simples fonctionnent incroyablement bien", a déclaré Jeff. Depuis que «les données, les données, les données» - stockées et traitées à l'aide de BigTable, MapReduce et de leurs successeurs - le principal atout de l'entreprise, l'infrastructure mondiale de Google est devenue plus flexible et évolutive. L'idée de l'informatique distribuée est née il y a longtemps. Les concepts de «cloud computing» et de «big data» existaient avant l'avènement de Google. Mais en rendant l'infrastructure intelligemment gérable pour les programmes distribués par des programmeurs ordinaires, Jeff et Sanjay font passer Google au niveau supérieur. Les utilisateurs ont ressenti: quelque chose a changé - le cloud de Google devient plus intelligent.
En 2004, Jeff et Sanjay pensaient que le système serait utile aux astronomes, généticiens et autres scientifiques ayant beaucoup de données à traiter. Ils ont ensuite publié l'article
«MapReduce: traitement simplifié des données dans les grands clusters» . Le document est apparu comme Dieu de la voiture. Des équipements bon marché, la croissance des services Web et des appareils connectés ont conduit à un flux de données, mais seules quelques entreprises disposaient de logiciels pour traiter de tels tableaux d'informations. Deux ingénieurs qui avaient du mal à faire évoluer un petit moteur de recherche appelé Nutch - Mike Cafarella et Doug Cutting - étaient tellement convaincus de l'importance de MapReduce qu'ils ont décidé de créer un clone gratuit de ce système à partir de zéro. À la fin, ils ont nommé leur projet Hadoop, du nom de l'éléphant en peluche, que le fils de Cutting aimait.
Progressivement, la moitié des sociétés Fortune 50 ont repris Hadoop, devenu synonyme de Big Data. Facebook a utilisé Hadoop MapReduce pour stocker et traiter les métadonnées des utilisateurs - des informations sur les clics, les likes et les vues des annonces. À un moment donné, Facebook avait le plus grand cluster Hadoop au monde. Hadoop MapReduce a contribué au succès de LinkedIn et de Netflix.
L'ancien directeur de la technologie de la NSA, Randy Garrett, se souvient avoir montré la technologie au directeur général de la NSA, Keith Alexander. Hadoop a terminé la tâche d'analyse 18 000 fois plus rapidement que le système précédent. Cela est devenu la base d'une nouvelle approche de la collecte de renseignements, que certains observateurs appellent «la collecte totale de tout».
Jeff a un caractère agité: pour lui, le problème se désintéresse lorsqu'il voit une solution. En 2011, la technologie cloud a balayé le monde et Jeff Dean a commencé à travailler avec Andrew Eun, professeur d'informatique à Stanford, qui a dirigé un projet secret sur la recherche sur les réseaux de neurones chez Google. Jeff a rencontré des réseaux de neurones au cours de ses années d'études, mais ils n'ont pas pu résoudre de vrais problèmes. Eun a dit à Jeff que la situation avait changé. À Stanford, les chercheurs ont obtenu des résultats impressionnants en donnant aux réseaux de neurones accès à de grandes quantités de données. Eun a suggéré qu'à grande échelle, les réseaux de neurones peuvent devenir non seulement utiles, mais aussi puissants.
Les réseaux de neurones sont très différents des programmes informatiques traditionnels. Leur comportement n'est pas déterminé par des commandes ordinaires, mais le réseau est «entraîné» à l'aide des entrées et des retours. Les connaissances de Jeff sur les réseaux de neurones n'ont pas progressé depuis ses années d'études, et Heidi a regardé leur salle de bain se remplir de manuels. Jeff a commencé à consacrer environ une journée par semaine à un projet appelé Google Brain. Beaucoup chez Google doutaient de cette technologie. "Un gaspillage de talent", se souvient Alan Eustace, le manager de Jeff à l'époque. Sanjay, lui aussi, ne pouvait pas comprendre la décision de l'ami: "Vous travaillez sur l'infrastructure, qu'avez-vous oublié là-bas?"
Au cours des sept prochaines années, l'équipe de Google Brain a développé des réseaux de neurones qui ont donné les meilleurs résultats au monde en matière de traduction automatique, de reconnaissance vocale et d'image. Au final, ces réseaux de neurones ont remplacé les algorithmes les plus importants de Google pour le classement des résultats de recherche et le ciblage des annonces, et Google Brain est devenu l'une des équipes à la croissance la plus rapide de l'entreprise. Claire Tsui, ingénieur chez Google depuis 2001, dit que la décision de Jeff a été un tournant pour le développement de l'IA chez Google: «Certains y ont cru, d'autres non. Jeff a prouvé que cela peut fonctionner. »
Il s'est avéré que l'IA avait un besoin critique d'échelle, et l'ingénieur système Jeff Dean l'a fournie. Dans le cadre de ce projet, il a dirigé le développement d'un programme appelé TensorFlow - c'était une tentative de créer quelque chose comme MapReduce, uniquement pour l'IA. TensorFlow simplifie la distribution des réseaux de neurones dans un cluster d'ordinateurs, les transformant en un seul grand cerveau. En 2015, lorsque TensorFlow a été rendu public, il est devenu la norme de facto pour travailler avec l'IA. Le PDG Sundar Pichai a récemment annoncé que l'activité principale de Google est l'intelligence artificielle et a nommé Jeff pour diriger toutes les initiatives d'IA.
Maintenant, Jeff consacre quatre jours par semaine à la gestion de Google Brain. Il dirige le travail de 3 000 personnes. Il se rend aux négociations, tient des réunions hebdomadaires pour travailler sur une nouvelle puce informatique (un processeur tensoriel conçu spécifiquement pour les réseaux de neurones) et aide au développement d'AutoML, un système qui utilise des réseaux de neurones pour concevoir d'autres réseaux de neurones. Il n'a le temps de programmer avec Sanjay qu'une fois par semaine.
L'histoire efface les prouesses d'ingénierie. Nous nous souvenons des grands explorateurs du XVIIIe siècle - James Cook, George Vancouver - mais pas John Harrison, un charpentier du Yorkshire qui, après des décennies de travail, a rendu la montre suffisamment fiable pour mesurer la longitude en mer.
Jeff et Sanjay ont récemment dégusté des margaritas et des enchiladas au Palo Alto Sol, leur restaurant mexicain préféré. Jeff a sorti son téléphone et a demandé: "Quand Gmail est-il sorti?" Le téléphone a répondu: «1er avril 2004.» Sanjay, l'étiquette à table, ne semblait pas apprécier l'impulsion de l'ami, mais Jeff était ravi. Google est désormais capable de parler, d'écouter et de répondre à des questions à l'aide d'une pile de programmes facilement intégrés et largement invisibles, s'étendant de son téléphone aux centres de données du monde entier.
Aujourd'hui, leurs rôles ont divergé. Sanjay sur Google est connu comme un «participant individuel» - un encodeur qui fonctionne seul et ne contrôle personne. Il en est reconnaissant. «Je ne voudrais pas travailler comme Jeff», admet-il. Il crée actuellement un logiciel qui permettra aux ingénieurs d'intégrer et de gérer plus facilement des dizaines de programmes - actualités, photos, tarifs - qui commencent à fonctionner dès que l'utilisateur tape dans le champ de recherche Google. Une fois par semaine, il rencontre un groupe de responsables technologiques, le Jedi Engineering Council de Google, pour prendre des décisions techniques qui affectent l'ensemble de l'entreprise. Si Google était à la maison, Jeff construirait une extension et Sanjay renforcerait la fondation, renforcerait les poutres et resserrerait les boulons.
Pendant ce temps, lors de leurs sessions de programmation en couple du lundi, ils ont commencé quelque chose de nouveau. Il s'agit d'un projet d'IA: comme le dit Jeff, une tentative de former un modèle ML «géant» pour effectuer des milliers ou des millions de tâches différentes. Jeff réfléchit à cette idée depuis de nombreuses années; il a récemment décidé que c'était possible. Lui et Sanjay prévoient de construire un prototype autour duquel l'équipe pourra se développer. Dans le monde du logiciel, la meilleure façon de gérer votre équipe est basée sur le code du programme.
«Je pense qu'ils se manquent», explique Heidi, la femme de Jeff. Les dîners de famille du vendredi sont apparus lorsque leur collaboration a ralenti.
Dimanche de mars, Jeff et Sanjay se sont rencontrés pour un voyage à la campagne. Le temps est clair, bien qu'il fasse chaud au soleil. Jeff est arrivé sur le sentier de randonnée sur le Tesla Roadster bleu avec un autocollant pour pare-chocs Bernie 2016. Sanjay l'a rapidement suivi sur le modèle rouge S. Sanjay a lu le livre le matin, Jeff a joué au football (l'appareil à son poignet a montré qu'il avait couru 11 kilomètres. Deux décennies plus tard après avoir réparé cet indice, Jeff ressemble à un athlète rustique bronzé à la retraite, et Sanjay ne semble pas avoir vieilli du tout.
Le chemin est une boucle de 10 kilomètres à travers des forêts denses. Jeff est allé le premier. Dans la forêt, ils ont rappelé à quelle vitesse Google a grandi.
Sanjay a rappelé comment, après le premier agrandissement de l'entreprise, le plombier a installé deux toilettes dans la même salle de bain dans la chambre des hommes. «Je me souviens du commentaire de Jeff», a-t-il déclaré. "Deux têtes valent mieux qu'une!" Il rit.Ils sont descendus de la forêt vers une zone ouverte et sèche. Un vautour a volé dans le ciel."Les montagnes sont plus fraîches que je ne le pensais", a admis Jeff.- Et quelqu'un a dit que c'était une campagne plate."Je pense que c'est pourquoi il n'y a pas de pistes cyclables."Ils sont remontés dans la forêt. En montant, Jeff a vu un espace entre les arbres: «À un moment donné, il y aura une bonne vue», a-t-il déclaré.Le sentier est allé jusqu'au sommet de la colline, haut et large, sans forêt, avec une vue panoramique. La brume à l'horizon ne couvrait pas les montagnes de Santa Cruz au sud et Mission Peak à l'est. "Sanjay, voici ton bureau!" - dit Jeff. Ils se tenaient ensemble et regardaient à travers la vallée.