Programmer, c’est surtout penser (2014)

• Le résultat visible sous forme de code n’est pas l’ensemble du travail d’une journée : il ressemble plutôt au résultat pur qui reste après lecture, recherche, débogage, validation et décisions
• Dans des questions informelles posées à des programmeurs pendant plusieurs années, la réponse la plus fréquente au temps nécessaire pour ressaisir, à partir du seul diff, une modification de 6 heures était environ 30 minutes
• Ce ratio ne vient pas d’une étude scientifique, mais de sondages et de l’observation de diffs ; il constitue toutefois un repère pratique pour voir la programmation comme 1/12 d’action, 11/12 de réflexion
• Le développement logiciel ressemble davantage à un travail de conception qu’à une fabrication industrielle ; après la conception initiale, la reproduction est assurée par des machines à un coût marginal proche de zéro
• Si le management et les processus optimisent pour augmenter le temps passé à taper, ils produisent des effets à côté de la cible ; les environnements et modes de collaboration qui améliorent la qualité de la réflexion sont plus importants

---

Le temps nécessaire pour ressaisir 6 heures de travail

• L’hypothèse est celle d’une bonne journée, avec peu de réunions et d’interruptions, pendant laquelle un programmeur a fait 6 heures de programmation sérieuse
• Avant de partir, il a imprimé le diff, mais pendant la nuit le système de gestion de versions tombe en panne ; on restaure la sauvegarde de la veille et le travail de la journée disparaît
• La question centrale est : combien de temps faut-il au programmeur, muni du diff, pour ressaisir ces 6 heures de travail dans la base de code ?
• Pendant plusieurs années, cette question a été posée dans des conventions, chez des clients, à des collègues et à des programmeurs rencontrés pour la première fois ; la réponse la plus courante était environ 30 minutes
• 6 heures contiennent 12 fois 30 minutes ; cette observation mène donc à l’expression selon laquelle programmer, c’est 1/12 d’action, 11/12 de réflexion

Nature et limites de ce ratio

• Ce chiffre ne provient pas d’une recherche scientifique rigoureuse, ni d’une enquête officielle bien documentée
• L’objectif n’était pas de trouver une loi statistique ou mathématique de l’activité de programmation, mais une réponse raisonnable à une question raisonnable
• Comme aucune entreprise n’a voulu réellement supprimer tout le travail d’une journée pour prouver ou réfuter l’expérience, les éléments disponibles restent des estimations et l’observation de diffs quotidiens
• Après examen de nombreux changelogs et diffs, la quantité de changement pure produite lors d’une bonne journée semblait généralement représenter 30 minutes ± 10 minutes

La frappe n’est pas le goulot d’étranglement

• L’affirmation « la frappe n’est pas le goulot d’étranglement » circule depuis longtemps sur des autocollants et les réseaux sociaux
• Pour certains programmeurs, la frappe elle-même peut être un goulot d’étranglement, mais le cœur d’une production rapide de code n’est généralement pas la vitesse de frappe ni la seule maîtrise des outils
• Dans un long fil Quora intitulé « How do programmers code so quickly? », une personne ayant répondu mentionnait la mémoire musculaire, la maîtrise des outils, les capacités de débogage, la frappe et la recherche d’information
• Mais dans la production rapide de code, la frappe et les outils sont plutôt des moyens auxiliaires ; le temps passé à décider quoi faire pèse davantage

Différence entre usine logicielle et travail de conception

• Dans la production de biens physiques, la majeure partie du travail visible est du mouvement : rouler, emboutir, presser, fraiser, placer et assembler de l’acier ressemble à du travail
• Les usines modernes, comme avec les machines CNC, exécutent des mouvements précis à partir de modèles abstraits — des données — tandis que les humains supervisent les machines au lieu de les manipuler directement à la main
• Côté logiciel, l’usine est déjà achevée : l’utilisateur appuie sur un bouton « copy » ou « download » pour obtenir une bit-perfect copy
• Une fois le modèle initial existant, le coût marginal des copies suivantes est pratiquement nul ; le logiciel est un bien intellectuel
• Uncle Bob Martin affirme depuis longtemps que le développement logiciel n’est pas un travail de fabrication mais un travail de conception, et qu’après la conception initiale, la reproduction est effectuée par des machines à un coût presque nul
• Les programmeurs, testeurs, PO, Scrum Masters et managers logiciels conçoivent le modèle de données qui sert de base aux copies utilisées par les clients et la communauté

