Le mirage de la productivité

• Bob, ingénieur légendaire de Facebook, a lancé Facebook Groups et enchaîné les réussites en hackathon sans environnement de développement sophistiqué
• Il utilisait seulement Sublime Text de base et des logs printf, dans un environnement avec coloration syntaxique imprécise, sans live reloading ni débogueur
• À l’inverse, les développeurs autour de lui considéraient des configurations d’outils complexes comme la clé de la productivité : coloration syntaxique et snippets Vim, tmux, mosh, raccourcis hphpd, alias Git, etc.
• Dans les victoires de Bob en hackathon, le sens du produit et l’intuition, c’est-à-dire la capacité à juger quoi construire, ont davantage compté que la configuration de son éditeur
• Une nouvelle façon de travailler peut certes produire du changement, mais au final les résultats viennent du fait de résoudre le bon problème

---

L’écart entre outils complexes et résultats réels

• Bob était un ingénieur prolifique ayant lancé Facebook Groups, ainsi qu’une figure légendaire capable d’enchaîner les réalisations en hackathon
• Un collègue alors obsédé par la productivité utilisait une coloration syntaxique et des snippets Vim faits maison pour Hack, le dialecte PHP de Facebook
  • Il faisait tourner tmux sur mosh, et avait même mis en place des raccourcis hphpd personnalisés et des alias Git
• La manière de travailler de Bob était, à l’inverse, extrêmement simple
  • Il utilisait Sublime Text sans configuration particulière, au point qu’environ la moitié des couleurs de code s’affichaient incorrectement
  • Au lieu du live reloading ou d’un débogueur, il ajoutait printf dans le code et attendait l’apparition des logs
• Ce jour-là, Bob a gagné le hackathon, et son projet était, de mémoire, une fonctionnalité permettant les publications d’achat et de vente dans Facebook Groups
  • Cette fonctionnalité a ensuite évolué pour devenir Facebook Marketplace

Ce qu’il faut construire, plutôt que comment

• Se focaliser sur des outils complexes peut enfermer dans le comment du travail et faire perdre de vue le quoi, c’est-à-dire ce sur quoi il faut travailler
• La clé de la forte productivité de Bob n’était pas la configuration de son éditeur, mais son sens du produit et son intuition
• Sur X, de nouvelles manières de travailler apparaissent chaque jour avec la promesse de tout bouleverser, et certaines ont peut-être un réel potentiel de transformation
• Mais l’essentiel n’est ni l’outil ni la méthode de travail en soi, c’est de résoudre le bon problème

[GN⁺]

Avis sur Hacker News

• Il est erroné d’opposer l’artisan qui chérit ses outils à la personne obsédée par les outils. De bons outils ne sont pas des jouets, mais des moyens au service d’un objectif, et j’ai moi-même passé plusieurs jours à créer des scripts shell, des fonctions Emacs, des outils d’agencement de fenêtres, etc., adaptés à mon flux de travail.
  Résultat : la coloration syntaxique, la navigation et l’analyse de code, l’agencement de l’écran et les manipulations Git se font en quelques frappes, et les éléments qui brisent la concentration ont disparu. Il faut investir dans son environnement de travail — chaise, prompt shell, éditeur — puis, une fois à l’aise, l’oublier et se concentrer sur les vrais problèmes.
  Cela dit, un réglage sans fin des outils peut être le signe qu’on évite une tâche pénible et peu amusante ; ce n’est donc pas un problème aussi simple qu’un défaut des outils eux-mêmes.

  • Que faire si, dans un nouveau poste, on vous donne une nouvelle stack technique et un portable Windows ? En début de carrière, j’ai appris à travailler efficacement avec les outils de base de l’environnement qui m’était imposé, et en pratique il était rare de pouvoir choisir ses outils soi-même. Même les outils multiplateformes manquent souvent de cohérence, à l’exception de la suite JetBrains.
  • Cela ressemble à la différence entre samouraï et ninja. Le samouraï voyait son sabre comme une extension de son âme, tandis que le ninja s’en servait aussi pour faire levier et ouvrir quelque chose si nécessaire. Dans l’économie actuelle, la vision samouraï des outils ne convient pas.
  • Il est important d’éprouver du plaisir à utiliser ses outils. Même si la productivité n’est pas multipliée par 10, l’essentiel est de rester concentré sur le travail et d’apprécier le processus.
    À l’ère des LLM en particulier, les outils obligent à passer sans cesse d’un agent à l’autre et d’un terminal à l’autre. Ces changements de contexte fréquents enlèvent le plaisir et l’état de flow ; j’aimerais que quelqu’un trouve une solution.
  • On dirait que beaucoup de débutants sautent des étapes nécessaires parce qu’ils veulent être reconnus et pris au sérieux. Paraître ainsi et le devenir réellement sont deux choses différentes, et il faut aussi gagner sa vie pendant qu’on développe ses compétences.
  • Une fois une technique maîtrisée, de bons outils deviennent en eux-mêmes une grande source de plaisir. À l’inverse, les experts peuvent parfois produire des résultats étonnamment bons même avec des outils inadaptés.

