TENIR UN PROGRAMME DANS SA TÊTE

August 2007

Un bon programmeur travaillant intensivement sur son propre code peut le tenir dans sa tête comme un mathématicien tient un problème sur lequel il travaille. Les mathématiciens ne répondent pas aux questions en les résolvant sur papier comme on l'enseigne aux écoliers. Ils font plus dans leur tête : ils essaient de comprendre un espace de problème suffisamment bien pour pouvoir s'y déplacer comme on peut se déplacer dans la mémoire de la maison où l'on a grandi. Au mieux, la programmation est la même chose. Vous tenez l'ensemble du programme dans votre tête, et vous pouvez le manipuler à volonté.

C'est particulièrement précieux au début d'un projet, car au départ, la chose la plus importante est de pouvoir changer ce que vous faites. Pas seulement pour résoudre le problème d'une manière différente, mais pour changer le problème que vous résolvez.

Votre code est votre compréhension du problème que vous explorez. Donc, ce n'est que lorsque vous avez votre code dans votre tête que vous comprenez vraiment le problème.

Il n'est pas facile de faire entrer un programme dans votre tête. Si vous laissez un projet pendant quelques mois, il peut falloir des jours pour vraiment le comprendre à nouveau lorsque vous y revenez. Même lorsque vous travaillez activement sur un programme, il peut falloir une demi-heure pour le charger dans votre tête lorsque vous commencez à travailler chaque jour. Et c'est dans le meilleur des cas. Les programmeurs ordinaires travaillant dans des conditions de bureau typiques n'entrent jamais dans ce mode. Ou pour le dire de manière plus dramatique, les programmeurs ordinaires travaillant dans des conditions de bureau typiques ne comprennent jamais vraiment les problèmes qu'ils résolvent.

Même les meilleurs programmeurs n'ont pas toujours l'ensemble du programme sur lequel ils travaillent chargé dans leur tête. Mais il y a des choses que vous pouvez faire pour aider :

Évitez les distractions. Les distractions sont mauvaises pour de nombreux types de travail, mais particulièrement mauvaises pour la programmation, car les programmeurs ont tendance à opérer à la limite du détail qu'ils peuvent gérer.

Le danger d'une distraction dépend non pas de sa durée, mais de la manière dont elle brouille votre cerveau. Un programmeur peut quitter le bureau et aller chercher un sandwich sans perdre le code dans sa tête. Mais le mauvais type d'interruption peut effacer votre cerveau en 30 secondes.

Étrangement, les distractions programmées peuvent être pires que celles non programmées. Si vous savez que vous avez une réunion dans une heure, vous ne commencez même pas à travailler sur quelque chose de difficile.

Travaillez par longues sessions. Puisqu'il y a un coût fixe chaque fois que vous commencez à travailler sur un programme, il est plus efficace de travailler en quelques longues sessions qu'en de nombreuses courtes. Il y aura bien sûr un moment où vous devenez stupide parce que vous êtes fatigué. Cela varie d'une personne à l'autre. J'ai entendu parler de personnes qui ont codé pendant 36 heures d'affilée, mais le plus que j'ai jamais pu gérer est d'environ 18, et je travaille mieux par morceaux de pas plus de 12.

L'optimum n'est pas la limite que vous pouvez physiquement supporter. Il y a un avantage ainsi qu'un coût à diviser un projet. Parfois, lorsque vous revenez à un problème après un repos, vous constatez que votre esprit inconscient a laissé une réponse vous attendant.

Utilisez des langages succincts. Des langages de programmation plus puissants rendent les programmes plus courts. Et les programmeurs semblent penser aux programmes au moins partiellement dans le langage qu'ils utilisent pour les écrire. Plus le langage est succinct, plus le programme est court, et plus il est facile de le charger et de le garder dans votre tête.

Vous pouvez amplifier l'effet d'un langage puissant en utilisant un style appelé programmation ascendante, où vous écrivez des programmes en plusieurs couches, les couches inférieures agissant comme des langages de programmation pour celles au-dessus. Si vous faites cela correctement, vous n'avez qu'à garder la couche la plus haute dans votre tête.

