- La toute première chose faite en arrivant dans une nouvelle entreprise était d’acheter un nouveau carnet ; ce n’était pas qu’un simple plaisir, mais la reconnaissance qu’il s’agit d’un outil essentiel pour un développeur
- Le code n’est que l’étape finale ; le plus important est le processus de réflexion sur ce qu’il faut construire et comment le construire, et cela commence souvent sur un carnet plutôt que sur un ordinateur
- Visualiser sa pensée par l’écriture et le dessin dans un carnet permet de concrétiser des idées abstraites, de faire apparaître les zones de flou dans ses connaissances et d’aider à concevoir de meilleures architectures
- Prendre l’habitude de réexpliquer par écrit le code que l’on a soi-même produit agit comme un outil de refactoring efficace pour repérer les incohérences ou les mauvais choix de conception
- Ces notes sont aussi utiles à son soi futur comme support pour retrouver le contexte des décisions prises, devenant une sorte de document de rétrospective automatisé
Pourquoi le stylo et le carnet sont les plus importants
- Avant même le premier jour de travail, l’une des choses les plus attendues était de choisir un nouveau carnet
- Pour un développeur, un carnet n’est pas un simple outil de prise de notes, mais un outil de pensée
- Le code est l’exécution située à l’extrémité du processus de réflexion, et le plus important est de se demander quoi construire
- Dans bien des cas, la pensée créative circule mal devant un ordinateur
- Dès qu’on ouvre un éditeur, on entre dans un « mode fonctionnel » centré uniquement sur du code qui fonctionne
Réfléchir loin de l’ordinateur
- Faire une promenade ou réfléchir au problème avec un carnet sur le canapé ou en extérieur
- Noter dans le carnet la conception de l’approche d’un nouveau problème, des croquis d’UI, des organigrammes, ainsi que l’analyse du flux de données d’un code existant et des idées d’extension de fonctionnalités
- La visualisation de la pensée par le texte et le dessin est remarquablement efficace pour rendre concrètes des idées vagues
- Les manques logiques que l’on escamote vite dans sa tête apparaissent clairement lorsqu’on les écrit
L’écriture est le meilleur outil de refactoring
- Après avoir écrit du code, prendre l’habitude de le décrire par écrit comme si on l’expliquait à quelqu’un d’autre
- Si possible, le publier sur un blog, mais même sous forme de documentation interne, ce processus d’explication permet de repérer des incohérences, une mauvaise conception ou des erreurs
- Article lié : L’écriture est mon nouvel outil de refactoring préféré
Un sous-produit de la pensée et un capital documentaire
- Un autre avantage de cette façon de réfléchir par l’écriture est que la trace de la réflexion reste naturellement consignée
- Même sans documentation séparée, le sous-produit de l’organisation de ses idées devient un excellent matériau de rétrospective
- Plus tard, si quelqu’un (surtout soi-même dans le futur) demande « pourquoi cela a été fait ainsi », il suffit d’ouvrir le carnet et de l’expliquer tel quel
Pour aller plus loin sur la prise de notes de développeur
1 commentaires
Avis Hacker News
J’ai l’impression que c’est une excellente discussion. Le point clé, pour moi, ce n’est pas l’objet en lui-même, que ce soit un carnet ou un outil numérique, mais le fait qu’il change la vitesse de mon cerveau. À chaque changement de mode, le cerveau prête attention différemment, donc un nouveau contexte améliore la concentration, la créativité et la mémoire. Par exemple, après avoir passé mon temps à coder, j’ai commencé l’écriture comme nouveau hobby le soir, et j’ai eu l’impression que mon cerveau se réinitialisait ; ma productivité en journée a réellement augmenté. Passer un moment du numérique au stylo et au papier pour planifier casse aussi la routine et fait fonctionner le cerveau autrement. Au final, ce qui compte, ce n’est pas l’outil, mais l’éveil provoqué par le changement.
Je me demande combien de développeurs aujourd’hui ont déjà suivi de force un cours de dessin technique de base. Beaucoup ont sans doute joué avec des Lego. Quand il faut expliquer un objet en trois dimensions sur une feuille en deux dimensions, on dessine généralement des projections depuis trois directions, et si c’est plus complexe que ça, il faut encore plus d’angles pour pouvoir l’expliquer.
J’ai été marqué par le concept de « disfluency » que j’ai découvert dans le livre Smarter Faster Better. Une police inconfortable, un nouvel environnement, un autre outil, etc., nous sortent du mode pilote automatique et nous obligent à réfléchir à nouveau. Je n’ai vu ce concept nulle part ailleurs, mais il a complètement changé ma manière d’aborder la résolution de problèmes et l’apprentissage ces neuf dernières années. Pour moi aussi, passer au carnet est un bon déclencheur de cet effet.
Dans mon cas, je prends réellement des notes sur trois supports : un carnet papier, un vieux dictaphone et des fichiers texte. Chaque support a ses avantages et ses inconvénients propres, donc les idées s’y expriment différemment. Le dictaphone est de moins en moins utilisé, mais il est idéal quand je manque de temps et que je dois aller vite. Quand je réécoute un enregistrement plus tard pour le retranscrire, chaque répétition transforme l’idée d’une manière différente. Ce processus permet de voir la même idée sous plusieurs angles.
D’après une étude que j’avais entendue autrefois, le context switching coûte en moyenne environ 15 minutes. Je ne sais pas à quel point c’est exact, mais mes managers y font très attention et respectent beaucoup ce point.
Je l’ai vécu en suivant une série de webinaires en direct et en prenant immédiatement des notes au stylo sur papier. Au début, c’était vraiment difficile de suivre, mais au bout de quelques jours, je suis devenu de plus en plus à l’aise avec ce va-et-vient entre écouter et écrire, et j’avais l’impression de mieux retenir les informations auditives.
Certaines des personnes les plus brillantes que j’ai rencontrées en maths, en physique et en informatique ne prennent même pas de vraies notes. À la place, elles écrivent au stylo sur du papier d’imprimante et jettent tout une fois terminé. J’ai rarement trouvé de réelle utilité à mes anciennes notes personnelles. Ce qui compte vraiment, c’est de documenter les choses pour qu’elles puissent être retrouvées par d’autres, et d’apprendre avec des flashcards et de la spaced repetition ce qu’il faut absolument mémoriser. Bien sûr, c’est ma méthode, et elle peut ne pas convenir aux autres. Le titre de cet article partage simplement la philosophie d’un développeur, il ne dit pas que tout le monde doit faire pareil. Si le stylo et le carnet ne vous conviennent pas, vous n’êtes pas obligé de les utiliser.
Scientifiquement, écrire quelque chose améliore la mémoire, la mémorisation et l’apprentissage. Même si on jette ce qu’on vient d’écrire juste après, il y a quand même un effet. Il y a aussi cet article. Écrire à la main active davantage de sensations et de zones du cerveau — en particulier le cortex moteur — que taper au clavier. Je m’en sers souvent comme prétexte pour me dire que j’aimerais acheter un Moleskine, mais l’écriture manuscrite ne correspond pas à mon workflow. Je tape massivement dans un simple buffer texte, puis je retravaille ensuite avec un LLM comme GPT. Quand mon cerveau bloque, même si je ne comprends pas encore les mots que j’écris, le fait de taper sans m’arrêter me remet peu à peu en mouvement, et de là émergent des listes de tâches, des brouillons d’e-mails, des brouillons de code, etc. Au cours du processus, la plupart des gribouillages initiaux disparaissent. Malgré tout, l’écriture manuscrite aide davantage la mémoire.
Je suis d’accord avec ton idée selon laquelle les anciennes notes sont inutiles. Mais je conserve quand même tous ces carnets et ces feuilles. Les revoir longtemps après, c’est un peu comme regarder de vieilles photos de famille, des clichés de ma façon de penser à l’époque.
Mon cerveau fonctionne aussi comme ça. J’ai bien des carnets, mais une journée de pensées tient sur une seule page. Le lendemain, j’écris sur la suivante. Je relis presque jamais ce que j’ai écrit avant. Il y a peut-être une forme de valeur dans le fait de regarder le passé, mais en pratique je n’y arrive pas.
Pour moi, une méthode de prise de notes n’est efficace que si elle reste totalement libre et non structurée. Avec un clavier, il est difficile de capturer le flux. J’écris pour noter des données non linéaires, non verbales, relationnelles, spatiales, ou des informations de mémoire à court terme. Je relis périodiquement mes notes et je transfère les éléments significatifs vers des systèmes d’enregistrement comme le calendrier, les tickets, le wiki, la spaced repetition, etc. Au final, il est très rare que le contenu mérite vraiment d’être conservé, mais ce n’est pas grave. Le carnet papier n’est pas mon système d’archivage officiel, c’est une extension de ma mémoire de travail.
Avant, je perdais souvent mes notes. Maintenant, j’utilise des outils techniques pour les convertir en texte et les organiser dans un vault Obsidian. À l’avenir, j’aimerais essayer d’explorer automatiquement les liens entre les notes ou d’ajouter des tags pour retrouver plus facilement les idées.
Appeler le carnet « l’outil le plus important », c’est excessivement romantique. Ça peut être utile pour certaines personnes, mais dire que c’est plus important qu’un débogueur, que le versioning ou que la CI, c’est exagéré. Le software engineering n’est pas du cosplay d’artisan.
C’est l’OP. Chaque fois que mon blog arrive sur HN, on me dit que je « vis dans un fantasme » ou que c’est « du pur romantisme ». Les outils que tu as listés sont évidemment importants. Développer sans versioning ni débogueur serait inefficace, donc moi aussi je les évite. Mais pour moi, le carnet est vraiment plus important. Les outils qui servent à écrire et exécuter du code ne sont que des moyens de faire avancer le travail ; ce qui compte vraiment dans le développement logiciel, c’est de construire quelque chose de valable et de résoudre des problèmes. Dans ce cadre, le code lui-même n’est qu’une étape d’implémentation relativement mineure. Réfléchir à ce qu’il faut construire et à la manière de le faire est bien plus important. Certaines personnes réfléchissent mieux dans un éditeur de code ou avec des outils numériques. Moi, quand je reste seulement dans l’éditeur, je m’enferme trop dans les détails d’implémentation et j’ai du mal à voir la structure d’ensemble. Donc pour moi, utiliser un carnet avant et après le code fait partie du cœur même du travail. Sans cet outil, ma capacité de réflexion, de résolution de problèmes et de créativité serait considérablement émoussée, et je construirais de mauvais logiciels.
Ce que tu décris, ce n’est pas du software engineering, c’est de la transformation logicielle. La différence entre le col bleu et le col blanc, entre l’ouvrier de terrain et l’ingénieur, tient précisément à cette attitude face aux « outils ». Pour un ingénieur, qu’il s’agisse d’une règle à calcul, d’une calculatrice ou d’un supercalculateur, ce ne sont que des outils. Ce n’est pas à cause de l’outil qu’il fait de l’ingénierie. L’essence, c’est la pensée, et l’outil ne fait que faciliter le processus. Pour l’exécutant, en revanche, la machine est tout. Sans machine, pas de widget produit. L’essentiel n’est pas la « production », mais la réflexion.
C’est un peu comme dire : « Quand on construit une maison, évidemment qu’un marteau est plus important qu’un plan. Ce n’est pas un cours d’arts plastiques, c’est un chantier. »
Merci d’avoir souligné ce point. On voit souvent des gens investir énormément de temps dans leur système de productivité, remplir des notes gtd avec des onglets et des listes, sans jamais faire de travail réellement productif. Les gens écrivent sur leur workflow Obsidian, mais ne prennent pas de notes vraiment utiles. Beaucoup passent tout leur temps à construire leur blog sans jamais écrire d’article. (Moi aussi, ça m’est arrivé.) J’adore la formule « ce n’est pas du cosplay d’artisan, c’est du software engineering », je vais la noter dans mon carnet.
J’aime bien l’expression « craftsmanship cosplay ». J’aimerais voir les données sur le poste, la carrière, l’âge, les revenus et la formation de chaque commentateur. Au fond, ces avis en disent sans doute davantage sur ceux qui les formulent que sur le développement logiciel réussi lui-même. L’OP utilise simplement la manière qui lui permet d’obtenir la meilleure concentration et la meilleure créativité. Prendre le texte d’origine ou les critiques comme s’il s’agissait d’un standard est une erreur. Copier le motif revient en fin de compte à un comportement de cargo cult.
J’ai l’impression que la plupart des commentaires se focalisent sur l’aspect physique du « stylo et papier », tout en passant à côté du vrai principe fondamental. L’auteur utilise le stylo et le papier parce qu’une fois assis devant l’ordinateur, il bascule automatiquement en « mode implémentation » et se concentre davantage sur l’exécution que sur la conception. Le point important, autrement dit, c’est que lorsqu’un travail de conception est nécessaire, il ne faut pas se laisser happer simplement par l’implémentation ; chacun doit choisir comment maintenir son propre équilibre.
Au final, tout cela relève de la productivité personnelle. Il faut expérimenter différentes méthodes et trouver l’environnement et le processus qui nous conviennent. Le stylo et le papier aident à orienter la réflexion et la conception sans se noyer dans trop de détails ni se disperser. Moi aussi, j’alterne parfois entre des idées développées sur papier et d’autres directement écrites dans Sublime Text, et dans les deux cas ça fonctionne plutôt bien.
Le mème de la courbe en cloche populaire sur Reddit — celui où les deux extrêmes d’un niveau utilisent la même solution et où la « moyenne » se plaint — s’applique parfaitement ici. L’OP touche juste : il faut réfléchir avant de coder. À ce stade presque terminal de ma carrière (j’ai commencé en 88, donc ça fait des décennies), l’un des aspects les plus intéressants reste l’évolution des outils. Je suis senior principal software architect dans une grande entreprise, et je n’écris pas une ligne de code. Tous mes livrables sont produits avec Visio, Word, PowerPoint (et parfois PlantUML). Plus le niveau d’abstraction monte, plus les outils deviennent simples. Les architectures que je conçois doivent tourner plus de dix ans, dans le militaire, le médical et chez des équipementiers automobiles de rang 1. Le code effectivement implémenté (la plupart du temps en C, C++, jadis en Ada, peut-être demain en Rust) et le langage n’ont absolument aucun impact sur l’architecture. Ce qui compte vraiment, ce sont les blocs, les API et l’encapsulation, parce que cela a des effets sur le silicium, la sécurité, la production et les tests. Si quelque chose peut être expliqué en quelques slides, c’est là le cœur du sujet, pas dans le code lui-même. (Bien sûr, mes diagrammes doivent aussi résister à la découverte ultérieure de défauts de conception. C’est encore une autre partie intéressante.)
Carnet Leuchturm 1917 A4 Master (je recommande vivement la grille à points). La qualité est excellente, et avec un stylo-plume c’est un vrai plaisir. Le format A4 est grand, donc pratique pour glisser des feuilles volantes, et surtout c’est vraiment la taille idéale pour le design d’interface.
Je développe des logiciels depuis plus de 20 ans, et avant ça j’ai fait un doctorat et de la recherche en chimie organique. Je gagne très correctement ma vie comme « senior » en Australie. J’ai de l’aphantasie, donc j’utilise énormément le stylo, le papier et le tableau blanc. ERD, mind maps, diagrammes de séquence, toutes sortes de visualisations. Avec ReMarkable, déplacer le contenu est devenu plus facile et mon efficacité a augmenté. Pour certains, ça peut sembler relever du « pur romantisme », mais dans mon cas, le stylo et le papier ont été essentiels à ma réussite.
Après avoir essayé de mettre en place une habitude d’organisation avec divers outils et apps de notes, j’ai pris comme résolution de nouvelle année d’acheter un bloc-notes To-Do daté, et le simple fait d’y écrire librement pendant les réunions ou le travail m’a rendu bien plus productif. Pour ceux que ça intéresse, voici le modèle que j’utilise.
Quand je travaillais au bureau, l’une des choses qui me manquent est le temps passé debout devant un grand tableau blanc à concevoir avec des collègues. Quand on réfléchissait à l’architecture ensemble, marqueur à la main, on arrivait souvent à des conceptions de classes vraiment élégantes.
J’utilise excalidraw pour ça, et je trouve ça meilleur qu’un tableau blanc. 1) C’est plus propre et moins brouillon, 2) les marqueurs numériques ne sèchent pas, 3) les corrections et modifications sont faciles. Pour les conceptions techniques, je commence toujours par excalidraw.
J’utilise un écran à stylet de 24 pouces. Quand j’étais CTO, j’en avais même fourni un à tous les membres de l’équipe. Avec un tableau blanc numérique partagé qu’on peut éditer en continu, c’est tellement plus pratique que de devoir tout redessiner plusieurs fois. Et pas besoin non plus de prendre une photo du tableau avant de l’effacer.
Le tableau blanc (ou même le tableau noir), c’est la vie.