Le travail intellectuel est difficile à observer

• La pensée héritée de l’ère industrielle tend à voir le développement logiciel comme une usine, et les développeurs subissent une pression pour que leur activité ressemble à du travail physique, même si cela nuit au processus réel
• L’activité intellectuelle est difficile à observer et à mesurer ; une idée achevée à 80 % n’a pas de forme physique
• Il peut y avoir des expériences, du code de proof-of-concept ou des notes, mais ils ne montrent pas un taux d’achèvement précis comme le ferait un travail physique
• Une chaise en cours de fabrication semble à peu près terminée à 50 % lorsqu’elle est à mi-parcours, et ressemble à un produit fini lorsqu’elle est terminée
• La conception d’une chaise peut ne pas exister sur papier avant d’avoir dépassé 70 %, et avant la fin de la conception, il est difficile de savoir si elle est réellement achevée à 70 %

Pourquoi une modification de 30 minutes représente 6 heures de travail

• Les 30 minutes correspondent au temps nécessaire pour reproduire le résultat pur du code écrit, supprimé, édité et recréé toute la journée, pas à l’ensemble de l’effort investi
• En écrivant du code, le programmeur évalue en continu et formule des hypothèses afin d’éviter défauts et vulnérabilités de sécurité
• Le texte du code ne dit que ce que le programme doit faire à l’exécution ; il ne conserve généralement pas pourquoi cette approche a été choisie, quels effets elle a sur les autres parties du système, ni quelles erreurs ont été introduites puis supprimées
• L’essentiel du travail réel ne consiste pas dans la modification elle-même, mais à décider comment la faire ; comme il faut comprendre le code existant, un code désordonné ou une base où la conception n’apparaît pas clairement prend plus de temps
• Le résultat du programmeur étant intégré à une base de code partagée, il a un contexte social ; aider d’autres programmeurs, testeurs et équipes d’exploitation à comprendre le travail crée aussi des coûts et bénéfices qui n’apparaissent pas dans le code

Les lignes de code ne mesurent pas l’avancement

• 6 heures de travail intellectuel peuvent, après lecture, recherche, décision, vérification, validation et revue, se transformer en l’équivalent de 30 minutes de changements purs dans la base de code
• Cela ne signifie pas un nombre de lignes de code ajoutées ; il arrive qu’après une correction de bug et l’ajout d’une fonctionnalité, le nombre de lignes de code en fin de semaine soit inférieur à celui du début de semaine
• Il est déjà arrivé que l’enregistrement de lignes de code négatives pendant plusieurs semaines pose problème, sans que l’équipe sache que des cadres dirigeants utilisaient le SLOC comme indicateur d’avancement
• Ce que le programmeur a réellement fait ressemble plutôt à de la lecture, de l’apprentissage, de la compréhension, des suppositions, de la recherche, du débogage, des tests, de la compilation, de l’exécution, ainsi qu’à la formulation et à la réfutation d’hypothèses
• Une grande partie du travail reste, au final, penser et décider

Écrire moins peut être du développement plus rapide

• L’une des réponses sur Quora soulignait que l’on voit les doigts bouger sur le clavier, mais pas le temps passé à parler avec les utilisateurs, discuter des problèmes avec les collègues, enquêter et réfléchir
• Une autre réponse indiquait qu’aider le client à supprimer des idées inutiles qu’il appelle « exigences » ou « must have » est ce qui accélère le plus la livraison d’une solution
• Une autre encore expliquait qu’un excellent développeur accomplit plus de 90 % du travail avant de toucher le clavier, en comprenant les besoins et en imaginant une solution appropriée
• « Savoir quoi ne pas écrire », « en faire moins », « travailler par étapes plus petites » et « déterminer quoi faire d’abord » reviennent régulièrement dans les réponses
• Les personnes qui tapent davantage ou copient-collent davantage peuvent manquer de réflexion et de compréhension, ce qui peut entraîner plus d’erreurs et alourdir la charge de compréhension et de correction pour les autres programmeurs

Les processus doivent être conçus pour la réflexion

