GARDER UN PROGRAMME EN TÊTE

Août 2007

Un bon programmeur travaillant intensivement sur son propre code peut le garder en tête de la même manière qu'un mathématicien garde 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'apprend aux écoliers. Ils font plus dans leur tête : ils essaient de comprendre un espace de problèmes assez bien pour pouvoir s'y promener comme vous pouvez vous promener dans le souvenir de la maison où vous avez grandi. À son meilleur, la programmation est la même. Vous tenez tout le programme en tête, et vous pouvez le manipuler à volonté.

C'est particulièrement précieux au début d'un projet, car initialement, le plus important 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 en tête que vous comprenez vraiment le problème.

Il n'est pas facile de mettre un programme dans sa tête. Si vous quittez un projet pendant quelques mois, il peut vous falloir des jours pour vraiment le comprendre à nouveau lorsque vous y retournez. Même lorsque vous travaillez activement sur un programme, il peut vous 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 plus dramatiquement, 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 tout le programme sur lequel ils travaillent chargé dans leur tête. Mais il y a des choses que vous pouvez faire pour vous 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 à fonctionner à la limite du détail qu'ils peuvent gérer.

Le danger d'une distraction ne dépend pas de sa durée, mais de la façon 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.

Bizarrement, les distractions planifiées peuvent être pires que les distractions non planifié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 en longues séances. 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 séances plutôt qu'en plusieurs courtes. Il arrivera bien sûr un moment où vous deviendrez stupide parce que vous êtes fatigué. Cela varie d'une personne à l'autre. J'ai entendu parler de gens qui ont piraté pendant 36 heures d'affilée, mais le maximum que j'ai pu gérer est d'environ 18, et je travaille mieux par tranches de 12 maximum.

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

Utilisez des langages concis. Plus puissants les langages de programmation, plus les programmes sont courts. Et les programmeurs semblent penser aux programmes au moins en partie dans le langage qu'ils utilisent pour les écrire. Plus le langage est concis, plus le programme est court, et plus il est facile à charger et à garder en 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 qui sont au-dessus. Si vous faites cela correctement, vous n'avez qu'à garder la couche supérieure en 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 lisible. 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 étendez 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 meilleur 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 à la limite du code que vous possédez. Vous ne comprenez pas aussi bien les autres parties, et plus important encore, vous ne pouvez pas vous permettre de les modifier. 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 refontes globales.

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 attentivement, vous ne l'avez que lu, pas écrit. Donc, si un morceau de code est écrit par plusieurs auteurs, aucun d'eux ne le comprend aussi bien qu'un seul auteur.

Et bien sûr, vous ne pouvez pas modifier 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. Refonte du code avec plusieurs auteurs est comme changer les lois ; refonte 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 en tête au fur et à 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 complètement explorées. Mais lorsque vous commencez à travailler sur un projet, vous êtes obligé de tout voir. Si vous commencez avec un problème trop grand, vous ne pourrez peut-être jamais l'englober complètement. Donc, si vous avez besoin d'écrire un programme grand et complexe, la meilleure façon de commencer peut ne pas être d'écrire un cahier des charges, 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 surclassés par les avantages de pouvoir garder un programme en tête.

Il est frappant de constater à quelle fréquence les programmeurs réussissent à atteindre 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 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 qu'il s'agit initialement d'une simple expérience, au lieu d'un langage de "production", il utilise un simple langage de "scripting" - 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 comme personne ne va le voir sauf lui, il omet tous les commentaires sauf ceux de type "note pour moi-même". Il travaille dans un petit groupe par force, parce qu'il n'a encore parlé de l'idée à personne, ou parce qu'elle semble si peu prometteuse 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 il 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 les huit choses mal. 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, ils le font. L'une des qualités définissantes des organisations depuis qu'il y en a, c'est de traiter les individus comme des pièces interchangeables. Cela fonctionne bien pour les tâches plus parallélisables, comme les guerres. Pendant la majeure partie de l'histoire, une armée bien drillée de soldats professionnels pouvait être considérée comme capable de battre une armée de guerriers individuels, aussi vaillants soient-ils. 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. Cela fait partie de la définition d'une organisation de ne pas le faire. De notre concept actuel d'organisation, du moins.

Peut-être pourrions-nous définir un nouveau type d'organisation qui combinerait les efforts des individus sans exiger qu'ils soient interchangeables. On pourrait soutenir qu'un marché est une telle forme d'organisation, bien qu'il soit peut-être plus exact 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 qu'elles les achètent simplement. Mais quelle que soit la solution qui s'avère être la meilleure, 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 va être en conflit avec elle, car les organisations sont conçues pour empêcher ce que les programmeurs cherchent à faire.

Les bons programmeurs parviennent quand même à faire beaucoup de choses. 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 en longues séances pendant lesquelles ils se débarrassent de toutes leurs autres obligations, se lancent directement dans la programmation au lieu d'écrire des spécifications en premier, et réécrivent du code qui fonctionne déjà. Ce n'est pas parce qu'ils sont antipathiques qu'ils préfèrent travailler seuls, ou grognent à ceux qui leur font un signe de tête pour dire bonjour. Cet ensemble apparemment aléatoire d'habitudes gênantes a une seule explication : le pouvoir de garder un programme en tête.

Que la compréhension de cela puisse ou non aider les grandes organisations, elle peut certainement aider leurs concurrents. Le point 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 type de problèmes qui doivent être résolus dans un seul 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 les brouillons de ce texte.