Coders At Work, écrit par Peter Seibel et publié le 16 septembre 2009, est un recueil d’entretiens avec certains des principaux programmeurs de cette génération. Les conversations sont longues et approfondies sur tous les sujets, y compris le débogage et les tests, et tournent toutes autour de l’art de la programmation. Ce livre ferait une bonne série de podcasts ou un livre audio, mais je préfère le lire.
COMMENT CE LIVRE NOUS A-T-IL AIDÉS ?
Coders at work nous a permis d’améliorer nos connaissances technologiques. Le livre fournit des informations qui ouvrent de nouvelles perspectives dans nos carrières. Le livre nous a également aidés à résoudre des problèmes. Coders at work nous a fourni des informations qui nous ont aidés à comprendre comment aborder les problèmes et utiliser les outils qui nous entourent pour développer des solutions suprêmes.
LE LIVRE EXPLIQUÉ EN MOINS DE 60 SECONDES
Le livre comprend des entretiens avec des programmeurs de haut niveau. Les principales parties de ces entretiens portent sur la manière dont les personnes interrogées se sont lancées dans la programmation, leurs langages de programmation préférés et leurs premiers programmes, leurs opinions sur les tendances actuelles en matière de programmation et des informations sur leur carrière.
TROIS CITATIONS PRINCIPALES
- « La lisibilité du code est désormais ma priorité. Elle est plus importante que la rapidité, presque autant que l’exactitude. Pourtant, la lisibilité est le moyen le plus probable de le rendre correct. »
- « Il est entré et a pissé dans la salle de bain de mon hôtel sans même fermer la porte alors que je me tenais juste à côté. Je lui ai dit : « D’accord. Vous êtes à l’aise. » Nous nous connaissions depuis quatre ou cinq ans, même si nous ne nous étions jamais rencontrés. »
- « Mais je pense que si un programme est bien écrit, il y aura quelque chose dans sa structure qui me guidera vers les différentes parties du programme dans un ordre qui aura du sens.
RÉSUMÉS ET NOTES DE LECTURE
Premier chapitre : Jamie Zawinski
Jamie Zawinski, propriétaire d’une boîte de nuit, hacker Lisp et développeur précoce de Netscape, fait partie d’un groupe de hackers connus par leurs initiales de trois lettres en guise de nom complet. En 1998, il a remarquablement contribué au développement de mozilla.org et de XEmacs. Lorsqu’on lui demande comment il a appris à programmer, Zawinski répond que la première fois qu’il a utilisé un ordinateur dans des circonstances de codage, c’était en huitième année. Il n’y avait pas d’approche pour sauvegarder les programmes, alors nous les tapions à partir de magazines. J’ai également lu beaucoup de livres, je suppose, sur différents langages, à tel point que je n’avais aucun moyen d’écrire des programmes pour des langages que je n’avais fait qu’étudier. Le fait de travailler chez Lucid, une société qui implémente le logiciel Lisp et crée un environnement de développement, a contribué à faire de Zawinski un meilleur programmeur. Il conseille aux développeurs d’être conscients du syndrome du deuxième système. Il n’a jamais eu l’idée de repenser un système. Zawinski conseille aux jeunes programmeurs de commencer modestement et de se concentrer davantage sur le processus que sur les résultats. C’est de cette manière que Fitzpatrick a créé LiveJournal.
Citation préférée du chapitre : « Parfois. Je me retrouve à faire toutes les conneries de l’administrateur système, ce que je ne supporte pas – je n’ai jamais aimé ça. J’ai aimé travailler sur XScreenSaver parce que, d’une certaine manière, les économiseurs d’écran – les modes d’affichage réels plutôt que le cadre de XScreenSaver – sont le programme parfait parce qu’ils partent presque toujours de zéro, qu’ils font quelque chose de joli et qu’il n’y a jamais de version 2.0. Il y a très rarement un bogue dans un économiseur d’écran. Il se bloque – oh, il y a une division par zéro, et vous réparez cela ».
Chapitre deux : Brad Fitzpatrick
Brad Fitzpatrick est le plus jeune des interviewés et la seule personne. Il ne peut pas vivre sans l’internet ou les ordinateurs personnels. Après avoir vu son père construire un Apple II à partir de rien, Brad est devenu programmeur, en jouant avec les pièces du matériel et en lisant des livres. Comme Zawinski, Brad a commencé avec BASIC. Il ne pouvait rien faire avec une souris ou des modes graphiques et des couleurs plus élevés. C’est alors qu’un ami de la famille de Brad l’a initié au langage C et lui a donné Turbo C. Brad s’est également essayé à la programmation assembleur sur des calculatrices telles que la Z80 sur la calculatrice IT. Brad a commencé à s’intéresser à Perl lorsqu’il s’est lancé dans les CGI et a imprimé une ou deux lignes sur le navigateur Netscape Navigator. Brad n’a pas suivi de cours de programmation. Il s’est contenté d’un ou deux livres de la bibliothèque. Son université était une combinaison de course à pied et de LiveJournal, ce qui rendait l’école supportable.
Citation préférée du chapitre : « Lorsque je travaillais en Perl – même pour les personnes qui connaissaient très bien Perl – je recommandais Higher-Order Per de MJD ! Le livre est divertissant en ce sens qu’il commence de manière assez simple, et que vous vous dites, ouais, ouais, je sais ce qu’est une fermeture. Puis il continue à vous prendre la tête. À la fin du livre, vous êtes tout simplement époustouflé ».
Chapitre trois : Douglas Crockford
Douglas Crockford a été architecte javascript senior chez Yahoo. Auparavant, il a travaillé pour Lucasfilm, Atari et Electric Communities. Crockford est allé à l’université de San Francisco et a suivi un cours de Fortran au département de mathématiques, où il a appris la programmation. Crockford affirme qu’avec les améliorations des processeurs et de la mémoire ou du matériel en général, les développeurs ne se soucient plus de l’efficacité comme ils le faisaient dans le passé. Selon l’interviewé, la difficulté de la programmation tient en partie au fait que la plupart du temps, les programmeurs font des choses qu’ils ne faisaient pas auparavant. Il évoque son approche préférée des entretiens avec les candidats à l’emploi. Il demande au candidat d’apporter un morceau de code qu’il a créé et de nous le présenter. Crockford pense également que la seule façon d’améliorer Javascript serait de le rendre plus petit, en supprimant toutes les fonctionnalités qui n’ont pas de valeur et en ne conservant que ce qui est important. Il affirme que cette approche peut être utilisée pour le HTML, le HTTP et le CSS. Les développeurs devraient déterminer ce que les langages font le mieux et se concentrer là-dessus plutôt que d’accumuler les nouvelles mises à jour. Lorsqu’on lui demande de donner des conseils à un futur programmeur, M. Crockford répond qu’il devrait se concentrer davantage sur la communication. Ils devraient apprendre à lire et à écrire.
Citation préférée du chapitre : « Pour l’essentiel, nous nous sommes bien débrouillés. Je pense que le monde est meilleur, même s’il ne va pas toujours de l’avant. Si l’on regarde les politiques internationales de ces dix dernières années, la consolidation des grands médias et la corruption des effets qui n’ont pas été compensés par le réseau ouvert, c’est une grande déception. C’est une grande déception. Des centaines de milliers de personnes sont mortes à cause de cela ».
Chapitre quatre : Brendan Eich
Brendan Eich, directeur technique de Mozilla Corporation, une filiale de la Fondation Mozilla, est responsable du développement continu du navigateur Firefox et créateur de Javascript, le langage de programmation le plus utilisé sur le web. Brendan a étudié la physique à Santa Clara, où il a appris à programmer. Brendan raconte qu’il s’intéressait à Unix et au langage C, mais qu’ils n’en étaient qu’à leurs débuts avec le vieux processeur DEC. Il possédait un compilateur C portable et commençait à créer du code et à s’amuser avec le portage d’utilitaires Unix. D’après les observations de Brendan, de plus en plus de personnes écrivaient du code avec des abstractions de plus haut niveau qu’auparavant. Si vous utilisez des applications réparties sur des serveurs dans le monde entier, l’ancienne approche ne fonctionnera pas. Brendan explique également comment il a travaillé sur le noyau et le code réseau au SCI. La taille de l’arrière-plan linguistique qu’il a utilisé a augmenté au fil du temps parce qu’il a écrit sa gestion de réseau et sa couche de reniflage de paquets. En plus de lire du code, Eich lit également des livres sur la programmation. Il dit qu’il aimait les livres de Brian Kernighan et qu’il les considérait comme très intéressants. Eich a également aimé les volumes 1 à 3 de l’ouvrage Art of Computer Programming de Knuth.
Citation préférée du chapitre : « [Assenbly level programming] sépare encore les programmeurs indépendants du sexe et des poils de la poitrine de ceux qui n’en ont pas tout à fait l’étoffe. «
Chapitre cinq : Joshua Bloch
Joshua Bloch est l’actuel architecte en chef de Java chez Google et un ancien ingénieur chez Sun Microsystems. Il est à l’origine de la conception et de la mise en œuvre du Java Collections Framework, lancé dans Java 2. Joshua a appris à programmer, notamment en Fortran, auprès de son père alors qu’il suivait un cours de programmation vers 1971. En 1977, Joshua a écrit une version du jeu des vingt questions appelé « Animals ». C’est le premier programme passionnant qu’il a écrit. Joshua insiste sur le fait que les développeurs devraient lire souvent des livres, comme Design Patterns, avec un vocabulaire commun, de bonnes idées et un mélange de styles et de langages. Un autre livre est Elements of Style, qui n’est pas un livre de programmation, mais que vous devriez lire pour deux raisons. Premièrement, il améliore votre style de prose ; deuxièmement, tous les concepts du livre s’appliquent aux programmes. Joshua soutient que la nécessité des mathématiques est beaucoup plus considérable dans une communauté qui écrit des compilateurs, des bibliothèques et des cadres. Lorsque vous écrivez des applications web sur des frameworks, vous devez comprendre la communication visuelle et verbale. Selon Joshua, les programmeurs intelligents écrivent généralement le pire code. Les programmeurs intelligents peuvent faire tenir l’ensemble dans leur tête et le comprendre. Et parce qu’ils peuvent comprendre, ils pensent que le code est utilisable.
Citation préférée du chapitre : « Nous sommes tous des optimistes dans notre métier, sinon nous serions obligés de nous tirer une balle. »
Chapitre six : Joe Armstrong
Joe est le créateur d’Erlang et de l’Open Telecom Platform, un cadre pour la création d’applications Erlang. Joe étudiait la physique et, en tant qu’étudiant de premier cycle, certains cours impliquaient la création de programmes, ce qu’il adorait. Il est devenu très doué pour le débogage, et la rémunération standard pour le débogage était d’une bière à ce moment-là. Joe passe généralement beaucoup de temps à réfléchir avant de se lancer dans le codage. Cependant, pendant cette période, il prend également des notes. Selon Joe Armstrong, les gadgets actuels ne vous rendent pas plus productif. Jetez un coup d’œil aux systèmes de fichiers hiérarchiques. Comment améliorent-ils votre productivité ? Ils ne le font pas parce que la quasi-totalité du développement du logiciel se fait dans votre tête. Travailler avec un système sans effort impose une certaine discipline de pensée. Vous aurez besoin de discipline si vous n’avez pas de système de répertoire et que vous devez placer tous les fichiers dans un seul répertoire. Si vous pouvez appliquer le même champ à ce que vous faites, vous n’aurez pas besoin de systèmes de fichiers hiérarchiques. Les systèmes de fichiers hiérarchiques, dix pour un, permettent aux groupes de travailler ensemble sans effort. Armstrong pense que ce qui fait un bon programmeur, c’est le choix des problèmes. Est-il motivé par les solutions ou par les réponses ? Il conseille également aux jeunes programmeurs d’essayer d’apprendre différents langages afin d’améliorer leurs compétences, leur flexibilité et leur connaissance d’autres langages.
Citation préférée du chapitre : « Je pense que le manque de réutilisation vient des langages orientés objet, pas des langages fonctionnels. Le problème des langages orientés objet est qu’ils ont tout cet environnement implicite qu’ils transportent avec eux. Vous vouliez une banane, mais vous avez eu un gorille qui tenait la banane et toute la jungle. »
Chapitre sept : Simon Peyton Jones
En 1987, il a été l’un des architectes d’un projet qui a permis de résoudre le langage de programmation Haskell. Simon Peyton est chercheur principal au laboratoire Microsoft Research à Cambridge. Interrogé sur la corrélation entre la programmation et la recherche, Simon a répondu que ces aspects interagissent largement. Les langages de programmation permettent de programmer sans effort. Ils agissent comme l’interface utilisateur de la programmation. Par conséquent, la recherche sur les langages de programmation et la programmation sont intimement liées. Simon a parlé des tests d’API chez Microsoft. L’entreprise réalise un travail remarquable en matière de tests d’API. Face à une nouvelle API, Steven Clarke et son équipe s’efforcent d’observer les programmeurs parler de ce qu’ils essaient de faire. Et de faire en sorte que les créateurs de l’API les observent à partir d’un écran de verre. Peyton apprécie la programmation lorsqu’il essaie d’écrire un programme avec une intégrité intellectuelle. Il ajoute que vous pouvez continuer à mettre de la boue sur le côté d’un programme, et que cela fonctionnera pendant un certain temps, mais ne sera pas satisfaisant. Par conséquent, l’une des qualités d’un bon programmeur est qu’il doit toujours essayer de trouver des solutions originales, même lorsqu’il se trouve dans une situation technique.
Citation préférée du chapitre : « Parfois, dire que c’est manifestement juste ne signifie pas que l’on peut voir que c’est juste sans aucun échafaudage mental. Il se peut que vous ayez besoin d’une explication pour comprendre pourquoi c’est juste. »
Chapitre huit : Peter Norvig
Peter Norvig est un penseur inclusif et un hacker dans l’âme. Une fois, il a conçu un programme pour détecter une série de trois recherches effectuées par le même utilisateur dans les journaux de recherche de Google. Peter a appris à programmer au lycée, où l’école disposait d’un Ph.D.-8, et il a suivi un cours qui commençait par la programmation en BASIC. Le premier code intéressant que Peter a écrit était le jeu de la vie. Il dit qu’il s’agissait d’un exercice de classe qu’il a rapidement réalisé. Peter a travaillé pour une société de logiciels à Cambridge. Leur produit était un ensemble d’outils de conception de logiciels et divers types de conseils en matière de logiciels. L’un des projets de l’entreprise consistait à créer un tiroir d’organigramme qui analyserait votre programme et générerait un organigramme. Peter a insisté sur le fait que les développeurs devaient posséder d’autres compétences que l’écriture de codes. Des compétences telles que la compréhension des besoins des clients, la communication et la résolution de problèmes. Selon Peter, la programmation est devenue une activité plus sociale qu’auparavant. À l’époque, les ordinateurs étaient plus cloisonnés et il s’agissait davantage de traitement par lots, de sorte que l’interface était un peu plus simple. Peter Norvig ne voit pas d’un bon œil l’approche de Google, qui consiste à poser des questions à énigme lors des entretiens. Il préfère que les personnes interrogées soient placées dans une situation technique plutôt que de se contenter de bavarder pour vous donner l’impression qu’il s’agit de la bonne personne.
Citation préférée du chapitre : « Je pense que l’une des choses les plus importantes est d’être capable de tout garder en tête en même temps. Vous avez beaucoup plus de chances de réussir si vous y parvenez. Un petit programme est plus facile à réaliser. Pour un programme plus vaste, vous avez besoin d’outils supplémentaires pour pouvoir le gérer. »
Chapitre neuf : Guy Steele
Lorsqu’on lui a demandé quels langages il avait utilisés, Guy Steele, véritable polyglotte de la programmation, était en fait un polyglotte de la programmation. Il a dressé la liste suivante : Fortran, COBOL, IBM, langage machine PDP-10, APL, C, C++, BLISS, Haskell, FOCAL, TEGO et TeX. « Ce sont les principaux, je suppose », ajoute-t-il. Guy a commencé à programmer grâce à un ami de l’école qui l’a fasciné avec quelques lignes du programme Fortran. Après avoir étudié Fortran, Guy a appris le langage d’assemblage IBM 1130. Son premier programme passionnant consistait à créer des index par mot-clé dans le contexte. IBM proposait des index rapides pour ses manuels qui, lorsqu’on leur donnait un clavier, vous permettaient de le rechercher dans les index. L’ordre alphabétique était basé sur le clavier, mais des deux côtés du clavier, vous pouviez voir différents mots du contexte entourant ce mot. Steele s’occupait de diverses machines sur le campus, comme le DEC PDP-10. À l’époque, Harvard possédait un PDP-10 pour les travaux d’études supérieures. Les étudiants de premier cycle n’utilisaient que les terminaux de télétype d’un système commercial loué par l’école. Steele a également mentionné certains des livres essentiels qu’il a lus et qui ont amélioré ses compétences en programmation, notamment Knuth et The Art of Computer Programming (L’art de la programmation informatique). Guy Steele affirme également que les jeunes programmeurs n’utilisent pas leurs pouces lorsqu’ils essaient de compter. D’autre part, la lutte contre l’incompatibilité de la base dix avec deux puissances a permis de réaliser des progrès substantiels.
Citation préférée du chapitre : « Je suppose qu’il y a des leçons à en tirer – la leçon que j’aurais dû tirer est qu’il peut y avoir plus d’un bogue ici, et que j’aurais dû regarder plus attentivement la première fois. Mais une autre leçon est que si l’on pense qu’un bogue est rare, l’examen des chemins rarement exécutés peut s’avérer fructueux. Enfin, le fait de disposer d’une bonne documentation sur ce que l’algorithme essaie de faire, à savoir une référence à Knuth, était tout simplement incroyable.
Chapitre dix : Dan Ingalls
Dan Ingalls, l’un des cofondateurs de Smalltalk. Il est à l’origine de la première version de Smalltalk, écrite en BASIC. Il a participé à la mise en œuvre de sept générations de Smalltalk, depuis le prototype jusqu’à l’implémentation open source actuelle, Squeak. Dan a grandi en tant qu’inventeur et s’est spécialisé en physique à l’université. Il a suivi un cours de programmation en Fortran à Harvard. Ingalls a lancé un programme après avoir fait des affaires. Son objectif était d’évaluer les programmes et d’observer leur comportement dynamique, en termes simples, le profilage. Il y avait un programme qui engloutissait un programme Fortran et plaçait des compteurs à chaque point d’embranchement. Dan a créé une version améliorée du programme, avec un processus d’interruption par minuterie, afin de suivre le temps réel passé sur les différentes parties du programme. Dan aime toujours autant programmer qu’à ses débuts. Il dit que les deux dernières années ont été intéressantes car il est passé d’un environnement familier – Smalltalk – à Squeak, où les outils étaient formidables. Dan conseille aux développeurs débutants d’apprendre différents langages avec des points forts différents. Il ajoute que cela vaut la peine pour les développeurs d’utiliser plusieurs environnements informatiques différents et de trouver un problème à résoudre.
Citation préférée du chapitre : « Différentes personnes ont différents niveaux à atteindre pour se sentir à l’aise avec ce qu’elles travaillent. Je pense donc que quelqu’un peut être tout à fait confiant dans l’utilisation d’une bibliothèque de collections sans l’avoir programmée lui-même. »
COMMENT CE LIVRE PEUT AIDER LES DÉVELOPPEURS DE LOGICIELS
« Coders at Work » est un recueil d’entretiens menés par Peter Seibel avec certains des programmeurs les plus performants et les plus expérimentés de notre époque. Dans ce livre, ces programmeurs partagent leurs idées, leurs expériences et leur sagesse sur le développement de logiciels. La lecture de ce livre peut aider les développeurs de logiciels à mieux comprendre le secteur, à tirer parti de l’expérience de programmeurs chevronnés et à développer leurs compétences et leurs perspectives. Ce livre peut inciter les développeurs à penser de manière créative et à se remettre en question pour devenir de meilleurs programmeurs.