• Si la programmation est 1/12 d’action et 11/12 de réflexion, il ne faut pas pousser les gens à taper pendant 11/12 de leur temps
• Ce qu’il faut, ce sont des matériaux, environnements et processus qui améliorent la qualité de la réflexion
• Faire l’inverse revient à optimiser le système pour les mauvais effets
• La productivité peut augmenter lorsque l’on conçoit délibérément le système pour réfléchir ensemble au logiciel et rendre les décisions plus faciles à prendre
• Il faut expérimenter l’apprentissage au travail et réfléchir à la manière de créer des systèmes où la pensée est optimisée

[GN⁺]

Avis de Hacker News

• La phrase de l’article selon laquelle « un développeur vraiment excellent termine plus de 90 % du travail avant de toucher au clavier » est parfois vraie, mais elle me semble oublier que les gens ne peuvent pas garder simultanément en tête beaucoup de contraintes et de concepts
  Le champ dans lequel on peut se contenter de penser, sans rien écrire, est très limité ; donc dès qu’une approche possible me vient à l’esprit, j’ai tendance à prendre le clavier presque aussitôt, avant de la raffiner en une conception entièrement spécifiée
  En écrivant du vrai code et en essayant plusieurs approches, il m’est souvent arrivé que la solution que je pensais d’abord être la meilleure se révèle bien moins bonne qu’une solution qui paraissait moins prometteuse, et rien ne met aussi bien un problème en évidence que du code concret qui s’exécute
  Au bout du compte, coder consiste à matérialiser des idées en code pour les valider, et il faut voir l’écriture de code comme une partie du processus de réflexion, à la manière d’une approche de prototypage où l’on jette la première itération

  • J’ai eu la même réaction en lisant cette phrase, et je suppose qu’elle faisait peut-être référence à des cas comme Linus Torvalds
    La légende veut qu’il ait réfléchi à Git pendant environ un mois, puis l’ait terminé en 6 jours et se soit reposé le 7e ; mais pour les gens ordinaires, en particulier dans mon cas, c’est plutôt une interaction où l’on réfléchit à ce qu’on va écrire, on écrit, on teste, on réfléchit à nouveau, puis on corrige une partie
    Au final, le chemin qui mène à la version fonctionnelle définitive relève dans une certaine mesure de l’art
  • En général, je procède par itérations
    Une fois que j’ai une idée générale, je commence à coder par les parties « collantes » qui me semblent les plus susceptibles de poser problème
    On ne peut pas anticiper tous les problèmes à l’avance, il faut les rencontrer concrètement, et cette méthode conduit souvent à jeter beaucoup de travail
    Je n’écris presque pas de documentation tant que je ne suis pas convaincu d’être sur la bonne voie[0], car cela permet de réduire ce que j’appelle les Concrete Galoshes[1]
    [0] https://littlegreenviper.com/miscellany/evolutionary-design-...
    [1] https://littlegreenviper.com/miscellany/concrete-galoshes/
  • Pour concevoir toute une application dans sa tête, il faut très bien connaître les pièges de la plateforme et des technologies qu’on utilise
    La seule façon de les apprendre, c’est beaucoup de codage en conditions réelles et un apprentissage actif, ce qui signifie aussi réutiliser sans cesse la même stack technique
    Je préfère rester sur la même stack pour me concentrer sur le problème lui-même, mais le « bon développeur » dont il est question ici risque d’être assez unidimensionnel dans son choix d’outils
  • Je commence par réfléchir au niveau macroscopique, puis j’organise les connexions et la structure avec des mind maps et des diagrammes
    Avec l’âge, il devient évident que l’architecture compte bien plus que les décisions microscopiques
    Le micro peut être optimisé, mais les décisions macro sont généralement permanentes
  • J’ai toujours pensé que c’était une raison d’utiliser le TDD
    On conçoit souvent le code dans les tests, en les laissant guider l’implémentation dans une certaine mesure
    J’imagine le résultat final, puis j’écris les tests sous la forme qui me semble constituer une bonne API pour le système, et je pars de là
    Le code devient ainsi testable par défaut, et en enchaînant plusieurs cycles Red → Green → Refactor, on finit par atteindre un état satisfaisant
    Je me demande si d’autres travaillent aussi comme ça

