Tenir un programme dans sa tête

Août 2007

Un bon programmeur travaillant intensément sur son propre code peut le garder en tête comme un mathématicien avec 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ème suffisamment bien pour pouvoir s'y promener comme vous pourriez vous promener dans le souvenir de la maison où vous avez grandi. À son meilleur, la programmation est la même chose. Vous gardez tout le programme dans votre tête, et vous pouvez le manipuler à volonté.

C'est particulièrement précieux au début d'un projet, car initialement la chose la plus importante est de pouvoir changer ce que vous faites. Pas seulement résoudre le problème d'une manière différente, mais 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 laissez un projet pendant quelques mois, cela peut prendre des jours pour vraiment le comprendre à nouveau lorsque vous y revenez. Même lorsque vous travaillez activement sur un programme, cela peut prendre 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 aider :

1. É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 des détails 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.

Curieusement, les distractions programmées peuvent être pires que les 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.

2. Travaillez sur de longues périodes. 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 nombreuses courtes. Il viendra 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 programment 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 tranches de pas plus de 12.

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 revenez à un problème après un repos, vous trouvez que votre esprit inconscient a laissé une réponse vous attendre.

3. Utilisez des langages succincts. Les 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 à garder que la couche la plus haute dans votre tête.

4. 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.

5. É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é.

6. 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. Les autres parties, vous ne les comprenez pas aussi bien, et plus important, vous ne pouvez pas en prendre des 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 englobants.

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

Et bien sûr, vous ne pouvez pas redessiner en toute sécurité quelque chose sur lequel d'autres travaillent. Ce n'est pas seulement que vous devriez demander la permission. Vous ne vous permettez même pas de 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.

8. Commencez petit. Un programme devient plus facile à garder en tête à mesure que vous vous familiarisez avec lui. Vous pouvez commencer à traiter des parties comme des boîtes noires une fois que vous êtes confiant de les avoir pleinement explorées. Mais lorsque vous commencez à travailler sur un projet, vous êtes obligé de tout voir. Si vous commencez avec un problème trop gros, vous pourriez ne jamais être tout à fait capable de l'envelopper. Donc si vous avez besoin d'écrire un programme grand et complexe, la meilleure façon de commencer pourrait ne pas être d'écrire un spec pour lui, 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 surpassés par les avantages de pouvoir garder un programme dans votre tête.

Il est frappant de voir à quel point les programmeurs parviennent souvent à 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 heures supplémentaires - qui s'avèrent plus productives parce qu'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 bien 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 le verra sauf lui, il omet tout commentaire sauf ceux du type note à soi-même. Il travaille dans un petit groupe par nécessité, parce qu'il n'a pas encore dit à personne d'autre de l'idée, ou 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 éditant le même code, parce qu'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 mal les huit choses. En fait, si vous regardez la façon dont le logiciel est écrit dans la plupart des organisations, c'est presque comme s'ils essayaient délibérément de faire les choses mal. Dans un sens, ils le font. Une des qualités définissant les organisations depuis qu'elles existent est de traiter les individus comme des pièces interchangeables. Cela fonctionne bien pour des tâches plus parallélisables, comme faire la guerre. Pour la plupart 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.

Ce 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 de ne pas le faire. Du moins, de notre concept actuel d'une organisation.

Peut-être pourrions-nous définir un nouveau type d'organisation qui combine les efforts des individus sans exiger qu'ils soient interchangeables. Un marché est peut-être une telle forme d'organisation, bien qu'il soit peut-ê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 ferons est une sorte de hack, comme faire fonctionner les parties de programmation d'une organisation 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 quelle que soit la solution qui se révèle être, la première étape est de réaliser qu'il y a un problème. Il y a une contradiction dans l'expression même de "entreprise de logiciel". Les deux mots tirent dans des directions opposées. Tout bon programmeur dans une grande organisation va être en désaccord avec elle, parce que les organisations sont conçues pour empêcher ce que les programmeurs s'efforcent d'atteindre.

Les bons programmeurs parviennent à faire beaucoup de choses malgré tout. 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 dans de longues frénésies pendant lesquelles ils ignorent toutes les autres obligations, plongent directement dans la programmation au lieu d'écrire d'abord des specs, 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 contre les gens qui passent la tête à la porte pour dire bonjour. Cette collection apparemment aléatoire de habitudes ennuyeuses a une seule explication : le pouvoir de tenir un programme dans sa tête.

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

Remerciements à 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 ceci.