Continuez à réécrire votre programme. Réécrire un programme donne souvent un design plus propre. Mais cela aurait des avantages même si ce n'était pas le cas : vous devez comprendre un programme complètement pour le réécrire, donc il n'y a pas de meilleure façon de le charger dans votre tête.

Écrivez du code relisible. Tous les programmeurs savent qu'il est bon d'écrire du code lisible. Mais vous-même êtes le lecteur le plus important. Surtout au début ; un prototype est une conversation avec vous-même. Et lorsque vous écrivez pour vous-même, vous avez des priorités différentes. Si vous écrivez pour d'autres personnes, vous ne voudrez peut-être pas rendre le code trop dense. Certaines parties d'un programme peuvent être plus faciles à lire si vous étalez les choses, comme un manuel d'introduction. Alors que si vous écrivez du code pour le rendre facile à recharger dans votre tête, il peut être préférable d'opter pour la brièveté.

Travaillez en petits groupes. Lorsque vous manipulez un programme dans votre tête, votre vision a tendance à s'arrêter au bord du code que vous possédez. D'autres parties que vous ne comprenez pas aussi bien, et plus important encore, avec lesquelles vous ne pouvez pas prendre de libertés. Donc, plus le nombre de programmeurs est petit, plus un projet peut muter complètement. S'il n'y a qu'un seul programmeur, comme c'est souvent le cas au début, vous pouvez faire des redesigns globaux.

Ne laissez pas plusieurs personnes modifier le même morceau de code. Vous ne comprenez jamais le code des autres aussi bien que le vôtre. Peu importe à quel point vous l'avez lu en profondeur, vous l'avez seulement lu, pas écrit. Donc, si un morceau de code est écrit par plusieurs auteurs, aucun d'eux ne le comprend aussi bien qu'un auteur unique.

Et bien sûr, vous ne pouvez pas redessiner en toute sécurité quelque chose sur lequel d'autres personnes travaillent. Ce n'est pas seulement que vous devriez demander la permission. Vous ne vous laissez même pas penser à de telles choses. Redessiner du code avec plusieurs auteurs est comme changer des lois ; redessiner du code que vous contrôlez seul est comme voir l'autre interprétation d'une image ambiguë.

Si vous voulez mettre plusieurs personnes à travailler sur un projet, divisez-le en composants et donnez-en un à chaque personne.

Commencez petit. Un programme devient plus facile à tenir dans votre tête à mesure que vous vous familiarisez avec lui. Vous pouvez commencer à traiter des parties comme des boîtes noires une fois que vous vous sentez confiant de les avoir pleinement explorées. Mais lorsque vous commencez à travailler sur un projet, vous êtes forcé de tout voir. Si vous commencez avec un problème trop grand, vous ne pourrez peut-être jamais vraiment l'englober. Donc, si vous devez écrire un grand programme complexe, la meilleure façon de commencer peut ne pas être d'écrire un cahier des charges pour cela, mais d'écrire un prototype qui résout un sous-ensemble du problème. Quels que soient les avantages de la planification, ils sont souvent éclipsés par les avantages de pouvoir garder un programme dans votre tête.

Il est frappant de voir à quelle fréquence les programmeurs parviennent à toucher les huit points par accident. Quelqu'un a une idée pour un nouveau projet, mais parce qu'il n'est pas officiellement sanctionné, il doit le faire en dehors des heures de travail—ce qui s'avère être plus productif car il n'y a pas de distractions. Poussé par son enthousiasme pour le nouveau projet, il y travaille pendant de nombreuses heures d'affilée. Parce que c'est initialement juste une expérience, au lieu d'un langage de "production", il utilise un simple langage de "script"—qui est en fait beaucoup plus puissant. Il réécrit complètement le programme plusieurs fois ; cela ne serait pas justifiable pour un projet officiel, mais c'est un travail d'amour et il veut qu'il soit parfait. Et puisque personne ne va le voir sauf lui, il omet tous les commentaires sauf ceux de type note à soi. Il travaille en petit groupe de force, car il n'a soit pas encore dit à quelqu'un d'autre l'idée, soit cela semble si peu prometteur que personne d'autre n'est autorisé à y travailler. Même s'il y a un groupe, ils ne pourraient pas avoir plusieurs personnes modifiant le même code, car cela change trop vite pour que cela soit possible. Et le projet commence petit parce que l'idée est petite au début ; il a juste un hack cool qu'il veut essayer.