• J’ai vu beaucoup de techniciens passer plus de temps à optimiser leur configuration d’environnement qu’à réellement construire quelque chose, et cela m’est aussi arrivé. L’idée selon laquelle, puisque 90 % du temps de codage serait passé à taper, il faudrait augmenter sa vitesse de saisie, est fausse : 90 % du temps devrait être consacré à réfléchir, et l’essentiel de ce temps à lire.

  • Un logiciel est la concrétisation d’une solution à un problème ; il faut donc d’abord définir le problème à résoudre. Le code est un instantané qui montre à tout le monde, y compris à votre futur vous, votre compréhension actuelle du problème ainsi que la clarté et la pertinence de la solution.
    Au bon moment, coder revient presque à concrétiser par la saisie une solution déjà comprise.
  • Avant, j’étais obsédé par la configuration, mais depuis que j’utilise l’IA, je crée des choses formidables que je n’aurais pas pu faire auparavant. En revanche, ma compréhension du code sous-jacent et mes compétences existantes s’affaiblissent peu à peu ; j’admire de nouvelles techniques sans vraiment les apprendre en profondeur.
    En abaissant la barrière à franchir au départ, l’IA est aussi une autre forme d’amélioration de l’environnement. Quand je voyageais en Europe pour passer d’un rôle QA à un poste de développeur en étudiant InterviewCake, je perdais déjà du temps à peaufiner la configuration de mon éditeur plutôt qu’à résoudre des problèmes.
    C’est peut-être un symptôme de TDAH. Depuis un traitement médicamenteux récent, ma productivité a énormément changé, au point que j’en ai eu les larmes aux yeux en pensant avoir gâché la moitié de ma vie à rendre ma configuration parfaite plutôt qu’à faire le vrai travail.
  • Il existe un décalage entre productivité réelle et productivité ressentie. Taper du code avec aisance dans Vim ou Emacs donne l’impression d’être un hacker, mais cela ne signifie pas qu’on est productif. Même piloter des dizaines d’agents IA avec d’énormes quantités de tokens ne garantit pas que le résultat fonctionne ou résolve le problème.
  • Je ne sais pas si, pour la plupart des développeurs d’applications CRUD ordinaires, le ratio selon lequel 90 % du temps devrait être passé à réfléchir et lire est exact.
  • Réflexion et saisie se produisent souvent simultanément. Beaucoup de gens raisonnent plus facilement sur un problème en écrivant et en modifiant du code, ce qui explique aussi pourquoi, même en lisant tout le code généré par un LLM, la compréhension du code peut fortement diminuer.

• Il existe des entreprises financées par des VC qui ne parviennent pas à créer des produits réellement utilisés ou payés. Pour justifier leur valorisation, elles montrent à quel point elles sont occupées et productives ; la frénésie autour de l’IA peut relever de la même logique, en se concentrant sur la productivité et les méthodes plutôt que sur ce qu’il faut construire.
  https://components.news/the-gamer-and-the-nihilist/ compare ces startups nihilistes aux studios de jeux qui créent des produits que les gens paient et utilisent. Dans une économie où les apps de productivité représentent près de 40 % des résultats de Product Hunt, le travail peut servir davantage à donner l’impression de construire quelque chose qu’à construire réellement.

  • Les développeurs de jeux consacrent eux aussi d’énormes efforts à la création d’outils, simplement la cible principale n’est pas l’éditeur de texte.
  • Je me demande où se situent, dans cette analogie, les personnes qui passent d’innombrables heures à créer l’environnement de jeu parfait plutôt qu’à jouer, ou les audiophiles qui passent leur vie à chercher l’équipement parfait plutôt qu’à écouter de la musique.
  • Plutôt qu’une bulle, cela ressemble davantage à une manipulation de signaux qui se répète depuis longtemps. Cela a toujours existé et continuera d’exister.