• L’explication que j’ai préférée vient du livre de Jonathan E. Steinhart, “The Secret Life of Programs”
  Elle dit que la programmation informatique se fait en deux étapes : 1. comprendre l’univers 2. l’expliquer à un enfant de trois ans
  Cela veut dire qu’on ne peut pas écrire un programme qui fait quelque chose qu’on ne comprend pas ; qu’on ne peut pas créer un correcteur orthographique si l’on ne connaît pas les règles d’orthographe ; et qu’il est difficile de faire un bon jeu vidéo d’action si l’on ne connaît pas la physique
  Pour devenir un bon programmeur, il faut apprendre autant que possible sur tout le reste, et comme la solution à un problème vient souvent d’endroits inattendus, il ne faut pas écarter ce qui ne semble pas pertinent sur le moment
  La deuxième étape consiste à expliquer ce que l’on sait à une machine qui voit le monde de manière très stricte, comme un enfant de trois ans
  Si vous demandez à un enfant « où sont tes chaussures ? », il peut répondre « là-bas » : il a répondu à la question, mais il n’a pas déduit l’intention réelle, qui était d’enfiler ses chaussures pour sortir
  Les enfants grandissent et apprennent la souplesse et l’inférence, mais les ordinateurs, comme Peter Pan, ne grandissent jamais

  • Je serais curieux de savoir s’il existe d’autres recommandations de livres similaires
  • La programmation est en grande partie de la réflexion, mais il existe de nombreuses façons de réfléchir
    Les modes de pensée adaptés varient selon les personnes et les problèmes, et apprendre à penser et à programmer de plusieurs manières donne davantage d’outils parmi lesquels choisir
    C’est pourquoi je n’aime pas les affirmations selon lesquelles la programmation devrait forcément se dérouler d’une seule bonne manière
    Dire qu’« on ne peut pas programmer ce qu’on ne comprend pas » n’est pas vrai non plus ; on utilise souvent le logiciel pour comprendre comment quelque chose fonctionne réellement
    Même la modélisation physique vise souvent moins une fidélité parfaite au réel qu’une exploration de l’équilibre entre expérience utilisateur et difficulté dans un jeu
    La programmation peut être un outil cognitif exploratoire, ce qui ne signifie pas que l’essentiel de la réflexion doive toujours venir en premier
    J’aime les généralistes et les autodidactes, mais ce n’est pas une première étape indispensable pour devenir un bon programmeur
    Les enfants n’ont pas tant une « vision stricte du monde » qu’une incapacité fréquente à inférer les implications sociales, et les ordinateurs aussi peuvent être programmés pour tirer des conclusions logiques à partir de faits connus
    J’ai expliqué des choses à des enfants de plusieurs âges, y compris à des enfants de trois ans, mais cette expérience ne ressemblait en rien à la programmation informatique

• Je suis assez convaincu que ce chiffre est globalement juste, mais aucune entreprise n’a encore accepté de supprimer entièrement une journée de travail pour prouver ou réfuter cette expérience.
  À une époque où j’étais beaucoup plus patient, j’avais un patron qui relisait chaque soir toutes les modifications de code et supprimait ce qui ne lui plaisait pas.
  Il estimait que le contrôle de version était inutilement compliqué, et voulait imposer comme standard de l’entreprise l’accès à distance au disque réseau de chez lui.
  Donc, de temps en temps, en arrivant le lendemain, le travail de la veille avait disparu, et jusqu’à ce qu’on installe SVN en douce, j’étais devenu très doué pour le recréer.
  Même en incluant les tests des cas limites, cela prenait rarement plus d’une heure.

  • L’échantillon est réduit, mais dans mes 2 premiers postes en embarqué sur 2, le code était versionné avec des partages réseau et du copier-coller.
    Ayant été en quelque sorte traumatisé par mon premier emploi, j’ai tout de suite demandé dans le deuxième s’il y avait un dépôt Git ; mon patron pensait que Git était la même chose que Github et a répondu qu’il ne voulait pas rendre le code public.
    Plus tard, après notre rachat par une plus grande entreprise, j’ai obtenu un accès à l’intranet et j’y ai trouvé une instance GitLab ; j’y ai mis sous contrôle de version et documenté mon code, sur lequel je travaillais presque seul, et j’ai même installé GitLab Runner.
    J’avais aussi documenté étape par étape comment exécuter le code ; quand on m’a licencié et demandé de transmettre le code, j’ai tout montré et expliqué comment le reproduire, et mon patron a été assez impressionné et reconnaissant.
    En insistant pour faire les choses comme je pensais qu’elles devaient l’être dans un boulot médiocre, j’ai peut-être laissé un petit impact positif.
    Avant de trouver ce GitLab, j’avais créé un dépôt Git nu sur un partage réseau et je poussais dessus.
  • Je ne saurai jamais si c’était un mauvais patron ou un maître zen.
  • Le plus gros problème, c’est que le manager intervient dans le code.
    Même avec de bonnes intentions, quand un manager se mêle du code ou des reviews, c’est presque toujours une perte nette pour l’équipe.
  • Quiconque a sérieusement utilisé des produits Microsoft Office dans les années 2000 et 2010 sait que c’est vrai, ou bien finit par appuyer machinalement sur Enregistrer toutes les 5 à 10 minutes.
  • Je me demande si le travail refait une deuxième fois était meilleur ou moins bon.