Encore plus frappant est le nombre de projets officiellement sanctionnés qui parviennent à faire toutes les huit choses de travers. En fait, si vous regardez la façon dont les logiciels sont écrits dans la plupart des organisations, c'est presque comme s'ils essayaient délibérément de faire les choses mal. En un sens, c'est le cas. L'une des qualités définissantes des organisations depuis qu'il y a eu de telles choses est de traiter les individus comme des pièces interchangeables. Cela fonctionne bien pour des tâches plus parallélisables, comme mener des guerres. Pendant la majeure partie de l'histoire, une armée bien entraînée de soldats professionnels pouvait être comptée pour battre une armée de guerriers individuels, peu importe leur valeur. Mais avoir des idées n'est pas très parallélisable. Et c'est ce que sont les programmes : des idées.

Il n'est pas seulement vrai que les organisations n'aiment pas l'idée de dépendre du génie individuel, c'est une tautologie. C'est une partie de la définition d'une organisation que de ne pas le faire. De notre concept actuel d'une organisation, du moins.

Peut-être pourrions-nous définir un nouveau type d'organisation qui combine les efforts des individus sans exiger qu'ils soient interchangeables. On peut soutenir qu'un marché est une telle forme d'organisation, bien qu'il puisse être plus précis de décrire un marché comme un cas dégénéré—comme ce que vous obtenez par défaut lorsque l'organisation n'est pas possible.

Probablement, le mieux que nous puissions faire est une sorte de hack, comme faire en sorte que les parties de programmation d'une organisation fonctionnent différemment du reste. Peut-être que la solution optimale est que les grandes entreprises n'essaient même pas de développer des idées en interne, mais simplement de les acheter. Mais peu importe ce que la solution s'avère être, la première étape est de réaliser qu'il y a un problème. Il y a une contradiction dans la phrase même "entreprise de logiciels." Les deux mots tirent dans des directions opposées. Tout bon programmeur dans une grande organisation sera en désaccord avec elle, car les organisations sont conçues pour empêcher ce que les programmeurs s'efforcent d'atteindre.

Les bons programmeurs parviennent à accomplir beaucoup de choses quand même. Mais souvent, cela nécessite pratiquement un acte de rébellion contre les organisations qui les emploient. Peut-être que cela aidera si plus de gens comprennent que la façon dont les programmeurs se comportent est dictée par les exigences du travail qu'ils font. Ce n'est pas parce qu'ils sont irresponsables qu'ils travaillent par longues périodes pendant lesquelles ils négligent toutes les autres obligations, plongent directement dans la programmation au lieu d'écrire d'abord des spécifications, et réécrivent du code qui fonctionne déjà. Ce n'est pas parce qu'ils sont peu amicaux qu'ils préfèrent travailler seuls, ou grognent à ceux qui passent la tête par la porte pour dire bonjour. Cette collection apparemment aléatoire d'habitudes ennuyeuses a une seule explication : le pouvoir de tenir un programme dans sa tête.

Que cela puisse ou non aider les grandes organisations, cela peut certainement aider leurs concurrents. Le point le plus faible des grandes entreprises est qu'elles ne laissent pas les programmeurs individuels faire un excellent travail. Donc, si vous êtes une petite startup, c'est l'endroit où les attaquer. Prenez en charge le genre de problèmes qui doivent être résolus dans un grand cerveau.

Merci à Sam Altman, David Greenspan, Aaron Iba, Jessica Livingston, Robert Morris, Peter Norvig, Lisa Randall, Emmett Shear, Sergei Tsarev, et Stephen Wolfram pour avoir lu des brouillons de ceci.