• Je crée ou utilise des outils de productivité seulement assez pour ne pas prendre de retard, et je considère le reste comme un piège. Avant, je faisais le point une fois par trimestre ; depuis l’IA, je passe 1 à 2 jours par semaine sur ce méta-travail d’amélioration des outils, et je m’attends à ce que cela diminue quand les outils concernés se standardiseront.
  Si l’image d’expert des outils devient trop forte, on risque non seulement de manquer le vrai travail à valeur ajoutée, mais aussi d’être perçu comme quelqu’un qui détient des secrets de productivité. Si l’écart n’est pas à la hauteur des attentes, même d’autres jugements peuvent perdre en crédibilité.

• Moins je passais de temps devant l’ordinateur, plus j’abattais de travail ; lorsque je suis passé de 3 moniteurs à 1, ma productivité a fortement augmenté. Je résous la plupart des problèmes en coupant des légumes ou en tondant la pelouse, et ce n’est pas parce qu’on est assis devant une technologie brillante qu’on prend des décisions plus rapides et meilleures.
  Si j’obtiens de meilleurs résultats que les équipes de développement de mes clients, c’est aussi parce que je ne suis pas salarié permanent et que je peux m’arrêter suffisamment longtemps pour réfléchir lentement. Le théâtre de la productivité, comme la pression de garder son statut Teams au vert, produit des décisions idiotes dans beaucoup d’organisations.

  • Pendant 15 ans, j’ai travaillé dans deux entreprises dont les bureaux étaient installés sur une falaise surplombant l’océan à La Jolla, en Californie. Je marchais le long de la falaise et dans le parc en réfléchissant au travail, et lorsqu’une discussion sérieuse ne nécessitait pas de tableau blanc, je proposais à un collègue de marcher ensemble. Cela vaut la peine de réécouter le hammock talk de Rich Hickey.
  • Vu le nom d’utilisateur, je me demande si c’est le Bob mentionné dans l’article.

• En réfléchissant à la raison d’être de la productivité, j’en suis arrivé à l’hypothèse qu’il s’agit d’une tentative de réduire la douleur. De nombreuses optimisations de performance, y compris la productivité des programmeurs, deviennent souvent pour les ingénieurs un refuge pour éviter la douleur liée à l’ambiguïté du domaine du problème, à la politique organisationnelle, au flou et au risque d’échec.
  Mais pour résoudre des problèmes réels, il faut affronter la réalité : examiner les workflows utilisateurs avec un niveau de détail presque ennuyeux, proposer clairement une stratégie commune pour obtenir la coopération des autres, etc. Il n’est pas nécessaire de glorifier la douleur elle-même, mais un bon résultat intègre un entraînement comparable à celui d’un athlète, et il faut développer la capacité à gérer la douleur nécessaire sur le terrain.

• Le cœur du sujet est de savoir s’il est facile d’obtenir de la reconnaissance. Les outils brillants, tout le monde peut les voir et les admirer ; rares sont ceux qui savent reconnaître un excellent nouveau produit ou une excellente fonctionnalité à partir d’un éditeur vide ou d’un squelette de code. C’est pourquoi l’attention se porte sur les outils visibles, tandis que la question difficile et floue de ce qu’il faut construire est ignorée.
  J’applique aux outils un critère à la Marie Kondo : s’ils ne sont ni agréables à utiliser ni utiles pour me simplifier la vie, je m’en débarrasse ; sinon, je les garde.

• En 2004, une petite équipe composée majoritairement de développeurs juniors a eu droit à une excellente et vaste formation Java. Avant la formation, nous étions obsédés par la configuration d’IntelliJ et d’Eclipse et en débattions âprement, mais l’instructeur a étonnamment recommandé de n’utiliser que les outils JDK de base et Notepad.
  L’objectif était de nous apprendre ce qui se passait en interne, et il disait que la productivité ne serait probablement pas très différente.

• Si l’on s’obsède pour l’optimisation de l’environnement, c’est parce que le lien entre effort concentré et récompense est visible, concret et physique. À l’inverse, l’apprentissage abstrait ne l’est pas. Les tâches d’apprentissage sont bien plus nombreuses que les choses à optimiser dans une chaise ; ce serait bien de trouver une façon de rendre l’apprentissage abstrait plus concret.

• Il ne s’agit pas de productivité, mais du plaisir de jouer avec des jouets.