• C’est un bon texte à envoyer à des non-programmeurs.
  De même que les programmeurs ont besoin de connaissances métier, les personnes qui veulent obtenir quelque chose de programmeurs devraient aussi comprendre un minimum la programmation.
  Même un diff minuscule peut prendre des heures à cause du débogage, de la conception et de l’apprentissage.
  Il est facile de rester indifférent en ne regardant que la quantité produite, mais se faire expliquer quelque chose par quelqu’un et passer soi-même des heures à se cogner la tête contre un mur pour le comprendre sont deux choses complètement différentes.

  • Les plus petits morceaux de code que j’ai livrés sont généralement ceux qui ont pris le plus de temps, ont eu le plus d’impact et ont été les plus satisfaisants une fois compris.
    C’est le genre de situation où il faut des jours pour trouver un commit d’une ligne qui améliore les performances par 100, tout en devant expliquer en réunion de synchronisation pourquoi le ticket n’avance pas.

• C’est donc la connaissance métier qui est essentielle.
  J’ai travaillé dans la finance, assis sur des desks de trading à observer plusieurs places de marché, et j’ai écrit du code pour implémenter diverses stratégies.
  Si l’on ne sait pas ce que l’entreprise doit faire, on ne peut pas non plus réfléchir à ce que l’ordinateur doit faire.
  De ce point de vue, il peut être logique de former les codeurs comme des traducteurs.
  Un ami traducteur connaît bien la grammaire et les idiomes de plusieurs langues, et apprend de nouvelles langues comme nous apprenons de nouveaux langages de programmation, mais il a aussi passé beaucoup de temps à étudier l’industrie pharmaceutique, et traduit maintenant des documents médicaux.
  Les avocats et les comptables exercent eux aussi des métiers avec une barrière de langage.
  En devenant expert, on apprend le langage du droit, de la comptabilité ou du logiciel, mais un bon expert répond dans le langage du business, pas dans le langage de sa spécialité.
  Un avocat moins bon énumère en jargon juridique tous les résultats possibles et vous laisse décider ; un bon avocat vous dit que, même s’il existe de nombreuses possibilités marginales, en pratique les clients dans une situation comparable font tous X pour atteindre tel objectif business.
  Dans mon premier poste en trading, un trader avait créé un module Excel VBA qui parcourait des titres et exécutait une procédure pour trouver des opportunités de transaction.
  Il n’y avait aucun contrôle de version, seulement un fichier enregistré sur disque ; en quelques semaines, un nouveau venu a enregistré le fichier après avoir effacé tout le module VBA, sans sauvegarde ni aide possible de l’IT.
  Le trader est devenu rouge de colère, puis s’est calmé, a accepté le fait qu’il aurait de toute façon fallu une sauvegarde et la réalité de ce qu’il faisait avec VBA, puis s’est assis et a retapé l’ensemble, comme un écran de terminal des années 80 qui affiche les caractères un par un.

  • Développer dans un domaine que l’on connaît bien et dans un nouveau domaine, ce n’est pas du tout la même chose.
    Ma conviction est qu’il faut d’abord avoir de l’expérience dans ce domaine pour créer une bonne solution.
    En ce moment, je passe l’essentiel de mon temps à acquérir de l’expérience dans un nouveau domaine, et je m’assois à côté d’experts métier pour accumuler rapidement les connaissances nécessaires.
  • D’après mon expérience de software engineer également CPA, les entreprises ne se soucient généralement pas beaucoup de cette connaissance métier.
    Elles préfèrent un software engineer qui a créé des logiciels comptables pendant 15 ans à quelqu’un avec mon profil, puis choisissent de le faire discuter 30 minutes avec un comptable.
  • La programmation est un domaine si vaste qu’il est très difficile de formuler des généralisations valables pour l’ensemble.
    On voit sans cesse revenir des prescriptions selon lesquelles la programmation devrait forcément fonctionner d’une certaine manière, mais les types de tâches varient énormément selon les sous-domaines.
    Plutôt que d’essayer d’apprendre ou d’enseigner une méthodologie unique parfaite applicable à tous les domaines, je pense qu’il vaut mieux disposer d’une boîte à outils contenant plusieurs approches et méthodologies, et comprendre dans quelles situations chacune convient bien.
  • C’est vrai, mais dans mon pays toutes les entreprises ont des clauses de non-concurrence, donc même si l’on acquiert une connaissance métier, on ne peut pas la réutiliser dans le poste suivant si l’employeur actuel nous licencie.
    C’est pourquoi on finit par se concentrer sur des compétences générales de programmation transférables d’un secteur à l’autre.

• On trouve quelque chose de similaire au début du livre PPP de Bjarne[0]
  L’idée est : « Même les meilleurs programmeurs — surtout les meilleurs — passent l’essentiel de leur temps non pas à écrire du code, mais à comprendre le problème. Comprendre un problème demande souvent beaucoup de temps sérieux et un effort intellectuel considérable. C’est précisément ce défi intellectuel que beaucoup de programmeurs désignent quand ils disent que la programmation est passionnante »
  J’ai aussi acheté la nouvelle édition[1], qui était récemment en première page[2]
  [0]: https://www.stroustrup.com/PPP2e_Ch01.pdf
  [1]: https://www.stroustrup.com/programming.html
  [2]: https://news.ycombinator.com/item?id=40086779

  • C’est globalement vrai, mais j’ai l’impression que le plus gros problème est le temps passé à répéter sans cesse les mêmes débats
    Quelle base de données utiliser, quel langage est le meilleur, faut-il autoriser null dans le code et dans la base de données, le format des API, le format des logs, ce genre de choses
    Ce n’est pas particulièrement intéressant et il faut parfois les réexaminer, mais dans les trois dernières entreprises où j’ai travaillé, cette perte de temps m’a surtout donné l’impression qu’il s’agissait de problèmes qui auraient déjà dû être résolus
    En réalité, une entreprise dotée d’une doctrine forte peut être bien plus productive, même si celle-ci est discutable
    Si on m’avait imposé Perl, MongoDB et CGI, je pense que j’aurais été plus productif que récemment, malgré cette stack
  • La partie la plus difficile est de déterminer ce qu’il ne faut pas coder, que ce soit lors de la phase de conception avant d’écrire, ou après avoir appris d’un prototype ou d’une itération précédente
  • *Bjarne

• « Programmer, c’est surtout penser » fait partie de ces phrases que l’on se répète comme une vérité profonde, mais comme observation, elle n’est pas très productive
  Dire que programmer, c’est penser, est vrai exactement dans le même sens que tout travail intellectuel est de la pensée
  Le design aussi, c’est surtout penser ; la comptabilité aussi, c’est surtout penser ; et le management, c’est en grande partie penser
  La différence significative n’est pas la pensée elle-même, mais ce à quoi on pense
  Les managers doivent déboguer des problèmes humains, ils ont donc besoin de passer beaucoup de temps avec des gens, c’est-à-dire en réunions
  Les développeurs déboguent des problèmes informatiques, ils ont donc besoin de passer beaucoup de temps avec l’ordinateur
  Il y a là une tension évidente, et aucun des deux extrêmes ne fonctionne ; il faut donc trouver un équilibre pour moins perturber le travail des uns et des autres

  • Cet article ne s’adresse pas aux programmeurs, mais aux non-programmeurs, comme les managers qui pensent que programmer consiste surtout à taper au clavier ; il explique ce qui se passe quand nous ne sommes pas en train de taper
  • Mon ancien directeur de thèse répétait sans fin combien de temps on perdait chaque jour à retirer les mains du clavier si l’on ne mémorisait pas les raccourcis et les macros ; cette observation-ci est beaucoup plus productive que cela
  • Une différence importante en programmation est qu’il vaut souvent mieux faire la même chose avec moins de code
    Je ne parle pas de code golf obscur, mais du fait qu’il faudra maintenir tout ce que l’on produit
    C’est clairement différent d’un romancier, qui se souciera peu de maintenance et davantage de l’émotion produite par le texte

• La meilleure optimisation pour « créer un système où la pensée s’optimise en expérimentant l’apprentissage au travail », c’est réduire les interruptions
  Les études montrent que les interruptions ont un effet dévastateur sur la programmation
  Après une interruption, il faut 10 à 15 minutes pour reprendre le travail ; un programmeur n’a probablement qu’une seule session ininterrompue de deux heures dans sa journée ; et les pires moments pour l’interrompre sont lorsqu’il est en train d’éditer, de rechercher ou de comprendre
  Je me demande s’il existe un moyen de suivre et de visualiser ce type d’interruptions
  [0] http://blog.ninlabs.com/2013/01/programmer-interrupted/

  • Si vous proposez à un manager de découper une réunion d’une heure en tranches de 10 minutes réparties sur 6 heures, vous verrez une expression vraiment étrange sur son visage
    Pourtant, on attend des développeurs qu’ils terminent des tâches de codage de plusieurs heures au milieu de réunions sans fin, de petits pings Slack/Zoom et de synchronisations
    Les fois où j’ai dû travailler de chez moi le week-end, j’ai constaté que la qualité du travail produit pendant un week-end sans interruption était bien meilleure que lors d’un jour de semaine chaotique
  • C’est pour cela que je fais 80 % de mon travail la nuit
    Cela ne convient pas à tout le monde ni à toutes les situations, et les 20 % restants servent à se coordonner avec les personnes qui travaillent de jour, mais la productivité qui vient de bonnes sessions sans interruption de plusieurs heures est incomparable
    Encore une fois, ce n’est pas une méthode qui convient à tout le monde, ni probablement à la plupart des gens
  • À cause des fortes exigences en temps et des interruptions, je suis environ plusieurs fois plus productif en télétravail, de l’ordre d’un facteur à un chiffre
    Chez moi, personne ne m’interrompt, et même lorsqu’une interruption arrive, je peux choisir quand y répondre
    En particulier, si l’on travaille sur un problème difficile et qu’on est interrompu toutes les 10 à 20 minutes, il vaut mieux laisser tomber ; sinon, on risque fort de produire du code catastrophique qui donnera mal à la tête plus tard
  • J’ai déjà dirigé, dans une grande entreprise, un projet de développement d’un outil destiné à suivre la façon dont les gens utilisent leur temps
    Il était conçu pour respecter la vie privée : il enregistrait le fait qu’un navigateur web avait été utilisé, mais pas les URL précises indiquant s’il s’agissait de l’intranet interne ou de fb.com
    Une popup demandait parfois à l’utilisateur d’évaluer lui-même sa productivité et de laisser un commentaire en texte libre, et nous ne la rattachions pas à son identifiant utilisateur afin que les gens ne mentent pas pour se donner une image surhumaine
    Nous avons créé un frontend Windows et un backend Scala, puis les avons déployés auprès d’un groupe de volontaires incluant des développeurs, des juristes et des financiers, mais juste au moment où les premières analyses de données devenaient intéressantes, nous avons manqué de temps et de budget, et nous n’en avons donc pas fait un article
    Nous avions aussi regardé des outils existants comme Rescue Time ( https://www.rescuetime.com/
    ), mais nous avions jugé inacceptable de stocker des données internes de productivité dans un cloud externe

• La bonne programmation consiste parfois surtout à réfléchir, mais l’adage « aucun plan ne survit au premier contact avec l’ennemi » est juste
  La programmation pragmatique est un mélange réfléchi entre planification et mise du code dans l’IDE, et cet équilibre doit évoluer selon le cas d’usage

  • Programmer, ce n’est pas simplement penser, c’est surtout faire de la reconnaissance
    Si vous passez plusieurs jours sans écrire de code, soit vous connaissez parfaitement la surface du problème, soit vous êtes simplement en train de deviner
    Dans le second cas, il n’y a pas grand-chose à quoi réfléchir
  • Faire un premier lancement dans l’IDE ressemble au fait de terminer un niveau de jeu pour la première fois
    La deuxième fois, on va plus vite
    Je suis d’accord pour étendre la notion de pensée à une « pensée assistée par les outils »

• C’est une reformulation de Programming as Theory Building de Peter Naur, qui a été décisive dans ma compréhension de l’essence de la programmation
  Programmer ne consiste pas à produire le programme lui-même, mais à formuler une certaine intuition sur les affaires du monde ; le code finalement produit n’est qu’une simple expression de la théorie que l’on a construite